常见问题：

  1. 什么是CAP原理？什么是BASE理论？
  2. zookeeper是什么？zk的性能瓶颈怎么克服？

知识点：

理论

  • CAP
    • C 一致性
    • A 可用性
    • P 分区容错性
  • BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。

    1. 基本可用（Basically Available）

指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

    1. 软状态（ Soft State）

指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。

    1. 最终一致（ Eventual Consistency）

2PC与3PC

  1. 2PC和3PC的区别？有什么缺点？什么是脑裂？ https://blog.51cto.com/11821908/2058651
    1. 2PC

阶段1：准备阶段
1. #协调者#向#所有参与者#发送事务内容，询问是否可以提交事务。
2. #各参与者#执行事务操作，将Undo和Redo日志写入事务中。如果执行成功，反馈#协调者#YES，如果执行失败，反馈#协调者#NO
阶段2：提交阶段
1. 如果#All参与者#返回YES，则提交事务。#All参与者#在Commit事务之后，反馈ACK。
2. 如果#Any一个参与者#返回NO，则中断事务。
缺点：
1. 同步阻塞:所有参与事务的逻辑处于阻塞状态。
2. 单点：协调者如果DOWN,则所有参与者都处于锁定状态；
3. 脑裂：在阶段2中，如果只有部分参与者Commit，则会导致数据不一致；

3PC是2PC的改进版本。
阶段1：CAN COMMIT
阶段2：PRE COMMIT
阶段3：DO COMMIT
缺点？
1.并没有解决2PC的数据不一致问题。原因：在Phase2时，#参与者#接收到PreCommit之后等待doCommit。如果此时#协调者#发出Abort请求之后Down机，导致部分#参与者#没有接收到并在超时之后执行Commit而产生数据不一致。
优点？
1.3PC主要解决同步阻塞问题。降低的是#参与者#的阻塞范围。
2.3PC新增了参与者超时机制
3 没有解决数据不一致

  1. 总结:<br />1. 2PC和3PC都无法彻底解决分布式系统一致性问题。<br />2. 解决一致性问题，只有Paxos.
  3. 什么是脑裂？<br />    如何解决脑裂？-- 过半机制。为什么是大于，而不是大于等于？ https://www.toutiao.com/i6717931175530201604/

常见协议

  • 没有一种方案是完美的 | 协议 | 典型案例 | 优点 | 缺点 | 可参考博客 | | —- | —- | —- | —- | —- | | Paxos |

    |

    |

    |

    | | Zab | Zookeeper |

    |

    |

    | | Raft | Etcd |

    |

    |

    | | Gossip | Cassandra\Consul |
    1. 可扩展性
    1. 容错
    1. 去中心化
    1. 传播速度达logN
    1. 简单
    |
    1. 消息延迟
    1. 消息冗余
    |
    1. P2P 网络核心技术：Gossip 协议
    | | Chubby | Google BigTable |

    |

    |

    |

面试必备：分布式一致性协议 - 图1

Paxos

Paxos基于2PC扩展

  1. 定义3个角色
    1. Proposer
    2. Acceptor
    3. Learner
  2. 推导过程

此处为语雀加密文本卡片，点击链接查看：https://www.yuque.com/yulongsun/java/pkm9f7#EznmC

ZAB协议

  1. ZAB中节点的三种状态？
    1. following
    2. leading
    3. looking 处于选举状态。
  2. ZAB模式
    1. 崩溃恢复
    2. 消息广播
  3. ZAB和Paxos的区别？https://www.cnblogs.com/sunddenly/articles/4073157.html
    1. 设计目的
    2. 流程上的区别
  4. 为什么要设计ZAB？
    1. 因为Paxos满足不了ZK对数据一致性的要求。
    2. ZAB协议保证了数据有序性。
  5. ZAB如何保证？
    1. 保证同一Leader发起的事务要被#顺序#执行，同时需要保证旧Leader的所有事务都被执行之后，新Leader才能发起事务。
    2. 一些已经被Skip的消息，需要仍然被Skip。— 通过zxid=epoch+counter实现

分布式消息队列

  1. 讲了下kafka，怎么保证数据不丢失？确保消息不会重复消费？消息送达确认是怎么实现的？
    1. 重复消费怎么解决？
      1. 幂等机制
    2. 如何保证消息的可靠性传输？
      1. RabbitMQ为例
        1. 生产者弄丢了数据
          1. 事务机制
          2. confirm机制
          3. 事务机制和confirm机制最大的区别在于：事务机制是同步的，但是confirm机制是异步的。
        2. RabbitMQ弄丢了数据
          1. 持久化机制：
            1. 创建Queue时设置持久化机制；
            2. 发送消息的时候，将消息设置为持久化；
        3. 消费者弄丢了数据
          1. autoAck机制。
      2. Kafka为例
    3. 顺序消费
      1. 让每个消费者
    4. MQ消息积压了几百万条数据怎么办？

分布式限流

1. 常见限流方式

  1. 限制总并发（数据库连接池、线程池）
  2. 限制瞬时并发（Nginx#limit_conn模块）
  3. 限制窗口时间的平均速率（Guava#RateLimiter、Nginx#limit_req）
  4. 限制MQ的消费速率

  5. 分布式限流：基于Redis实现

    2. 限流算法

    |

    | 漏桶算法 | 令牌桶算法 | | —- | —- | —- | | 特点 | 漏桶的出口速率固定（出速率固定）
    强制限定数据传输速率 | 按照固定速率添加令牌（入速率固定） | | 优点 |

    | 允许某种程度的突发 | | 实践案例 |

    | Guava#Ratelimiter |

分布式事务需要注意的问题


面试必备：分布式一致性协议 - 图2

  1. 如何处理并发控制？
  2. (如何异常控制?) TCC下最常见的三种异常：空回滚、幂等、悬挂

文献

  1. 分布式系统中的2PC与3PC
    2. ZooKeeper学习第七期—ZooKeeper一致性原理

  2. 分布式事务 Seata TCC 模式深度解析

  3. 蚂蚁金服生产级 Raft 算法库 SOFAJRaft 存储模块剖析