读书笔记: 大型网站系统与Java中间件实践(2)

2 大型网站架构演进

大型网站并不是单指访问量大的网站，如某些导航网站访问量很大，但却并不是大型网站。大型网站一般指有海量的数据，高并发的访问量，同时本身的业务和系统的复杂度也较高。

2.1 大型网站的架构演进

简单的系统，可能仅仅只需要一个服务器，将应用系统和数据库放在同一个服务器上。随着访问量增大，服务器压力上升，需要将应用系统和数据库分离开，分别放在应用服务器和数据库服务器上。当系统进一步发展，单台应用服务器可能无法承受负载压力，此时需要将应用服务器从单台服务器扩展为集群。演进过程如下图所示：

2.1.1 分布式session

应用服务器从单机变为集群之后，一个请求进来之后交由集群中的哪一台机器进行处理，涉及到请求路由和负载均衡，可通过负载均衡软件或服务注册中心解决。同时，集群环境也带来了分布式session问题。分布式session有以下几种解决方案。

Session Sticky

这种解决方案是在负载均衡器上做了处理，将同样session的请求每次都发送到同一个服务器上。此种方式带来的问题是：如果某台服务器宕机或重启，这台服务器中的session就会丢失，如果session中保存有用户的登录状态数据，那么用户就需要重新登录。

Session Replication

这种方式在每一台服务器上复制session。这样来自用一个用户的请求，不管是发送到哪一台服务器上，都能找到该用户的session。 但问题是同步session数据带来了网络带宽的消耗，另外也需要消耗更多的内存，在每一台服务器上保存同样的session。

Session集中存储

这种方式是将session集中存储起来，如保存到分布式缓存服务器上或持久化到数据库中。当web服务器使用Session数据时，从这个集中存储session数据的地方来读取。此种方案存在的问题是，如果几种存储Session的机器或集群宕机，就会影响应用。

Cookie Based

这种方案是将Session数据方法放到Cookie中，然后在Web服务器上从Cookie中生成对应的Session数据。但问题是一来Cookie存在安全方面的问题，而是Cookie数据长度是有限制的。
在实际中，大部分情况都会采用Session集中存储的解决方案，另一篇文章中也提到过分布式session解决方案-分布式缓存。

2.1.2 数据库读写分离

当数据库压力大时，可对数据库进行读写分离。这会带来两个问题：一是数据复制，而二是数据源的选择。

对于数据复制，数据库系统一般都提供了此功能，可以直接使用，如mysql的主从复制。但数据复制也存在着时延，在某些场景下可能会出现主库和从库数据不一致的问题。

读写分离之后，写操作需要选择写库，读操作需要选择读库，带来了数据源的选择问题。

2.1.3 搜索引擎

当根据商品关键字搜索商品，或其他模糊查询时，使用SQL查询代价是很大的。更好的方式是引入垂直化搜索引擎。

2.1.4 其他分布式系统基础设施

本章还大概介绍了分布式缓存，持久化存储方案扩展，消息中间件等。整体上介绍得比较散，内容都属于分布式系统的基础设施。这些内容在博主的另一篇读书笔记(分布式系统基础设施)中都有介绍，而且集中一些，这里不再重复。