auto commit
This commit is contained in:
CyC2018
parent
2d4df4a9d7
commit
bcb47c8078
203
notes/分布式问题分析.md
203
notes/分布式问题分析.md
|
|
@ -1,29 +1,104 @@
|
|||
<!-- GFM-TOC -->
|
||||
* [一、分布式事务](#一分布式事务)
|
||||
* [本地消息](#本地消息)
|
||||
* [一、分布式锁](#一分布式锁)
|
||||
* [数据库的唯一索引](#数据库的唯一索引)
|
||||
* [Redis 的 SETNX 指令](#redis-的-setnx-指令)
|
||||
* [Redis 的 RedLock 算法](#redis-的-redlock-算法)
|
||||
* [Zookeeper 的有序节点](#zookeeper-的有序节点)
|
||||
* [二、分布式事务](#二分布式事务)
|
||||
* [本地消息表](#本地消息表)
|
||||
* [两阶段提交协议](#两阶段提交协议)
|
||||
* [二、分布式锁](#二分布式锁)
|
||||
* [原理](#原理)
|
||||
* [实现](#实现)
|
||||
* [三、分布式 Session](#三分布式-session)
|
||||
* [Sticky Sessions](#sticky-sessions)
|
||||
* [Session Replication](#session-replication)
|
||||
* [Session Server](#session-server)
|
||||
* [四、负载均衡](#四负载均衡)
|
||||
* [算法](#算法)
|
||||
* [实现](#实现)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、分布式事务
|
||||
# 一、分布式锁
|
||||
|
||||
指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。例如在下单场景下，库存和订单如果不在同一个节点上，就需要涉及分布式事务。
|
||||
在单机场景下，可以使用 Java 提供的内置锁来实现进程同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。
|
||||
|
||||
## 本地消息
|
||||
阻塞锁通常使用互斥量来实现，互斥量为 1 表示有其它进程在使用锁，此时处于锁定状态，互斥量为 0 表示未锁定状态。1 和 0 可以用一个整型值来存储，也可以用某个数据存在或者不存在来存储，某个数据存在表示互斥量为 1。
|
||||
|
||||
## 数据库的唯一索引
|
||||
|
||||
当想要获得锁时，就向表中插入一条记录，释放锁时就删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。
|
||||
|
||||
存在以下几个问题：
|
||||
|
||||
- 锁没有失效时间，解锁失败的话其他线程无法再获得锁。
|
||||
- 只能是非阻塞锁，插入失败直接就报错了，无法重试。
|
||||
- 不可重入，已经获得锁的进程也必须重新获取锁。
|
||||
|
||||
## Redis 的 SETNX 指令
|
||||
|
||||
使用 SETNX（set if not exist）指令插入一个键值对，如果 Key 已经存在，那么会返回 False，否则插入成功并返回 True。
|
||||
|
||||
SETNX 指令和数据库的唯一索引类似，可以保证只存在一个 Key 的键值对，可以用一个 Key 的键值对是否存在来判断是否存于锁定状态。
|
||||
|
||||
EXPIRE 指令可以为一个键值对设置一个过期时间，从而避免了数据库唯一索引实现方式中释放锁失败的问题。
|
||||
|
||||
## Redis 的 RedLock 算法
|
||||
|
||||
使用了多个 Redis 实例来实现分布式锁，这是为了保证在发生单点故障时仍然可用。
|
||||
|
||||
- 尝试从 N 个相互独立 Redis 实例获取锁，如果一个实例不可用，应该尽快尝试下一个。
|
||||
- 计算获取锁消耗的时间，只有当这个时间小于锁的过期时间，并且从大多数（N/2+1）实例上获取了锁，那么就认为锁获取成功了。
|
||||
- 如果锁获取失败，会到每个实例上释放锁。
|
||||
|
||||
## Zookeeper 的有序节点
|
||||
|
||||
### 1. Zookeeper 抽象模型
|
||||
|
||||
Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示它的父节点为 /app1。
|
||||
|
||||
<div align="center"> <img src="../pics//31d99967-1171-448e-8531-bccf5c14cffe.jpg" width="400"/> </div><br>
|
||||
|
||||
### 2. 节点类型
|
||||
|
||||
- 永久节点：不会因为会话结束或者超时而消失；
|
||||
- 临时节点：如果会话结束或者超时就会消失；
|
||||
- 有序节点：会在节点名的后面加一个数字后缀，并且是有序的，例如生成的有序节点为 /lock/node-0000000000，它的下一个有序节点则为 /lock/node-0000000001，以此类推。
|
||||
|
||||
### 3. 监听器
|
||||
|
||||
为一个节点注册监听器，在节点状态发生改变时，会给客户端发送消息。
|
||||
|
||||
### 4. 分布式锁实现
|
||||
|
||||
- 创建一个锁目录 /lock；
|
||||
- 当一个客户端需要获取锁时，在 /lock 下创建临时的且有序的子节点；
|
||||
- 客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁；否则监听自己的前一个子节点，获得子节点的变更通知后重复此步骤直至获得锁；
|
||||
- 执行业务代码，完成后，删除对应的子节点。
|
||||
|
||||
### 5. 会话超时
|
||||
|
||||
如果一个已经获得锁的会话超时了，因为创建的是临时节点，所以该会话对应的临时节点会被删除，其它会话就可以获得锁了。可以看到，Zookeeper 分布式锁不会出现数据库的唯一索引实现分布式锁的释放锁失败问题。
|
||||
|
||||
### 6. 羊群效应
|
||||
|
||||
一个节点未获得锁，需要监听自己的前一个子节点，这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其它所有子节点都会收到通知（羊群效应），而我们只希望它的后一个子节点收到通知。
|
||||
|
||||
参考：
|
||||
|
||||
- [浅谈分布式锁](http://www.linkedkeeper.com/detail/blog.action?bid=1023)
|
||||
- [Distributed locks with Redis](https://redis.io/topics/distlock)
|
||||
- [基于 Zookeeper 的分布式锁](http://www.dengshenyu.com/java/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/10/23/zookeeper-distributed-lock.html)
|
||||
|
||||
# 二、分布式事务
|
||||
|
||||
指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。
|
||||
|
||||
## 本地消息表
|
||||
|
||||
### 1. 原理
|
||||
|
||||
本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性。
|
||||
|
||||
1. 在分布式事务操作的一方，它完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
2. 之后将本地消息表中的消息转发到 Kafka 等消息队列（MQ）中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
|
||||
3. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。
|
||||
|
||||
|
|
@ -35,86 +110,19 @@
|
|||
|
||||
## 两阶段提交协议
|
||||
|
||||
[2PC](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E4%B8%80%E8%87%B4%E6%80%A7.md)
|
||||
[CyC2018/Interview-Notebook/一致性.md/2PC](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E4%B8%80%E8%87%B4%E6%80%A7.md)
|
||||
|
||||
# 二、分布式锁
|
||||
参考：
|
||||
|
||||
可以使用 Java 提供的内置锁来实现进程同步：由 JVM 实现的 synchronized 和 JDK 提供的 Lock。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁来同步。
|
||||
|
||||
## 原理
|
||||
|
||||
锁可以有阻塞锁和乐观锁两种实现方式，这里主要探讨阻塞锁实现。阻塞锁通常使用互斥量来实现，互斥量为 1 表示有其它进程在使用锁，此时处于锁定状态，互斥量为 0 表示未锁定状态。1 和 0 可以用一个整型值来存储，也可以用某个数据存在或者不存在来存储，某个数据存在表示互斥量为 1，也就是锁定状态。
|
||||
|
||||
## 实现
|
||||
|
||||
### 1. 数据库的唯一索引
|
||||
|
||||
当想要获得锁时，就向表中插入一条记录，释放锁时就删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。
|
||||
|
||||
这种方式存在以下几个问题：
|
||||
|
||||
- 锁没有失效时间，解锁失败会导致死锁，其他线程无法再获得锁。
|
||||
- 只能是非阻塞锁，插入失败直接就报错了，无法重试。
|
||||
- 不可重入，同一线程在没有释放锁之前无法再获得锁。
|
||||
|
||||
### 2. Redis 的 SETNX 指令
|
||||
|
||||
使用 SETNX（set if not exist）指令插入一个键值对，如果 Key 已经存在，那么会返回 False，否则插入成功并返回 True。
|
||||
|
||||
SETNX 指令和数据库的唯一索引类似，可以保证只存在一个 Key 的键值对，可以用一个 Key 的键值对是否存在来判断是否存于锁定状态。
|
||||
|
||||
EXPIRE 指令可以为一个键值对设置一个过期时间，从而避免了死锁的发生。
|
||||
|
||||
### 3. Redis 的 RedLock 算法
|
||||
|
||||
使用了多个 Redis 实例来实现分布式锁，这是为了保证在发生单点故障时仍然可用。
|
||||
|
||||
- 尝试从 N 个相互独立 Redis 实例获取锁，如果一个实例不可用，应该尽快尝试下一个。
|
||||
- 计算获取锁消耗的时间，只有当这个时间小于锁的过期时间，并且从大多数（N/2+1）实例上获取了锁，那么就认为锁获取成功了。
|
||||
- 如果锁获取失败，会到每个实例上释放锁。
|
||||
|
||||
### 4. Zookeeper 的有序节点
|
||||
|
||||
Zookeeper 是一个为分布式应用提供一致性服务的软件，例如配置管理、分布式协同以及命名的中心化等，这些都是分布式系统中非常底层而且是必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。
|
||||
|
||||
**（一）抽象模型**
|
||||
|
||||
Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示它的父节点为 /app1。
|
||||
|
||||
<div align="center"> <img src="../pics//31d99967-1171-448e-8531-bccf5c14cffe.jpg" width="400"/> </div><br>
|
||||
|
||||
**（二）节点类型**
|
||||
|
||||
- 永久节点：不会因为会话结束或者超时而消失；
|
||||
- 临时节点：如果会话结束或者超时就会消失；
|
||||
- 有序节点：会在节点名的后面加一个数字后缀，并且是有序的，例如生成的有序节点为 /lock/node-0000000000，它的下一个有序节点则为 /lock/node-0000000001，依次类推。
|
||||
|
||||
**（三）监听器**
|
||||
|
||||
为一个节点注册监听器，在节点状态发生改变时，会给客户端发送消息。
|
||||
|
||||
**（四）分布式锁实现**
|
||||
|
||||
- 创建一个锁目录 /lock；
|
||||
- 在 /lock 下创建临时的且有序的子节点，第一个客户端对应的子节点为 /lock/lock-0000000000，第二个为 /lock/lock-0000000001，以此类推；
|
||||
- 客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁；否则监听自己的前一个子节点，获得子节点的变更通知后重复此步骤直至获得锁；
|
||||
- 执行业务代码，完成后，删除对应的子节点。
|
||||
|
||||
**（五）会话超时**
|
||||
|
||||
如果一个已经获得锁的会话超时了，因为创建的是临时节点，所以该会话对应的临时节点会被删除，其它会话就可以获得锁了。可以看到，Zookeeper 分布式锁不会出现数据库的唯一索引实现分布式锁的死锁问题。
|
||||
|
||||
**（六）羊群效应**
|
||||
|
||||
一个节点未获得锁，需要监听自己的前一个子节点，这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其它所有子节点都会收到通知（羊群效应），而我们只希望它的后一个子节点收到通知。
|
||||
- [聊聊分布式事务，再说说解决方案](https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html)
|
||||
- [分布式系统的事务处理](https://coolshell.cn/articles/10910.html)
|
||||
- [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be)
|
||||
|
||||
# 三、分布式 Session
|
||||
|
||||
在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有用户的 Session，就可能导致用户需要重新进行登录等操作。
|
||||
|
||||
<div align="center"> <img src="../pics//cookiedata.png"/> </div><br>
|
||||
|
||||
### 1. Sticky Sessions
|
||||
## Sticky Sessions
|
||||
|
||||
需要配置负载均衡器，使得一个用户的所有请求都路由到一个服务器节点上，这样就可以把用户的 Session 存放在该服务器节点中。
|
||||
|
||||
|
|
@ -122,25 +130,25 @@ Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示
|
|||
|
||||
<div align="center"> <img src="../pics//MultiNode-StickySessions.jpg"/> </div><br>
|
||||
|
||||
### 2. Session Replication
|
||||
## Session Replication
|
||||
|
||||
在服务器节点之间进行 Session 同步操作，这样的话用户可以访问任何一个服务器节点。
|
||||
|
||||
缺点：需要更好的服务器硬件条件；需要对服务器进行配置。
|
||||
缺点：占用过多内存；同步过程占用网络带宽以及服务器处理器时间。
|
||||
|
||||
<div align="center"> <img src="../pics//MultiNode-SessionReplication.jpg"/> </div><br>
|
||||
|
||||
### 3. Persistent DataStore
|
||||
## Session Server
|
||||
|
||||
将 Session 信息持久化到一个数据库中。
|
||||
使用一个单独的服务器存储 Session 数据，可以存在 MySQL 数据库上，也可以存在 Redis 或者 Memcached 这种内存型数据库。
|
||||
|
||||
缺点：有可能需要去实现存取 Session 的代码。
|
||||
缺点：需要去实现存取 Session 的代码。
|
||||
|
||||
<div align="center"> <img src="../pics//MultiNode-SpringSession.jpg"/> </div><br>
|
||||
|
||||
### 4. In-Memory DataStore
|
||||
参考：
|
||||
|
||||
可以使用 Redis 和 Memcached 这种内存型数据库对 Session 进行存储，可以大大提高 Session 的读写效率。内存型数据库同样可以持久化数据到磁盘中来保证数据的安全性。
|
||||
- [Session Management using Spring Session with JDBC DataStore](https://sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/)
|
||||
|
||||
# 四、负载均衡
|
||||
|
||||
|
|
@ -239,20 +247,9 @@ PAC 服务器是用来判断一个请求是否要经过代理。
|
|||
|
||||
<div align="center"> <img src="../pics//52e1af6f-3a7a-4bee-aa8f-fcb5dacebe40.jpg"/> </div><br>
|
||||
|
||||
|
||||
|
||||
# 参考资料
|
||||
参考：
|
||||
|
||||
- [Comparing Load Balancing Algorithms](http://www.jscape.com/blog/load-balancing-algorithms)
|
||||
- [负载均衡算法及手段](https://segmentfault.com/a/1190000004492447)
|
||||
- [Redirection and Load Balancing](http://slideplayer.com/slide/6599069/#)
|
||||
- [Session Management using Spring Session with JDBC DataStore](https://sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/)
|
||||
- [Apache Wicket User Guide - Reference Documentation](https://ci.apache.org/projects/wicket/guide/6.x/)
|
||||
- [集群/分布式环境下 5 种 Session 处理策略](http://blog.csdn.net/u010028869/article/details/50773174?ref=myread)
|
||||
- [浅谈分布式锁](http://www.linkedkeeper.com/detail/blog.action?bid=1023)
|
||||
- [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be)
|
||||
- [分布式系统的事务处理](https://coolshell.cn/articles/10910.html)
|
||||
- [关于分布式事务](http://blog.csdn.net/suifeng3051/article/details/52691210)
|
||||
- [基于 Zookeeper 的分布式锁](http://www.dengshenyu.com/java/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/10/23/zookeeper-distributed-lock.html)
|
||||
- [微服务场景下的数据一致性解决方案](https://opentalk.upyun.com/310.html)
|
||||
- [聊聊分布式事务，再说说解决方案](https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user