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

   一、功能定义: 

 

商品 展示商品, 商品管理,……
交易 创建交易, 交易管理, ……
用户 注册用户, 信息查询, 用户 管理, ……
  
   二、技术发展
第一版:简单基础版
简述一个大型交易网站的发展旅程_第1张图片
      出于快速开发的考虑,第一版往往采用 单台机器构建(这里采用java技术,下同),这样开发方便而且快速,采用的技术甚至可以是最简单的jsp,servlet等。
      它的技术特点:
     • 个功能模块
     • 一个数据库中的三个表
     • 连接数据库使用了 JDBC
     • 模块之间的调用是 JVM 内部的方法调用
第二版:应用和数据库分离
     随着访问量的上升,这台机器的负载越来越高,这时可以说是该网站遇到的第一个性能问题,此时一般的解决方案很简单, 将应用 (App) 和数据库 (DB) 拆分到两台机器上
简述一个大型交易网站的发展旅程_第2张图片
       这种改造实现了应用服务器和数据服务器的分离, 对开发、测试、部署,没什么影响。

第三版:多台应用服务器
     访问量持续上升,应用服务器的压力也变的很大,第二版的简单设计已经不能支撑这么大的访问量,所以不得不继续对其进行改造。
简述一个大型交易网站的发展旅程_第3张图片
     它的设计方案就是将 应用从 1 台拆分到了两台,甚至多台。但此时会遇到的问题——session。 Session 的数据保存在服务器中,服务器拆分前后,如何维护session的一致性?比如,下图中,将应用服务器拆分为A应用服务器和B应用服务器,当一个顾客先访问A服务器,然后经过通过页面跳转到了B服务器,此时A中有该用户的session,而B没有,造成访问有误。
     简述一个大型交易网站的发展旅程_第4张图片
它的解决方案:
解法 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 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。
第四版:读写分离
    随着业务的发展,数据库会成为瓶颈,读写比例很高(相当于读数据库的人很多,而写数据库的人相对而言少)
    解决方案,通过读写分离,降低主库的压力
简述一个大型交易网站的发展旅程_第5张图片
第五版:
      1.为了方便用户更快地找到商品,系统引入搜索引擎;为了减轻数据库的访问压力和提高访问速度,引入了缓存;为了解决海量数据存储,引入了分布式文件存储。系统架构如下
简述一个大型交易网站的发展旅程_第6张图片
    
      2. 引入CDN系统, CDN的全称是Content Delivery Network,即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络"边缘",使用户可以就近取得所需的内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。
简述一个大型交易网站的发展旅程_第7张图片

第六版:数据库拆分
     虽然读写分离了,但虽这业务的增长,主库还是会遇到瓶颈。这时,我们可以根据功能,对数据库进行切分。具体如下图,原先的数据库中包含了所有数据,现在将其进行“垂直切分”——就是不同的数据库存储不同类型的表。
     简述一个大型交易网站的发展旅程_第8张图片
     这个交易系统中,就是分库为商品表,交易表,用户表。
     这时需要注意的问题包括:
     1. 对之前的一些有事务的SQL,可能造成影响
     2. 对之前的多表join的SQL,可能造成影响。
      原先多张表是在同一数据库中,用join操作是相当容易的,现在不同的表在不同的数据库中,一个join操作要用到在不同的表,此时就需要访问不同的服务器。

ps:
事务讲解: http://blog.csdn.net/lengyuhong/archive/2010/11/02/5981872.aspx
第七版:
      用垂直拆分后,能够缓解很大的问题,但如果数据库和访问量地原因,造成单台数据库还是不能够去负担。这时就需要对数据库进行水平拆分。 具体如下图中的用户表。
简述一个大型交易网站的发展旅程_第9张图片
      水平切分和垂直切分的不同在于扩展方式上,举例而言,原先一台服务器一个数据库三张表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. 唯一主键
     用户表分布在两台数据库中,如何做到两台数据库中的用户表有唯一主键。
第八版:
     引入服务化
简述一个大型交易网站的发展旅程_第10张图片
       它可以解决两个问题:

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

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

第九版:
      引入消息中间件
      – 解耦
      – 异步   
      三、技术总结     
最后系统的架构:
简述一个大型交易网站的发展旅程_第11张图片
大致总结这个网站的技术发展过程:
1 机器 +1 个应用 +1 一个 DB
应用和 DB 分到两个机器
应用部署多机器,走入集群
DB 读写分离
引入搜索
引入 Cache
引入分布式存储
引入 CDN
数据库垂直拆分
数据库水平拆分
应用的拆分
服务化
引入消息中间件
 

 

     这篇文章来源于自己最近在淘宝参加的一个培训课程——《java中间件》,当中介绍“一个交易网站的旅程”的内容,自己特别收益,所以在它的基础上整理出这篇文章。

你可能感兴趣的:(数据库,应用服务器,session,服务器,internet,消息中间件)