docs: 更新文档

Author: dunwu

README.md

@@ -553,7 +553,6 @@
 ##### [RocketMQ](docs/15.分布式/分布式通信/MQ/RocketMQ)
 
 - [RocketMQ 快速入门](docs/15.分布式/分布式通信/MQ/RocketMQ/RocketMQ_快速入门.md)
-- [RocketMQ 基本原理](docs/15.分布式/分布式通信/MQ/RocketMQ/RocketMQ_原理.md)
 - [RocketMQ 面试](docs/15.分布式/分布式通信/MQ/RocketMQ/RocketMQ_面试.md) 💯
 
 ### [分布式存储](docs/15.分布式/分布式存储)

assets/分布式/分布式协同/分布式协同.xmind

@@ -701,7 +701,9 @@ Java 中线程共有六种状态：
 
 ### 方法是如何被执行的
 
-![](https://raw.githubusercontent.com/dunwu/images/master/snap/202408270751420.png)“CPU 去哪里找到调用方法的参数和返回地址？
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/202408270751420.png)
+
+CPU 去哪里找到调用方法的参数和返回地址？
 
 **通过 CPU 的堆栈寄存器**。CPU 支持一种栈结构，先入后出。因为这个栈是和方法调用相关的，因此经常被称为**调用栈**。
 
@@ -767,4 +769,4 @@ Java 中线程共有六种状态：
 
 ## 参考资料
 
-- [极客时间教程 - Java 并发编程实战](https://time.geekbang.org/column/intro/100023901)
+- [极客时间教程 - Java 并发编程实战](https://time.geekbang.org/column/intro/100023901)

assets/分布式/分布式通信/mq/Kafka.xmind

@@ -601,7 +601,7 @@ JDK6 以前，由于 synchronized 阻塞度高，导致性能不佳。JDK6 对
 
 Mark Word 记录了对象和锁有关的信息。Mark Word 在 64 位 JVM 中的长度是 64bit，我们可以一起看下 64 位 JVM 的存储结构是怎么样的。如下图所示：
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20200629191250.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20200629191250.png)
 
 锁升级功能主要依赖于 Mark Word 中的锁标志位和释放偏向锁标志位，`synchronized` 同步锁就是从偏向锁开始的，随着竞争越来越激烈，偏向锁升级到轻量级锁，最终升级到重量级锁。
 
@@ -1432,4 +1432,4 @@ UUID
 
 ## 参考资料
 
-- [极客时间教程 - Java 核心技术面试精讲](https://time.geekbang.org/column/intro/82) - 极客时间教程——从面试官视角梳理如何解答常见 Java 面试问题
+- [极客时间教程 - Java 核心技术面试精讲](https://time.geekbang.org/column/intro/82) - 极客时间教程——从面试官视角梳理如何解答常见 Java 面试问题

assets/分布式/分布式通信/mq/MQ.xmind

@@ -39,11 +39,11 @@ permalink: /pages/76e8b6af/
 
 ## 大厂面试题：你不得不掌握的 JVM 内存管理
 
-![img](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjWAPqAuAARqnz6cigo666.png)
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjWAPqAuAARqnz6cigo666.png)
 
-![img](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjaANruFAAQKxZvgfSs652.png)
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjaANruFAAQKxZvgfSs652.png)
 
-![img](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjaAIlgaAAJKReuKXII670.png)
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e6%b5%85%e5%87%ba%20Java%20%e8%99%9a%e6%8b%9f%e6%9c%ba-%e5%ae%8c/assets/Cgq2xl4VrjaAIlgaAAJKReuKXII670.png)
 
 ## 大厂面试题：从覆盖 JDK 的类开始掌握类的加载机制
 
@@ -201,4 +201,4 @@ MAT 是用来分析内存快照的。
 
 ## 未来：JVM 的历史与展望
 
-## 福利：常见 JVM 面试题补充
+## 福利：常见 JVM 面试题补充

assets/分布式/分布式通信/mq/RocketMQ.xmind

@@ -36,7 +36,7 @@ permalink: /pages/0c17c64c/
 2. 其他副本则全部称为从副本（或称为从节点）。主副本把新数据写入本地存储后，然后将数据更改作为复制的日志或更改流发送给所有从副本。每个从副本获得更改日志之后将其应用到本地，且严格保持与主副本相同的写入顺序。
 3. 客户端从数据库中读数据时，可以在主副本或者从副本上执行查询。再次强调，只有主副本才可以接受写请求：从客户端的角度来看，从副本都是只读的。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302202101.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302202101.png)
 
 支持主从复制的案例：
 
@@ -49,7 +49,7 @@ permalink: /pages/0c17c64c/
 复制的基本流程是，客户将更新请求发送给主节点，主节点接收到请求，接下来将数据更新转发给从节点。最后，由
 主节点来通知客户更新完成。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302202158.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302202158.png)
 
 通常情况下， 复制速度会非常快，例如多数数据库系统可以在一秒之内完成所有从节点的更新。但是，系统其
 实并没有保证一定会在多长时间内完成复制。有些情况下，从节点可能落后主节点几分钟甚至更长时间，例如，由于从节点刚从故障中恢复，或者系统已经接近最大设计上限，或者节点之间的网络出现问题。
@@ -165,7 +165,7 @@ PostgreSQL 、Oracle 以及其他系统等支持这种复制方式。其主要
 
 然而对于异步复制存在这样一个问题，用户在写入不久即查看数据，则新数据可能尚未到达从节点。对用户来讲， 看起来似乎是刚刚提交的数据丢失了。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302204836.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220302204836.png)
 
 对于这种情况，我们需要强一致性。如何实现呢？有以下方案：
 
@@ -181,7 +181,7 @@ PostgreSQL 、Oracle 以及其他系统等支持这种复制方式。其主要
 
 #### 单调读
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303093658.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303093658.png)
 
 假设用户从不同副本进行了多次读取，可能会出现：用户看到了最新内容之后又读到了过期的内容，好像时间被回拨， 此时需要单调读一致性。
 
@@ -364,7 +364,7 @@ PostgreSQL 、Oracle 以及其他系统等支持这种复制方式。其主要
 
 一且找到合适的关键宇哈希函数，就可以为每个分区分配一个哈希范围（而不是直接作用于关键宇范围），关键字根据其哈希值的范围划分到不同的分区中。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303105925.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303105925.png)
 
 这种方总可以很好地将关键字均匀地分配到多个分区中。分区边界可以是均匀间隔，也可以是伪随机选择（ 在这种情况下，该技术有时被称为**一致性哈希**） 。
 
@@ -388,7 +388,7 @@ Cassandra 中的表可以声明为由多个列组成的复合主键。复合主
 
 #### 基于文档分区的二级索引
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303111528.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303111528.png)
 
 在这种索引方法中，每个分区完全独立，各自维护自己的二级索引，且只负责自己分区内的文档而不关心其他分区中数据。每当需要写数据库时，包括添加，删除或更新文档等，只需要处理包含目标文档 ID 的那一个分区。因此文档分区索引也被称为本地索引，而不是全局索引。
 
@@ -400,7 +400,7 @@ Cassandra 中的表可以声明为由多个列组成的复合主键。复合主
 
 为避免成为瓶颈，不能将全局索引存储在一个节点上，否则就破坏了设计分区均衡的目标。所以，**全局索引也必须进行分区**，且可以与数据关键字采用不同的分区策略。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303112708.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220303112708.png)
 
 可以直接通过关键词来全局划分索引，或者对其取哈希值。直接分区的好处是可以支持高效的区间查询；而采用哈希的方式则可以更均匀的划分分区。
 
@@ -473,11 +473,11 @@ Cassandra 和 Ketama 则采用了第三种方式，使分区数与集群节点
 2. 将所有客户端的请求都发送到一个路由层，由后者负责将请求转发到对应的分区节点上。路由层本身不处理任何请求，它仅充一个分区感知的负载均衡器。
 3. 客户端感知分区和节点分配关系。此时，客户端可以直接连接到目标节点，而不需要任何中介。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220304120137.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220304120137.png)
 
 许多分布式数据系统依靠独立的协调服务（如 ZooKeeper ）跟踪集群范围内的元数据。每个节点都向 ZooKeeper 中注册自己， ZooKeeper 维护了分区到节点的最终映射关系。其他参与者（如路由层或分区感知的客户端）可以向 ZooKeeper 订阅此信息。一旦分区发生了改变，或者添加、删除节点， ZooKeeper 就会主动通知路由层，这样使路由信息保持最新状态。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20220304163629.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20220304163629.png)
 
 Linkedln的Espresso使用 Helix进行集群管理（底层是ZooKeeper ）， 实现了请求路由 层。 HBase, SolrCloud和Kafka也使用 ZooKeeper来跟踪分区分配情况 。 MongoDB有类似的设计，但它依赖于自己的配置服务器和mongos守护进程来充当路由层。
 
@@ -537,4 +537,4 @@ ACID，分别代表原子性（ Atomicity ）， 一致性（ Consistency ），
 
 ## 参考资料
 
-- [**数据密集型应用系统设计**](https://book.douban.com/subject/30329536/) - 这可能是目前最好的分布式存储书籍，强力推荐【进阶】
+- [**数据密集型应用系统设计**](https://book.douban.com/subject/30329536/) - 这可能是目前最好的分布式存储书籍，强力推荐【进阶】

docs/00.笔记/Java/极客时间教程-Java并发编程实战笔记一.md

@@ -36,7 +36,7 @@ permalink: /pages/7c7c58f9/
 
 上述的故事可以映射到分布式系统中，_将军代表分布式系统中的节点；信使代表通信系统；叛徒代表故障或异常_。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704104211.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704104211.png)
 
 ### 问题分析
 
@@ -52,13 +52,13 @@ permalink: /pages/7c7c58f9/
 
 **示例一、叛徒人数为 1，将军人数为 3**
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704112012.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704112012.png)
 
 这个示例中，将军人数不满足 3m + 1，无法保证忠诚的副官都执行将军的命令。
 
 **示例二、叛徒人数为 1，将军人数为 4**
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704194815.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20210704194815.png)
 
 这个示例中，将军人数满足 3m + 1，无论是副官中有叛徒，还是将军是叛徒，都能保证忠诚的副官执行将军的命令。
 
@@ -95,7 +95,7 @@ ACID 特性：
   - 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
   - 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/cs/database/RDB/数据库ACID.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/cs/database/RDB/数据库ACID.png)
 
 在分布式系统中实现 ACID 比单机复杂的多。
 
@@ -120,7 +120,7 @@ BASE 特性
 - **软状态（Soft State）**：指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在延时。
 - **最终一致性（Eventually Consistent）**：最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致的状态。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/cs/design/architecture/%E5%88%86%E5%B8%83%E5%BC%8F%E7%90%86%E8%AE%BA-BASE.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/cs/design/architecture/%E5%88%86%E5%B8%83%E5%BC%8F%E7%90%86%E8%AE%BA-BASE.png)
 
 ## Paxos 算法
 
@@ -139,7 +139,7 @@ Paxos 算法运行在允许宕机故障的异步系统中，不要求可靠的
 
 #### 角色
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210528150700.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20210528150700.png)
 
 - **提议者（Proposer）**：发出提案（Proposal），用于投票表决。Proposal 信息包括提案编号 (Proposal ID) 和提议的值 (Value)。在绝大多数场景中，集群中收到客户端请求的节点，才是提议者。这样做的好处是，对业务代码没有入侵性，也就是说，我们不需要在业务代码中实现算法逻辑。
 - **决策者（Acceptor）**：对每个 Proposal 进行投票，若 Proposal 获得多数 Acceptor 的接受，则称该 Proposal 被批准。一般来说，集群中的所有节点都在扮演决策者的角色，参与共识协商，并接受和存储数据。
@@ -220,7 +220,7 @@ Raft 将一致性问题分解成了三个子问题：
 - **`Follower`** - 跟随者，**不会发送任何请求**，只是简单的 **响应来自 Leader 或者 Candidate 的请求**。
 - **`Candidate`** - 参选者，选举新 Leader 时的临时角色。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20200131215742.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20200131215742.png)
 
 > :bulb: 图示说明：
 >
@@ -230,7 +230,7 @@ Raft 将一致性问题分解成了三个子问题：
 
 #### 任期
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20200131220742.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20200131220742.png)
 
 Raft 把时间分割成任意长度的 **_`任期（Term）`_**，任期用连续的整数标记。每一段任期从一次**选举**开始。**Raft 保证了在一个给定的任期内，最多只有一个领导者**。
 
@@ -307,7 +307,7 @@ Raft 算法使用随机选举超时时间的方法来确保很少会发生选票
 - 日志条目中的 Term 号被用来检查是否出现不一致的情况。
 - 日志条目中的日志索引（一个整数值）用来表明它在日志中的位置。
 
-![img](https://pic3.zhimg.com/80/v2-ee29a89e4eb63468e142bb6103dbe4de_hd.jpg)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/202405170814527.png)
 
 Raft 日志同步保证如下两点：
 
@@ -318,7 +318,7 @@ Raft 日志同步保证如下两点：
 
 #### 日志复制流程
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20200201115848.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/202405170817072.png)
 
 1. Leader 负责处理所有客户端的请求。
 2. Leader 把请求作为日志条目加入到它的日志中，然后并行的向其他服务器发送 `AppendEntries RPC` 请求，要求 Follower 复制日志条目。
@@ -335,7 +335,7 @@ Raft 日志同步保证如下两点：
 
 Leader 和 Follower 可能存在多种日志不一致的可能。
 
-![img](https://pic4.zhimg.com/80/v2-d36c587901391cae50788061f568d24f_hd.jpg)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/202405170815743.png)
 
 > :bulb: 图示说明：
 >
@@ -381,7 +381,7 @@ Raft 通过比较两份日志中最后一条日志条目的日志索引和 Term
 
 一个当前 Term 的日志条目被复制到了半数以上的服务器上，Leader 就认为它是可以被提交的。如果这个 Leader 在提交日志条目前就下线了，后续的 Leader 可能会覆盖掉这个日志条目。
 
-![img](https://pic4.zhimg.com/80/v2-12a5ebab63781f9ec49e14e331775537_hd.jpg)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/202405170816381.png)
 
 > 💡 图示说明：
 >
@@ -410,7 +410,7 @@ Raft 通过比较两份日志中最后一条日志条目的日志索引和 Term
 
 当 Leader 要发送某个日志条目，落后太多的 Follower 的日志条目会被丢弃，Leader 会将快照发给 Follower。或者新上线一台机器时，也会发送快照给它。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20200201220628.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/snap/20200201220628.png)
 
 **生成快照的频率要适中**，频率过高会消耗大量 I/O 带宽；频率过低，一旦需要执行恢复操作，会丢失大量数据，影响可用性。推荐当日志达到某个固定的大小时生成快照。
 
@@ -424,7 +424,7 @@ Raft 通过比较两份日志中最后一条日志条目的日志索引和 Term
 
 **一致性哈希** 可以很好的解决 **稳定性问题**，可以将所有的 **存储节点** 排列在 **首尾相接** 的 `Hash` 环上，每个 `key` 在计算 `Hash` 后会 **顺时针** 找到 **临接** 的 **存储节点** 存放。而当有节点 **加入** 或 **退出** 时，仅影响该节点在 `Hash` 环上 **顺时针相邻** 的 **后续节点**。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/cs/design/architecture/partition-consistent-hash.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/cs/design/architecture/partition-consistent-hash.png)
 
 - **相同的请求**是指：一般在使用一致性哈希时，需要指定一个 key 用于 hash 计算，可能是：
   - 用户 ID
@@ -600,7 +600,7 @@ ZAB 协议定义了两个可以**无限循环**的流程：
 
 那么，ZooKeeper 是如何实现副本机制的呢？答案是：ZAB 协议的原子广播。
 
-![img](https://raw.githubusercontent.com/dunwu/images/master/cs/java/javaweb/distributed/rpc/zookeeper/zookeeper_3.png)
+![](https://raw.githubusercontent.com/dunwu/images/master/cs/java/javaweb/distributed/rpc/zookeeper/zookeeper_3.png)
 
 ZAB 协议的原子广播要求：
 
@@ -622,4 +622,4 @@ ZAB 协议的原子广播要求：
 
 ## 参考资料
 
-- [分布式协议与算法实战](https://time.geekbang.org/column/intro/100046101)
+- [分布式协议与算法实战](https://time.geekbang.org/column/intro/100046101)