大型网站架构演进过程

大型网站：访问量大，数据量大，业务系统的复杂度也是考量范围，

www.alexa.com 可以查询不同网站的访问量

演进过程：

1、java+单机构建网站

lamp，MVC框架，jsp，spring，struts，hibernate，html，css，JavaScript，python等，采用开源server做容器，直接使用jsp、servlet或者一些开源框架构建我们的应用，选择一个数据库管理数据，用jdbc进行数据库的连接和操作，这样一个最基本的环境就搭建好了。应用server是通过jvm内部方法进行交互的，数据库是通过jdbc进行访问的

2、负载大了，数据库和应用分离

这一步很自然，原来也是用jdbc进行数据沟通的，现在只是在应用配置的时候把数据库的地址从本机改到另一台主机上。

3、负载还是很大，让应用服务器集群化

面临的问题：1、用户对应用服务器的选择问题，可以用dns解决，也可以在服务器集群前面加上负载均衡设备来解决；2、session问题

session问题（http协议支持会话状态机制，多次http请求要能看到session，在浏览器和应用服务器的多次交互中保持用户状态，在浏览器中session保存着cookie中）的解决：

主要有四种方法，1、session sticky  ：session保存在单服务器，以后的请求也由这个单机处理，要求负载均衡器根据请求的会话标识进行请求转发。问题：1、服务器宕机，session记录会丢失用户会要求重新登录，2、会话标识属于第七层的应用，要进行应用层解析，开销比第四层大，3、负载均衡器变成一个有状态的节点，要保存session和应用服务器的映射，内存消耗大，和无状态的节点相比，容灾方面更麻烦。相当于选择在哪个饭店吃饭，筷子就放在那个饭店了，下次就一直在那了。

2、ssession replication ：session同步到所有应用服务器，同步session造成网络带宽的开销，内存占用，如果很多会话内存占用很恐怖

3、session数据集中存储：用一个集中存储装置保存所有session数据，所有应用服务器共享读取，问题，访问延时和不稳定，而且是集中存储，单点故障隐患

4、把session存在cookie里面，每次http请求用cookie传，问题：cookie长度限制，安全性，带宽消耗，性能影响

一般情况下13用的最多

4、数据读压力大，读写分离

因为大多数数据请求都是读请求，所以读写分离比较好，但是带来数据复制的问题和数据源选择的问题，数据复制不同的数据库都是有支持的，但是相对有限。读写分离要求写和事物访问走主库，一般的读走读库。

搜索引擎是读库，由数据库构建的索引，供查询使用，构建搜索引擎分为全量增量划分，和实时非实时划分

5、缓存加速数据读取：

1、数据缓存：cache存热数据，lru淘汰

2、页面缓存：esi就是此种应用的一个范例

命中率很重要，扩容和缩容的平滑性很重要，一致性hash是个好方法。

6、弥补关系型数据库的不足，引入分布式存储系统

由格式度由若到强分为分布式文件系统，分布式key-value系统和分布式数据库，分布式存储系统主要是代替主库，通过集群实现一个高容量，高并发访问，数据冗余容灾支持。

7、数据量大，数据库拆分

垂直拆分：把交易、商品、用户等数据库拆分，问题：跨业务事物处理

水平拆分：到上限的表拆分成两个，sql路由，主键处理

8、应用拆分

把各种不相干的应用拆分，比如拆分成用户，商户，登录等应用。缺点很大

服务化：web服务拆分，中间的服务中心支出web服务。这样web专注与交互，服务中心负责业务逻辑和数据连接