简述一个大型交易网站的发展旅程
一、功能定义:
–商品 :展示商品,商品管理,……
–交易 :创建交易,交易管理,……
–用户 :注册用户,信息查询,用户管理,……
二、技术发展
第一版:简单基础版
![](http://hi.csdn.net/attachment/201103/25/0_130105555085wQ.gif)
出于快速开发的考虑,第一版往往采用单台机器构建(这里采用java技术,下同),这样开发方便而且快速,采用的技术甚至可以是最简单的jsp,servlet等。
它的技术特点:
•三个功能模块
•一个数据库中的三个表
•连接数据库使用了JDBC
•模块之间的调用是JVM内部的方法调用
第二版:应用和数据库分离
随着访问量的上升,这台机器的负载越来越高,这时可以说是该网站遇到的第一个性能问题,此时一般的解决方案很简单,将应用(App)和数据库(DB)拆分到两台机器上
![](http://hi.csdn.net/attachment/201103/25/0_1301056053bRLJ.gif)
这种改造实现了应用服务器和数据服务器的分离,对开发、测试、部署,没什么影响。
第三版:多台应用服务器
访问量持续上升,应用服务器的压力也变的很大,第二版的简单设计已经不能支撑这么大的访问量,所以不得不继续对其进行改造。
![](http://hi.csdn.net/attachment/201103/25/0_1301056385Cccr.gif)
它的设计方案就是将应用从1台拆分到了两台,甚至多台。但此时会遇到的问题——session。Session的数据保存在服务器中,服务器拆分前后,如何维护session的一致性?比如,下图中,将应用服务器拆分为A应用服务器和B应用服务器,当一个顾客先访问A服务器,然后经过通过页面跳转到了B服务器,此时A中有该用户的session,而B没有,造成访问有误。
![](http://hi.csdn.net/attachment/201103/25/0_1301057811Tkdf.gif)
它的解决方案:
•解法1:Session-Sticky
一个用户访问了一次后,同一个session周期内,所有的请求都定向到这个服务器,只有当游览器关闭或者服务器挂掉,session才会丢失
•解法2:Session Replication
session replication 策略是复制会话,即一个用户访问了一次就把session复制到所有的服务器或这一部分服务器。这样的好处是如果正访问的服务器down了,用户可以自动被转到别的服务器session不丢失。缺点当然是效率低。
•解法3:基于Cookie
•解法4:Session数据集中独立存储
特别强调:
1. Web中的Session指的就是用户在浏览某个网站时,从进入网站到游览器关闭所经过的这段时间,也就是用户浏览这个网站所花费的时间。A用户和C服务器建立连接时所处的Session同B用户和C服务器中建立连接时所处的Sessions是两个不同的Session。
2. 当用户在相同机器的应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。
第四版:读写分离
随着业务的发展,数据库会成为瓶颈,读写比例很高(相当于读数据库的人很多,而写数据库的人相对而言少)
解决方案,通过读写分离,降低主库的压力
![](http://hi.csdn.net/attachment/201103/25/0_1301059059otNx.gif)
第五版:
1.为了方便用户更快地找到商品,系统引入搜索引擎;为了减轻数据库的访问压力和提高访问速度,引入了缓存;为了解决海量数据存储,引入了分布式文件存储。系统架构如下
![](http://hi.csdn.net/attachment/201103/25/0_1301059252WH0h.gif)
2. 引入CDN系统,CDN的全称是Content Delivery Network,即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络"边缘",使用户可以就近取得所需的内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。
![](http://hi.csdn.net/attachment/201103/25/0_1301059265UP08.gif)
第六版:数据库拆分
虽然读写分离了,但虽这业务的增长,主库还是会遇到瓶颈。这时,我们可以根据功能,对数据库进行切分。具体如下图,原先的数据库中包含了所有数据,现在将其进行“垂直切分”——就是不同的数据库存储不同类型的表。
![](http://hi.csdn.net/attachment/201103/29/0_1301399369gM0G.gif)
这个交易系统中,就是分库为商品表,交易表,用户表。
这时需要注意的问题包括:
1. 对之前的一些有事务的SQL,可能造成影响
2. 对之前的多表join的SQL,可能造成影响。
原先多张表是在同一数据库中,用join操作是相当容易的,现在不同的表在不同的数据库中,一个join操作要用到在不同的表,此时就需要访问不同的服务器。
第七版:
用垂直拆分后,能够缓解很大的问题,但如果数据库和访问量地原因,造成单台数据库还是不能够去负担。这时就需要对数据库进行水平拆分。 具体如下图中的用户表。
![](http://hi.csdn.net/attachment/201103/29/0_1301402060eT4G.gif)
水平切分和垂直切分的不同在于扩展方式上,举例而言,原先一台服务器一个数据库三张表TA,TB,TC。垂直切分就是三台服务器,每台服务器一个数据库,服务器A中存TA表,服务器B存TB表,服务器C存TC表。水平切分也是三台服务器,每台服务器一个数据库,服务器A,B,C中都存有TA,TB,TC三张表。
这杨拆分后,还是带来了新的问题:
1. 路由
比如有两台服务器,都存有用户数据,当我们要插入一条用户信息时,应该插入到哪台服务器的数据库上;当我们要检索一条用户信息时,我们应该到哪台服务器上查找。
2. 分页
3. 合并
个人觉得2,3两种情况通常会一起发生,比如我们要查出前一百名的用户(具体比如在网站购物最多的用户),此时可能的情况是这前100名中60个在数据库A,40个在数据库B。
4. 唯一主键
用户表分布在两台数据库中,如何做到两台数据库中的用户表有唯一主键。
第八版:
引入服务化
![](http://hi.csdn.net/attachment/201103/29/0_1301403573H77M.gif)
它可以解决两个问题:
1. 解决了业务核心的稳定和一致的问题
2. 解决了重要数据库的连接数的问题
第九版:
引入消息中间件
–解耦
–异步
三、技术总结
最后系统的架构:
![](http://hi.csdn.net/attachment/201103/29/0_1301403775uHV7.gif)
大致总结这个网站的技术发展过程:
1台机器+1个应用+1一个DB
应用和DB分到两个机器
应用部署多机器,走入集群
DB读写分离
引入搜索
引入Cache
引入分布式存储
引入CDN
数据库垂直拆分
数据库水平拆分
应用的拆分
服务化
引入消息中间件
如果你喜欢本文, 请长按二维码,关注公众号 分布式编程.
作者:分布式编程
出处:https://zthinker.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。