以淘宝为例，解析大型电商服务端架构！( 二 ) _架构

Session 共享解决方案session sticky我们使用 session sticky这种方式来解决这个问题，它的处理规则是对于同一个连接中的数据包，负载均衡会将其进行 NAT 转换后，转发至后端固定的服务器进行处理，这种方案解决了 session 共享的问题。
如图所示客户端 1 通过负载均衡会固定转发到服务器 1 中。缺点是第一假设有一台服务器重启了，那么该服务器的 session 将全部消失，第二是我们的负载均衡服务器成了一种有状态的服务器，要实现容灾会有麻烦。

文章插图

session 复制session 复制，即当 browser1 经过负载均衡服务器把 session 存到 application1 中，会同时把 session 复制到 application2 中，所以多台服务器都保存着相同的 session 信息。
缺点是应用服务器的带宽问题，服务器之间要不断同步 session 信息，当大量用户在线时，服务器占用内存会过多，不适合大规则集群，适合机器不多情况。

文章插图

基于 cookie基于 cookie，也就是说我们每次都用携带 session 信息的 cookie 去访问应用服务器。缺点是 cookie 的长度是有限制的，cookie 保存在浏览器上安全性也是一个问题。

文章插图

session 服务器把 session 做成了一个 session 服务器，比如可以使用 redis 实现。这样每个用户访问到应用服务器，其 session 信息最终都存到 session server 中，应用服务器也是从 session server 中去获取 session 。
要考虑以下几个问题，在当前架构中 session server 是一个单点的，如何解决单点，保证它的可用性，当然也可以将 session server 做成一个集群，这种方式适用于 session 数量及 web 服务器数量大的情况，同时改成这种架构后，在写应用时，也要调整存储 session 的业务逻辑。

文章插图

数据库读写分离在解决了服务器横向扩展之后，继续看数据库，数据库的读与写操作都需要经过数据库，当用户量达到一定量时，数据库性能又成为了一个瓶颈，我们继续演进。
我们可以使用数据库的读写分离，同时应用要接入多数据源。通过统一的数据访问模型进行访问。数据库的读写分离是将所有的写操作引入到主库中 (master)，将读操作引入到从库中 (slave)，此时应用程序也要做出相应的变化，我们实现了一个数据访问模块 (data accessmodule)，使上层写代码的人不知道读写分离的存在，这样多数据源的读写对业务代码就没有侵入，这就是代码层面的演变。
如何支持多数据源，如何封装对业务没有侵入，如何使用目前业务使用的 ORM 框架完成主从的读写分离，是否需要更换 ORM，各有什么优缺点，如何取舍都是当前这个架构需要考虑的问题。当访问量过大时候，也就是说数据库的 IO 非常大，我们的数据库读写分离又会遇到以下问题？
例如主库和从库复制有没有延迟，如果我们将主库和从库分机房部署的话，跨机房传输同步数据更是一个问题。另外应用对数据源的路由问题，这些也是需要思考和解决的点。