feat(basic): add

系统设计基础/分布式/README.md

@@ -2,27 +2,27 @@
  * @Author: shgopher shgopher@gmail.com
  * @Date: 2024-09-14 13:02:10
  * @LastEditors: shgopher shgopher@gmail.com
- * @LastEditTime: 2024-11-04 22:54:12
+ * @LastEditTime: 2024-11-05 12:36:44
  * @FilePath: /luban/系统设计基础/分布式/README.md
  * @Description: 
  * 
  * Copyright (c) 2024 by shgopher, All Rights Reserved. 
 -->
 # 分布式
 ## 分布式理论
-- [拜占庭将军问题（大体上分析了一下分布式共识算法的种类）](./分布式理论/拜占庭将军问题/README.md)
-- [CAP（一致性和可用性的酸碱测试剂）](./分布式理论/CAP/README.md)
-- [ACID（强一致性）](./分布式理论/ACID/README.md)
-- [BASE（强可用性）](./分布式理论/BASE/README.md)
+- [拜占庭将军问题 (大体上分析了一下分布式共识算法的种类)](./分布式理论/拜占庭将军问题/README.md)
+- [CAP (一致性和可用性的酸碱测试剂)](./分布式理论/CAP/README.md)
+- [ACID (强一致性)](./分布式理论/ACID/README.md)
+- [BASE (强可用性)](./分布式理论/BASE/README.md)
 ## 分布式算法
-- [paxos（共识算法鼻祖，但是不能直接用）](./分布式算法/paxos/README.md)
-- [raft（强一致性共识算法的典范，主备方案）](./分布式算法/raft/README.md)
-- [一致性哈希（从主备方案升级到多主方案就需要这个）](./分布式算法/一致性哈希/README.md)
-- [gossip（无主方案就需要这个）](./分布式算法/gossip/README.md)
-- [quorumNWR（自动调节一致性的强弱）](./分布式算法/quorumNWR/README.md)
-- [pbet（拜占庭将军问题共识算法的鼻祖）](./分布式算法/pbet/README.md)
-- [pow（也是解决拜占庭将军问题的算法，但是解决思路跟PBET 不同）](./分布式算法/pow/README.md)
-- [zab（这是zookeeper自创的共识算法，这个算法我们主要学习如何进行自我设计共识算法）](./分布式算法/zab/README.md)
+- [paxos (共识算法鼻祖，但是不能直接用，主备方案)](./分布式算法/paxos/README.md)
+- [raft (强一致性共识算法的典范，主备方案)](./分布式算法/raft/README.md)
+- [一致性哈希 (从主备方案升级到多主方案就需要这个)](./分布式算法/一致性哈希/README.md)
+- [gossip (无主方案就需要这个)](./分布式算法/gossip/README.md)
+- [quorumNWR (自动调节一致性的强弱)](./分布式算法/quorumNWR/README.md)
+- [pbet (拜占庭将军问题共识算法的鼻祖)](./分布式算法/pbet/README.md)
+- [pow (也是解决拜占庭将军问题的算法，但是解决思路跟 PBET 不同)](./分布式算法/pow/README.md)
+- [zab (这是 zookeeper 自创的共识算法，这个算法我们主要学习如何进行自我设计共识算法)](./分布式算法/zab/README.md)
 ## 分布式组件 (来自极客时间，分布式技术原理与算法解析)
 - 分布式锁
 - 分布式事务

系统设计基础/分布式/分布式理论/拜占庭将军问题/README.md

@@ -12,7 +12,7 @@
 - PBFT (强一致性的主备方案)
 - Pow (最终一致性方案)
 ## 常见的共识算法架构
-在分布式系统中，常见的共识方案可以分为以下两大类：
+在分布式系统中，常见的共识方案可以分为以下三大类：
 
 **主备方案 (Leader-Follower 模式)**
 
@@ -24,7 +24,7 @@
 
 **多主方案**
 
-Multi-Paxos 变体：支持多个主节点，每个主负责不同的值域范围
+Multi-Paxos 变体：支持多个主节点，每个主负责不同的值域范围，就是使用一致性哈希等分片算法组合起来的**多个主备方案**。
 
 典型例子：
   - MySQL 分片集群
@@ -44,29 +44,46 @@ CRDT (无主)：所有节点都可以处理写入；通过数学特性保证最
 - Pow 协议：
   - 支持对等节点设计
   - 可处理恶意节点
-  -常用于区块链系统
+  - 常用于区块链系统
 
 方案选择考虑因素：
 
-主备方案优势：
+**主备方案优势**：
 
-- 实现相对简单
-- 一致性保证强
-- 业务逻辑清晰
+- 架构相对**简单清晰**，易于理解和实现。主节点负责主要的业务处理，备节点处于待命状态，在主节点出现故障时能快速接替其工作，保障系统的连续性。
+- **数据一致性维护相对容易**。通常主节点处理完业务后会将数据同步到备节点，在切换过程中能较好地保证数据状态的一致性
+- 系统稳定性有一定保障。备节点的存在使得即使主节点突发故障，如宕机、网络中断等，也能在较短时间内恢复服务，减少因主节点故障导致的业务中断时间
 
+**主备方案劣势**：
+- **资源利用率可能不高**。备节点在大部分时间处于闲置状态，只在主节点故障时才发挥作用，造成了一定的硬件资源浪费。
+- 存在单点故障风险。虽然有备节点，但如果主节点和备节点同时出现故障 (比如遭受相同的网络攻击、硬件故障等)，系统仍可能陷入瘫痪。
+- 主备切换过程可能存在短暂的数据不一致或服务中断情况。
 
-多主/无主方案优势：
+**多主方案优势**：
 
-- 更好的写入性能
-- 更高的可用性
-- 避免单点故障
+- **更好的写入性能**，多个主节点可以同时处理不同的业务任务，分担了系统的工作量
+- 具备一定的容错能力更高的可用性。即使其中一个主节点出现故障，其他主节点仍能继续处理业务，不至于使整个系统陷入瘫痪，保障了系统的基本运行。
+- 可以**灵活配置资源**。根据业务需求和负载情况，可以灵活调整各个主节点的功能和任务分配，使系统资源得到更有效的利用。
 
 
-多主/无主方案劣势：
+**多主方案劣势**：
 
-- 一致性保证相对较弱
-- 实现复杂度高
-- 需要解决冲突
+- 数据一致性维护复杂。多个主节点同时处理业务，要确保它们处理的数据在整个系统中保持一致难度较大，需要复杂的同步机制和冲突处理机制。
+- 实现复杂度高，协调管理困难。多个主节点之间需要进行有效的协调和沟通，以确保业务的正常开展，否则可能出现任务分配不均、业务冲突等问题，增加了系统管理的复杂性。
+- 增加了安全风险。多个主节点意味着更多的攻击入口，更容易遭受恶意攻击，且一旦某个主节点被攻破，可能会影响到整个系统的安全和稳定。
+
+**无主方案优势**：
+
+- 资源利用更加**均衡**。所有节点地位平等，都参与到业务处理中，不存在某个节点闲置等待的情况，使得系统资源得到更充分的利用。
+- 具有较好的**可扩展性**。新节点可以很容易地加入到系统中，不需要考虑与主节点的适配等问题，只需遵循系统的基本规则即可参与业务处理，便于系统的扩展和升级
+- 避免了单点故障问题。由于不存在主节点，也就不存在因主节点故障而导致系统瘫痪的风险，
+
+
+**无主方案劣势**：
+
+- 达成共识难度大。由于没有主节点来主导决策过程，所有节点需要通过复杂的共识算法 (如 PBFT、RAFT 等) 来达成一致意见，这需要消耗大量的时间和计算资源，可能导致业务处理速度较慢。
+- 数据一致性维护挑战大。所有节点平等参与业务处理，要确保数据在各个节点间保持一致需要更为复杂的机制，比如分布式事务处理等，否则容易出现数据不一致的情况。
+- 系统管理和监控相对复杂。没有主节点作为核心监控和管理对象，需要对所有节点进行全面的监控和管理，增加了系统管理和监控的难度和工作量。
 
 实际选择时需要根据业务场景在 CAP 三者间做出权衡，选择最适合的方案。
 

系统设计基础/分布式/分布式算法/paxos/README.md

@@ -5,3 +5,4 @@ Paxos 算法是一种非拜占庭将军问题共识算法 (故障容错共识算
 paxos 分为 basic paxos 算法，它描述的是多节点之间就某个值达成共识；以及 Multi-Paxos 算法，描述的是执行多个 basic paxos 实例，一系列值达成共识。
 
 
+