diff --git a/notes/集群.md b/notes/集群.md
index 2cc3a7c8..32588068 100644
--- a/notes/集群.md
+++ b/notes/集群.md
@@ -4,8 +4,8 @@
     * [一、负载均衡](#一负载均衡)
         * [负载均衡算法](#负载均衡算法)
             * [1. 轮询（Round Robin）](#1-轮询round-robin)
-            * [2. 加权轮询（Weighted Round Robbin）](#2-加权轮询weighted-round-robbin)
-            * [3. 最少连接（least Connections）](#3-最少连接least-connections)
+            * [2. 加权轮询（Weighted Round Robin）](#2-加权轮询weighted-round-robin)
+            * [3. 最少连接（Least Connections）](#3-最少连接least-connections)
             * [4. 加权最少连接（Weighted Least Connection）](#4-加权最少连接weighted-least-connection)
             * [5. 随机算法（Random）](#5-随机算法random)
             * [6. 源地址哈希法 (IP Hash)](#6-源地址哈希法-ip-hash)
@@ -19,6 +19,7 @@
         * [Sticky Session](#sticky-session)
         * [Session Replication](#session-replication)
         * [Session Server](#session-server)
+        * [客户端保存](#客户端保存)
 <!-- GFM-TOC -->
 
 
@@ -30,7 +31,7 @@
 
 负载均衡器可以用来实现高可用以及伸缩性：
 
-- 高可用：当某个节点故障时，负载均衡器会将用户请求转发到另外的节点上，从而保证所有服务持续可用；
+- 高可用：负载均衡器通过健康检查发现某个节点故障时，会将用户请求转发到另外的节点上，从而保证所有服务持续可用；
 - 伸缩性：根据系统整体负载情况，可以很容易地添加或移除节点。
 
 负载均衡器运行过程包含两个部分：
@@ -53,7 +54,7 @@
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/bfea8772-d01b-4a51-8adc-edfd7d3dce84.jpg" width="500px"/> </div><br>
 
-#### 2. 加权轮询（Weighted Round Robbin）
+#### 2. 加权轮询（Weighted Round Robin）
 
 加权轮询是在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值，性能高的服务器分配更高的权值。
 
@@ -61,7 +62,9 @@
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/4ab87717-e264-4232-825d-8aaf08f14e8b.jpg" width="500px"/> </div><br>
 
-#### 3. 最少连接（least Connections）
+实际实现（例如 Nginx 的平滑加权轮询）会把请求交错发送，避免连续的请求集中到同一台服务器上。
+
+#### 3. 最少连接（Least Connections）
 
 由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数过大，而另一台服务器的连接过小，造成负载不均衡。
 
@@ -77,7 +80,7 @@
 
 #### 4. 加权最少连接（Weighted Least Connection）
 
-在最少连接的基础上，根据服务器的性能为每台服务器分配权重，再根据权重计算出每台服务器能处理的连接数。
+在最少连接的基础上，根据服务器的性能为每台服务器分配权重，将请求发送给“当前连接数 / 权重”最小的服务器。
 
 #### 5. 随机算法（Random）
 
@@ -91,10 +94,12 @@
 
 源地址哈希通过对客户端 IP 计算哈希值之后，再对服务器数量取模得到目标服务器的序号。
 
-可以保证同一 IP 的客户端的请求会转发到同一台服务器上，用来实现会话粘滞（Sticky Session）
+可以保证同一 IP 的客户端的请求会转发到同一台服务器上，用来实现会话粘滞（Sticky Session）。
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/0f399a9f-1351-4b2d-b8a4-2ebe82b1a703.jpg" width="500px"/> </div><br>
 
+缺点是同一出口 IP 后面的大量用户会落到同一台服务器上，造成负载不均；服务器数量变化时取模结果会全部改变，可以改用一致性哈希。
+
 ### 转发实现
 
 #### 1. HTTP 重定向
@@ -132,6 +137,8 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 
 在这种负载均衡转发方式下，客户端不直接请求源服务器，因此源服务器不需要外部 IP 地址，而反向代理需要配置内部和外部两套 IP 地址。
 
+反向代理工作在应用层，属于七层负载均衡，可以根据 URL、Cookie 等内容进行转发，常用的有 Nginx、HAProxy。
+
 优点：
 
 - 与其它功能集成在一起，部署简单。
@@ -144,7 +151,7 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 
 在操作系统内核进程获取网络数据包，根据负载均衡算法计算源服务器的 IP 地址，并修改请求数据包的目的 IP 地址，最后进行转发。
 
-源服务器返回的响应也需要经过负载均衡服务器，通常是让负载均衡服务器同时作为集群的网关服务器来实现。
+源服务器返回的响应也需要经过负载均衡服务器，通常是让负载均衡服务器同时作为集群的网关服务器来实现。对应 LVS 的 NAT 模式。
 
 优点：
 
@@ -158,11 +165,11 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 
 在链路层根据负载均衡算法计算源服务器的 MAC 地址，并修改请求数据包的目的 MAC 地址，并进行转发。
 
-通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致，从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样，所以源服务器的响应不需要转发回负载均衡服务器，可以直接转发给客户端，避免了负载均衡服务器的成为瓶颈。
+通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致，从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样，所以源服务器的响应不需要转发回负载均衡服务器，可以直接转发给客户端，避免了负载均衡服务器成为瓶颈。
 
-这是一种三角传输模式，被称为直接路由。对于提供下载和视频服务的网站来说，直接路由避免了大量的网络传输数据经过负载均衡服务器。
+这是一种三角传输模式，被称为直接路由，对应 LVS 的 DR 模式，要求源服务器和负载均衡服务器位于同一个局域网内。对于提供下载和视频服务的网站来说，直接路由避免了大量的网络传输数据经过负载均衡服务器。
 
-这是目前大型网站使用最广负载均衡转发方式，在 Linux 平台可以使用的负载均衡服务器为 LVS（Linux Virtual Server）。
+网络层和链路层的方式不解析应用层协议，属于四层负载均衡。链路层是目前大型网站使用最广的负载均衡转发方式，在 Linux 平台可以使用的负载均衡服务器为 LVS（Linux Virtual Server），通常用 LVS 做四层负载均衡，再用 Nginx 做七层负载均衡。
 
 参考：
 
@@ -179,7 +186,8 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 
 缺点：
 
-- 当服务器宕机时，将丢失该服务器上的所有 Session。
+- 当服务器宕机时，将丢失该服务器上的所有 Session；
+- 服务器不再是无状态的，不利于伸缩。
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1623f524-b011-40c8-b83f-eab38d538f76.png" width="400px"/> </div><br>
 
@@ -190,13 +198,13 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 缺点：
 
 - 占用过多内存；
-- 同步过程占用网络带宽以及服务器处理器时间。
+- 同步过程占用网络带宽以及服务器处理器时间，因此只适合规模很小的集群。
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/40c6570d-c1d7-4c38-843e-ba991b2328c2.png" width="400px"/> </div><br>
 
 ### Session Server
 
-使用一个单独的服务器存储 Session 数据，可以使用传统的 MySQL，也使用 Redis 或者 Memcached 这种内存型数据库。
+使用一个单独的服务器存储 Session 数据，可以使用传统的 MySQL，也可以使用 Redis 或者 Memcached 这种内存型数据库。
 
 优点：
 
@@ -204,10 +212,21 @@ HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服
 
 缺点：
 
-- 需要去实现存取 Session 的代码。
+- 需要去实现存取 Session 的代码（Spring Session 等框架已经封装）；
+- Session Server 本身需要保证高可用。
+
+这是目前最常用的方式。
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/fdc45a09-f838-4348-8959-d2c793727788.png" width="600px"/> </div><br>
 
+### 客户端保存
+
+把用户信息签名后放在 Cookie 或者 JWT 中，由客户端保存，服务端只需要验证签名。
+
+缺点：
+
+- 无法主动让某个会话失效。
+
 参考：
 
 - [Session Management using Spring Session with JDBC DataStore](https://sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/)