从0到1，Java Web网站架构搭建的技术演进(4)

02、分布式 Session

大家都知道，服务一般分为有状态和无状态，而分布式 Session 就是针对有状态的服务。

分布式 Session 的几种实现方式：

• 基于数据库的 Session 共享。

• 基于 resin/tomcat web 容器本身的 Session 复制机制。

• 基于 oscache/Redis/memcached 进行 Session 共享。

• 基于 cookie 进行 Session 共享。

分布式 Session 的几种管理方式：

• Session Replication 方式管理 (即 Session 复制)。

  简介：将一台机器上的 Session 数据广播复制到集群中其余机器上。

  使用场景：机器较少，网络流量较小。

  优点：实现简单、配置较少、当网络中有机器 Down 掉时不影响用户访问。

  缺点：广播式复制到其余机器有一定延时，带来一定网络开销。

• Session Sticky 方式管理。

  简介：即粘性 Session、当用户访问集群中某台机器后，强制指定后续所有请求均落到此机器上。

  使用场景：机器数适中、对稳定性要求不是非常苛刻。

  优点：实现简单、配置方便、没有额外网络开销。

  缺点：网络中有机器 Down 掉时，用户 Session 会丢失、容易造成单点故障。

• 缓存集中式管理。

  简介：将 Session 存入分布式缓存集群中的某台机器上，当用户访问不同节点时先从缓存中拿 Session 信息。

  使用场景：集群中机器数多、网络环境复杂。

  优点：可靠性好。

  缺点：实现复杂，稳定性依赖于缓存的稳定性、Session 信息放入缓存时要有合理的策略写入。

目前生产中使用到的：

• 基于 Tomcat 配置实现的 Mem Cache 缓存管理 Session 实现(麻烦)。

• 基于 Os Cache 和 shiro 组播的方式实现(网络影响)。

• 基于 Spring-Session+Redis 的方式实现(最适合)。

03、负载均衡策略

负载均衡策略的优劣及其实现的难易程度有两个关键因素：负载均衡算法，对网络系统状况的检测方式和能力。

rr 轮询调度算法

顾名思义，轮询分发请求。优点是实现简单，缺点是不考虑每台服务器的处理能力。

wrr 加权调度算法

我们给每个服务器设置权值 weight，负载均衡调度器根据权值调度服务器，服务器被调用的次数跟权值成正比。优点是考虑了服务器处理能力的不同。

sh 原地址散列

提取用户 IP，根据散列函数得出一个 key，再根据静态映射表，查出对应的 value，即目标服务器 IP。一单目标机器超负荷，则返回空。

dh 目标地址散列

同上，只是现在提取的是目标地址的 IP 来做哈希。优点是以上两种算法都能实现同一个用户访问同一个服务器。

lc 最少连接

优先把请求转发给连接数少的服务器。优点是使得集群中各个服务器的负载更加均匀。

wlc 加权最少连接

在 lc 的基础上，为每台服务器加上权值。算法为：（活动连接数*256+非活动连接数）÷权重 ，计算出来的值小的服务器优先被选择。优点是可以根据服务器的能力分配请求。

sed 最短期望延迟

sed 跟 wlc 类似，区别是不考虑非活动连接数。算法为：（活动连接数+1)*256÷权重，同样计算出来的值小的服务器优先被选择。

nq 永不排队

改进的 sed 算法，我们想一下什么情况下才能“永不排队”，那就是服务器的连接数为 0 的时候，那么假如有服务器连接数为 0，均衡器直接把请求转发给它，无需经过 sed 的计算。

LBLC 基于局部性的最少连接

均衡器根据请求的目的 IP 地址，找出该 IP 地址最近被使用的服务器，把请求转发之，若该服务器超载，则采用最少连接数算法。

LBLCR 带复制的基于局部性的最少连接

均衡器根据请求的目的 IP 地址，找出该 IP 地址最近使用的“服务器组”，注意，这里不是具体某个服务器，然后采用最少连接数算法，从该组中挑出具体的某台服务器出来，把请求转发之。

若该服务器超载，那么根据最少连接数算法，从在集群的非本服务器组的服务器中，找出一台服务器出来，加入本服务器组，然后把请求转发之。

读写分离

MySQL 主从配置，读写分离并引入中间件，开源的 MyCat，阿里的 DRDS 都是不错的选择。

如果是对高可用要求比较高，但是又没有相应的技术保障，建议使用阿里云的 RDS 或者 Redis 相关数据库，省事省力又省钱。

全文检索

如果有搜索业务需求，引入 solr 或者 elasticsearch 也是一个不错的选择，不要什么都塞进关系型数据库。

缓存优化

引入缓存无非是为了减轻后端数据库服务的压力，防止其"罢工"。