[docs update]zookeeper内容完善&部分markdown格式规范

2025-06-16 18:10:13 +08:00 · 2024-02-23 16:44:05 +08:00 · 2024-02-23 16:44:05 +08:00 · 3131d095c2
commit 3131d095c2
parent a8ec6e8d7d
6 changed files with 35 additions and 10 deletions
--- a/docs/database/mongodb/mongodb-questions-01.md
+++ b/docs/database/mongodb/mongodb-questions-01.md
@ -331,8 +331,6 @@ WriteResult({
 })
 ```

-
-
 ## 参考

 - MongoDB 官方文档（主要参考资料，以官方文档为准）：<https://www.mongodb.com/docs/manual/>
--- a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md
+++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md
@ -57,7 +57,9 @@ ZooKeeper 将数据保存在内存中，性能是不错的。 在“读”多于
 - **原子性：** 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
 - **单一系统映像：** 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
 - **可靠性：** 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。
- **实时性：** 每个客户端的系统视图都是最新的。
+- **实时性：** 一旦数据发生变更，其他节点会实时感知到。每个客户端的系统视图都是最新的。
+- **集群部署**：3~5 台（最好奇数台）机器就可以组成一个集群，每台机器都在内存保存了 ZooKeeper 的全部数据，机器之间互相通信同步数据，客户端连接任何一台机器都可以。
+- **高可用：**如果某台机器宕机，会保证数据不丢失。集群中挂掉不超过一半的机器，都能保证集群可用。比如 3 台机器可以挂 1 台，5 台机器可以挂 2 台。

 ### ZooKeeper 应用场景

@ -253,7 +255,7 @@ Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并

 ### ZAB 协议介绍

-ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
+ZAB（ZooKeeper Atomic Broadcast，原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

 ### ZAB 协议两种基本的模式：崩溃恢复和消息广播

@ -262,12 +264,38 @@ ZAB 协议包括两种基本的模式，分别是
 - **崩溃恢复**：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致**。
 - **消息广播**：**当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。

+### ZAB 协议&Paxos 算法文章推荐
+
 关于 **ZAB 协议&Paxos 算法** 需要讲和理解的东西太多了，具体可以看下面这几篇文章：

 - [Paxos 算法详解](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html)
 - [ZooKeeper 与 Zab 协议 · Analyze](https://wingsxdu.com/posts/database/zookeeper/)
 - [Raft 算法详解](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)

+## ZooKeeper VS Etcd
+
+[Etcd](https://etcd.io/) 是一种强一致性的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。Etcd 内部采用 [Raft 算法](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)作为一致性算法，基于 Go 语言实现。
+
+与 ZooKeeper 类似，Etcd 也可用于数据发布/订阅、负载均衡、命名服务、分布式协调/通知、分布式锁等场景。那二者如何选择呢？
+
+得物技术的[浅析如何基于 ZooKeeper 实现高可用架构](https://mp.weixin.qq.com/s/pBI3rjv5NdS1124Z7HQ-JA)这篇文章给出了如下的对比表格，可以作为参考：
+
+|                | ZooKeeper                                                             | Etcd                                                   |
+| -------------- | --------------------------------------------------------------------- | ------------------------------------------------------ |
+| **语言**       | Java                                                                  | Go                                                     |
+| **协议**       | TCP                                                                   | Grpc                                                   |
+| **接口调用**   | 必须要使用自己的 client 进行调用                                      | 可通过 HTTP 传输，即可通过 CURL 等命令实现调用         |
+| **一致性算法** | Zab 协议                                                              | Raft 算法                                              |
+| **Watch 功能** | 较局限，一次性触发器                                                  | 一次 Watch 可以监听所有的事件                          |
+| **数据模型**   | 基于目录的层次模式                                                    | 参考了 zk 的数据模型，是个扁平的 kv 模型               |
+| **存储**       | kv 存储，使用的是 ConcurrentHashMap，内存存储，一般不建议存储较多数据 | kv 存储，使用 bbolt 存储引擎，可以处理几个 GB 的数据。 |
+| **支持 MVCC**  | 不支持                                                                | 支持，通过两个 B+ Tree 进行版本控制                    |
+| **权限校验**   | 实现的 ACL                                                            | 实现了 RBAC                                            |
+| **事务能力**   | 提供了简易的事务能力                                                  | 只提供了版本号的检查能力                               |
+| 部署维护       | 复杂                                                                  | 简单                                                   |
+
+实际选用哪个要根据实际业务场景和需求来定，Etcd 相对来说更适合云原生领域，并且提供了更稳定的高负载稳定读写能力以及更高的可用性。
+
 ## 总结

 1. ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。
--- a/docs/high-performance/deep-pagination-optimization.md
+++ b/docs/high-performance/deep-pagination-optimization.md
@ -62,8 +62,7 @@ SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order limit 1000000, 1) LIMI
 ```sql
 SELECT t1.* FROM t_order t1
 INNER JOIN (SELECT id FROM t_order limit 1000000, 10) t2
-ON t1.id = t2.id
-LIMIT 10;
+ON t1.id = t2.id;
 ```

 除了使用 INNER JOIN 之外，还可以使用逗号连接子查询。
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@ -1,4 +1,4 @@
-lockfileVersion: '6.0'
+lockfileVersion: '6.1'

 settings:
  autoInstallPeers: true