简述一个大型交易网站的发展旅程

   一、功能定义: 

–商品 :展示商品,商品管理,……

–交易 :创建交易,交易管理,……

–用户 :注册用户,信息查询,用户管理,……

   二、技术发展

第一版:简单基础版

      出于快速开发的考虑,第一版往往采用单台机器构建(这里采用java技术,下同),这样开发方便而且快速,采用的技术甚至可以是最简单的jsp,servlet等。

      它的技术特点:

     •三个功能模块

     •一个数据库中的三个表

     •连接数据库使用了JDBC

     •模块之间的调用是JVM内部的方法调用

第二版:应用和数据库分离

     随着访问量的上升,这台机器的负载越来越高,这时可以说是该网站遇到的第一个性能问题,此时一般的解决方案很简单,将应用(App)和数据库(DB)拆分到两台机器上

      这种改造实现了应用服务器和数据服务器的分离,对开发、测试、部署,没什么影响。

第三版:多台应用服务器

    访问量持续上升,应用服务器的压力也变的很大,第二版的简单设计已经不能支撑这么大的访问量,所以不得不继续对其进行改造。

     它的设计方案就是将应用从1台拆分到了两台,甚至多台。但此时会遇到的问题——session。Session的数据保存在服务器中,服务器拆分前后,如何维护session的一致性?比如,下图中,将应用服务器拆分为A应用服务器和B应用服务器,当一个顾客先访问A服务器,然后经过通过页面跳转到了B服务器,此时A中有该用户的session,而B没有,造成访问有误。

     

它的解决方案:

•解法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 **对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。

第四版:读写分离

    随着业务的发展,数据库会成为瓶颈,读写比例很高(相当于读数据库的人很多,而写数据库的人相对而言少)

    解决方案,通过读写分离,降低主库的压力

第五版:

      1.为了方便用户更快地找到商品,系统引入搜索引擎;为了减轻数据库的访问压力和提高访问速度,引入了缓存;为了解决海量数据存储,引入了分布式文件存储。系统架构如下

      2. 引入CDN系统,CDN的全称是Content Delivery Network,即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络"边缘",使用户可以就近取得所需的内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。

第六版:数据库拆分

     虽然读写分离了,但虽这业务的增长,主库还是会遇到瓶颈。这时,我们可以根据功能,对数据库进行切分。具体如下图,原先的数据库中包含了所有数据,现在将其进行“垂直切分”——就是不同的数据库存储不同类型的表。

     

     这个交易系统中,就是分库为商品表,交易表,用户表。

     这时需要注意的问题包括:

     1. 对之前的一些有事务的SQL,可能造成影响

     2. 对之前的多表join的SQL,可能造成影响。

      原先多张表是在同一数据库中,用join操作是相当容易的,现在不同的表在不同的数据库中,一个join操作要用到在不同的表,此时就需要访问不同的服务器。

ps:

事务讲解:http://blog.csdn.net/lengyuhong/archive/2010/11/02/5981872.aspx

第七版:

      用垂直拆分后,能够缓解很大的问题,但如果数据库和访问量地原因,造成单台数据库还是不能够去负担。这时就需要对数据库进行水平拆分。 具体如下图中的用户表。

      水平切分和垂直切分的不同在于扩展方式上,举例而言,原先一台服务器一个数据库三张表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. 唯一主键

     用户表分布在两台数据库中,如何做到两台数据库中的用户表有唯一主键。

第八版:

     引入服务化

       它可以解决两个问题:

       1. 解决了业务核心的稳定和一致的问题

       2. 解决了重要数据库的连接数的问题

第九版:

      引入消息中间件

      –解耦

      –异步  

      三、技术总结     

最后系统的架构:

大致总结这个网站的技术发展过程:

1台机器+1个应用+1一个DB

应用和DB分到两个机器

应用部署多机器,走入集群

DB读写分离

引入搜索

引入Cache

引入分布式存储

引入CDN

数据库垂直拆分

数据库水平拆分

应用的拆分

服务化

引入消息中间件

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×