auto commit

notes/分布式问题分析.md

@@ -58,7 +58,7 @@
 
 消息中间件也可称作消息系统 (MQ)，它本质上是一个暂存转发消息的一个中间件。在分布式应用当中，我们可以把一个业务操作转换成一个消息，比如支付宝的余额转入余额宝操作，支付宝系统执行减少余额操作之后向消息系统发送一个消息，余额宝系统订阅这条消息然后进行增加余额宝操作。
 
-#### 2.1 消息处理模型
+**（一）消息处理模型** 
 
 <font size=3> **点对点** </font></br>
 
@@ -68,7 +68,7 @@
 
 <div align="center"> <img src="../pics//654acfed-a6a5-4fc7-8f40-3fdcae57bae8.jpg" width="700"/> </div><br>
 
-#### 2.2 消息的可靠性
+**（二）消息的可靠性** 
 
 消息的发送端的可靠性：发送端完成操作后一定能将消息成功发送到消息系统。
 
@@ -172,7 +172,7 @@ Java 提供了两种内置的锁的实现，一种是由 JVM 实现的 synchroni
 
 ### 1. 数据库分布式锁
 
-#### 1.1 基于 MySQL 锁表
+**（一）基于 MySQL 锁表** 
 
 该实现方式完全依靠数据库唯一索引来实现。当想要获得锁时，就向数据库中插入一条记录，释放锁时就删除这条记录。如果记录具有唯一索引，就不会同时插入同一条记录。这种方式存在以下几个问题：
 
@@ -180,19 +180,19 @@ Java 提供了两种内置的锁的实现，一种是由 JVM 实现的 synchroni
 2. 只能是非阻塞锁，插入失败直接就报错了，无法重试。
 3. 不可重入，同一线程在没有释放锁之前无法再获得锁。
 
-#### 1.2 采用乐观锁增加版本号
+**（二）采用乐观锁增加版本号** 
 
 根据版本号来判断更新之前有没有其他线程更新过，如果被更新过，则获取锁失败。
 
 ### 2. Redis 分布式锁
 
-#### 2.1 基于 SETNX、EXPIRE
+**（一）基于 SETNX、EXPIRE** 
 
 使用 SETNX（set if not exist）命令插入一个键值对时，如果 Key 已经存在，那么会返回 False，否则插入成功并返回 True。因此客户端在尝试获得锁时，先使用 SETNX 向 Redis 中插入一个记录，如果返回 True 表示获得锁，返回 False 表示已经有客户端占用锁。
 
 EXPIRE 可以为一个键值对设置一个过期时间，从而避免了死锁的发生。
 
-#### 2.2 RedLock 算法
+**（二）RedLock 算法** 
 
 ReadLock 算法使用了多个 Redis 实例来实现分布式锁，这是为了保证在发生单点故障时还可用。
 
@@ -204,34 +204,34 @@ ReadLock 算法使用了多个 Redis 实例来实现分布式锁，这是为了
 
 Zookeeper 是一个为分布式应用提供一致性服务的软件，例如配置管理、分布式协同以及命名的中心化等，这些都是分布式系统中非常底层而且是必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。
 
-#### 3.1 抽象模型
+**（一）抽象模型** 
 
 Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示它的父节点为 /app1。
 
 <div align="center"> <img src="../pics//31d99967-1171-448e-8531-bccf5c14cffe.jpg" width="400"/> </div><br>
 
-#### 3.2 节点类型
+**（二）节点类型** 
 
 - 永久节点：不会因为会话结束或者超时而消失；
 - 临时节点：如果会话结束或者超时就会消失；
 - 有序节点：会在节点名的后面加一个数字后缀，并且是有序的，例如生成的有序节点为 /lock/node-0000000000，它的下一个有序节点则为 /lock/node-0000000001，依次类推。
 
-#### 3.3 监听器
+**（三）监听器** 
 
 为一个节点注册监听器，在节点状态发生改变时，会给客户端发送消息。
 
-#### 3.4 分布式锁实现
+**（四）分布式锁实现** 
 
 1. 创建一个锁目录 /lock。
 1. 在 /lock 下创建临时的且有序的子节点，第一个客户端对应的子节点为 /lock/lock-0000000000，第二个为 /lock/lock-0000000001，以此类推。
 2.  客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听自己的前一个子节点，获得子节点的变更通知后重复此步骤直至获得锁；
 3. 执行业务代码，完成后，删除对应的子节点。
 
-#### 3.5 会话超时
+**（五）会话超时** 
 
 如果一个已经获得锁的会话超时了，因为创建的是临时节点，因此该会话对应的临时节点会被删除，其它会话就可以获得锁了。可以看到，Zookeeper 分布式锁不会出现数据库分布式锁的死锁问题。
 
-#### 3.6 羊群效应
+**（六）羊群效应** 
 
 在步骤二，一个节点未获得锁，需要监听监听自己的前一个子节点，这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其它所有子节点都会收到通知，而我们只希望它的下一个子节点收到通知。