From deed69f80d88a0442c958ac96f105107d2070b07 Mon Sep 17 00:00:00 2001
From: shengzhang <2393584716@qq.com>
Date: Mon, 8 Feb 2021 20:01:31 +0800
Subject: [PATCH] =?UTF-8?q?=E5=AE=8C=E5=96=84=E9=9B=86=E7=BE=A4=E5=88=86?=
 =?UTF-8?q?=E5=B8=83=E5=BC=8F=E4=B8=8B=E7=9A=84=E8=A7=A3=E5=86=B3=E6=96=B9?=
 =?UTF-8?q?=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 sa-token-doc/doc/senior/dcs.md | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/sa-token-doc/doc/senior/dcs.md b/sa-token-doc/doc/senior/dcs.md
index c0000e2e..b6554ebc 100644
--- a/sa-token-doc/doc/senior/dcs.md
+++ b/sa-token-doc/doc/senior/dcs.md
@@ -1,6 +1,31 @@
 # 集群、分布式
+Sa-token 在集群、分布式下的解决方案
+
+---
+
+
+
+### 分布式下的数据同步问题
+单机版的`Session`在分布式环境下一般不能正常工作，为此我们需要对框架做一些特定的处理。
+
+首先我们要明白，分布式环境下为什么`Session`会失效？因为用户在一个节点对会话做出的更改无法实时同步到其它的节点，
+这就导致一个很严重的问题：如果用户在节点一上已经登录成功，那么当下一次的请求落在节点二上时，对节点二来讲，此用户仍然是未登录状态。
+
+要怎么解决这个问题呢？目前的主流方案有四种：
+1. **Session同步**：只要一个节点的数据发生了改变，就强制同步到其它所有节点 
+2. **Session粘滞**：通过一定的算法，保证一个用户的所有请求都稳定的落在一个节点之上，对这个用户来讲，就好像还是在访问一个单机版的服务
+3. **建立会话中心**：将Session存储在专业的缓存中间件上，使每个节点都变成了无状态服务，例如：`Redis`
+4. **颁发无状态token**：放弃Session机制，将用户数据直接写入到令牌本身上，使会话数据做到令牌自解释，例如：`jwt`
+
+该如何选择一个合适的方案？
+- 方案一：性能消耗太大，不太考虑
+- 方案二：需要从网关处动手，与框架无关
+- 方案三：sa-token整合`Redis`非常简单，详见章节[持久层扩展](use/dao-extend)
+- 方案四：详见官方仓库中sa-token整合jwt的示例
+
+由于jwt模式不在服务端存储数据，对于比较复杂的业务可能会功能受限，因此更加推荐使用方案三
+
 
-集群模式下，