关于集群的那些事
集群
-
分布式系统
-
第二章 网络负载均衡策略
- 网络任务分配方案及其实现
-
- 轮转机制及其实现
-
- 加权轮转策略的设计与优化
-
- 最短路径寻址技术解析
-
- 带权重路径规划方法探讨
-
- 随机化任务分配机制研究
-
- IP哈希值随机化方法分析
- 转发实现
-
1. HTTP 重定向
-
2. DNS 域名解析
-
3. 反向代理服务器
-
4. 网络层
-
5. 链路层
-
-
第二章 集群环境中的Session管理
- 持续性会话（Persistent Sessions）
- 会话复制机制（Session Replication）
- 集群式会话服务器（Clustered Session Server）
一、负载均衡
在集群环境中使用stateless架构的应用服务器（节点）通常是常见的做法。
负载均衡器会通过某种机制依据各节点当前的负载状况将用户的请求转发至最合适的位置以平衡资源消耗并提升系统性能
负载均衡器可以用来实现高可用以及伸缩性：
- 高可靠性：在单个服务器发生故障时，在线服务依然能够正常运行；
- 伸缩能力：根据系统的负载状况动态评估并灵活地增减服务器数量以适应业务需求的变化。
负载均衡器运行过程包含两个部分：
- 根据负载均衡算法得到转发的节点；
- 进行转发。
负载均衡算法
1. 轮询（Round Robin）
轮询算法把每个请求轮流发送到每个服务器上。
在下图中所示的情况下，在线共有六个客户端生成了六个请求数值，并按照序列号（1至6）依次提交这些请求数值其中序号为奇数位（即第1、3、5项）的请求数值将被分配至服务器A而偶数位（即第2、4、6项）的请求数值则将被分配至服务器B
该算法特别适用于各个服务器之间在性能上较为接近的情形；在面对不同 performance 水平的情况时，在某些情况下可能会导致那些计算能力受限于 resource allocation 情况的关键节点（如Server 2）难以承受额外负担。
2. 加权轮询（Weighted Round Robbin）
采用加权的方式进行，在基础轮询的基础上，根据各服务器的性能特点给予相应的权重；其中表现越突出的服务器将获得更高的权重。
例如下图所示，在该系统架构中
3. 最少连接（least Connections）
因为每次请求的响应时间各不相同，在采用轮询算法（包括加权轮询）的情况下可能会导致某台服务器同时连接用户数量过多而另一台仅有较少的连接从而导致负载分布不均匀
在如下图所示的情境中，在请求（1、3、5）会被路由分配至服务器1；然而，在不久之后（1、3）就会断开连接关系；此时仅有（5）请求能够保持与服务器1的有效通信；同样地，在请求（2、4、6）被路由分配至服务器2时；但在随后的时间里（2）的连接就会中断；而此时则会重新建立新的连接关系以便接收（6、4）这两个请求；当此系统持续运行下去时；由于未及时扩展资源而导致 server2 必须承担过重的工作负载
最少连接算法就是将请求发送给当前最少连接数的服务器上。
在上文中所述的例子中，在下图中，请注意：服务器 1 目前的连接数处于最低水平。因此，在这种情况下，最新的请求编号为6的用户请求会被分配给服务器 1 进行处理。
4. 加权最少连接（Weighted Least Connection）
基于最少连接的前提下，依据服务器性能为每台服务器进行权重分配，然后通过计算确定每台服务器可处理的连接数量。
5. 随机算法（Random）
把请求随机发送到服务器上。
和轮询算法类似，该算法比较适合服务器性能差不多的场景。
6. 源地址哈希法 (IP Hash)
源地址哈希值通过计算客户端IP的哈希值后,然后用该哈希值对服务器总数取模以确定目标服务器的序号
确保来自同一IP地址的客户端请求会被转发至同一个服务器上，用于实现会话粘滞（Sticky Session）。
转发实现
1. HTTP 重定向
HTTP 重定向负载均衡服务器根据某种负载均衡算法通过某种算法计算得出目标服务器的IP地址，并将其记录于相应的HTTP转义报文中。当客户端接收到此HTTP转义报文后，则需重新向服务器发送请求。
缺点：
- 必须进行两次请求操作才能避免频繁的访问延迟问题；
- 该HTTP负载均衡器的承载能力有限，可能导致集群规模受到限制。
该负载均衡转发的缺点比较明显，实际场景中很少使用它。
2. DNS 域名解析
在 DNS 解析域名的同时使用负载均衡算法计算服务器 IP 地址。
优点：
- DNS 能够根据地理位置进行域名解析，返回离用户最近的服务器 IP 地址。
缺点：
DNS具有分层架构，在各个层级的域名记录都有可能被缓存的情况下，在一个服务器因故停机期间进行修改操作时，其修改操作需经历较长的时间才能生效。
大型网站主要依赖 DNS 作为第一级负载均衡手段；此外，在内部采用其他方式实现第二级负载均衡。具体来说，域名解析的结果是分配给内部负载均衡服务器的 IP 地址。
3. 反向代理服务器
反向代理服务器位于源服务器之前运行，在处理用户请求时需要依次经过反向代理 server后才能传递给源 server。除了缓存和记录日志外，反向 proxy还可以充当负载均衡设备使用
在这种负载均衡转发机制中，在这种机制下的情况下（此处可选择性替换），客户端无需直接访问源服务器这一行为发生时（此处可调整语序），由此导致源服务器本身无需配置外部网络地址这一情况出现（此处可替换词语），而反向代理则必须同时配置内部和外部网络接口的IP地址这一具体要求（此处可优化表达）。
优点：
- 与其它功能集成在一起，部署简单。
缺点：
- 所有请求和响应都需要经过反向代理服务器，它可能会成为性能瓶颈。
4. 网络层
在操作系统内核进程中，通过采集网络数据包的信息并遵循负载均衡算法确定源服务器的IP地址位置后，在请求数据包中将其目的IP地址设置为该源服务器的IP地址位置，并最终完成转发操作。
源服务器返回的响应通常会经历负载均衡服务器的处理，在集群架构中其功能通常表现为在集群架构中扮演网关角色
优点：
- 在内核进程中进行处理，性能比较高。
缺点：
如同反向代理一样，每个请求与响应都会经过负载均衡服务器处理，并将导致性能瓶颈
5. 链路层
基于负载均衡算法，在链路层确定源服务器的MAC地址，并更正请求数据包的目的MAC地址的同时完成转发操作。
通过设置源服务器与负载均衡服务器的虚拟化IP地址保持一致，并因此无需修改IP地址即可实现数据转发功能。这也正是因为两者的IP地址相同特性，在处理响应时源服务器可以直接将数据转发给客户端而不必经过负载均衡服务器这一环节, 从而避免了负载均衡 server成为系统性能瓶颈的问题
这种三角传输模式被命名为直接路由，在为下载和视频服务提供支持的网站中应用广泛。这些网站通过直接路由最大限度地减少了大量的网络传输数据通过负载均衡服务器的情况发生。
当前主流的负载均衡转发方案在Linux平台被广泛应用，并且该技术的核心服务器架构即为LVS（Linux Virtual Server）。
参考：
- Analyzing and Comparing Load Balancing Algorithms
- Exploring Redirection Techniques in the Context of Load Balancing
二、集群下的 Session 管理
该用户的Session信息由于被存储在服务器中而无法直接使用，在这种情况下，负载均衡器将用户的下一个请求路由到另一个服务器时会发现该服务器上缺失了用户的Session信息。因此该用户必须进行注册或其他必要的登录流程以完成操作。
Sticky Session
部署负载均衡器以实现所有来自同一个用户的请求被分配给同一台服务器处理，并使用户的会话数据存储在该服务器上
缺点：
- 当服务器宕机时，将丢失该服务器上的所有 Session。
Session Replication
通过在各个服务器之间实施Session同步操作，在实现这一过程中时下每一个服务器都包含着全部用户的Session信息。这样一来就使得用户能够向任意一个服务器发起请求。
缺点：
- 占用过多内存；
- 同步过程占用网络带宽以及服务器处理器时间。
Session Server
可以选择一个单一的服务器来保存 Session 数据。这将允许我们灵活地采用不同的存储解决方案以适应具体需求。例如，在传统的关系型数据库中选择 MySQL，在非关系型数据库中则可以选择 Redis 或 Memcached 这类内存型数据库。
优点：
为了实现大型网站的弹性扩展能力，在集群架构中，应用服务器设计时通常会采用无状态模式。这意味着这些服务端无法持久化维护客户端的状态信息。通过专门的Session Server组件，系统能够将每个客户端的会话数据独立隔离存放。
缺点：
- 需要去实现存取 Session 的代码。
参考：
Exploring Session Management Techniques with Spring's Utilization and JDBC-Based Data Storage