以下是主流分布式系统（Zookeeper、Nacos、Eureka、Consul、Redis Cluster、Kafka、Elasticsearch）的核心分布式算法及其作用，按系统分类说明：

---

📦 一、协调与配置服务

1. Zookeeper

• 共识算法：
  • ZAB协议（Zookeeper Atomic Broadcast）
    • 类似Paxos的变种，专为Zookeeper设计，支持崩溃恢复与原子广播。
    • 写操作由Leader发起，通过两阶段提交（2PC简化版）实现多数节点确认（Quorum）后提交。
  • Fast Leader选举：
    • 基于事务ID（ZXID）和节点ID（myid）选举Leader，优先选择数据最新的节点（ZXID最大者）。
• 数据模型：
  • 树形结构的Znode（持久节点/临时节点），通过Watcher机制监听变更。
• 典型场景：分布式锁、配置管理（Hadoop、Kafka早期）。

2. Nacos

• 双模式一致性协议：
  • CP模式：使用Raft算法管理配置数据，保证强一致性。
  • AP模式：服务发现采用Distro协议（Gossip变种），通过节点间随机同步实现最终一致性。
• 健康检查：
  • 主动心跳检测 + 被动上报，自动剔除异常节点。
• 典型场景：微服务配置中心、动态服务发现（Spring Cloud Alibaba）。

3. Eureka

• 最终一致性协议：
  • Gossip协议：节点间随机交换服务注册表，实现最终一致。
  • 自我保护机制：网络分区时保留现有节点列表，避免过度注销。
• 无Leader设计：
  • 各节点平等，客户端可从任意节点获取服务列表（可能短暂不一致）。
• 典型场景：Netflix微服务生态中的轻量级服务发现组件。

4. Consul

• 共识算法：
  • Raft协议：管理服务注册与键值存储，确保强一致性。
• 健康检查：
  • 多模式支持（TCP/HTTP/Docker），结合Gossip协议跨节点传播状态。
• 多数据中心：
  • 跨数据中心通信通过WAN Gossip同步。
• 典型场景：多集群服务网格、跨地域配置同步（HashiCorp生态）。

---

🚀 二、数据存储与消息系统

1. Redis Cluster

• 数据分片算法：
  • 哈希槽分区（16384个Slot）：
    • 键通过CRC16(key) % 16384计算槽位，由主节点管理。
    • 扩缩容时仅迁移槽位，避免全局数据重分布。
• 高可用机制：
  • 主从复制 + Gossip协议（节点状态同步）。
  • 故障转移：通过Raft-like选举（自研）切换主节点。
• 典型场景：分布式缓存、会话存储。

2. Kafka

• 元数据管理：
  • 早期依赖Zookeeper：存储Broker、Topic分区等元数据，通过ZAB协议保证一致性。
  • KRaft模式（新版本）：自研Raft变种，取代Zookeeper，提升伸缩性。
• 副本同步：
  • ISR机制（In-Sync Replicas）：Leader维护同步副本列表，写入需ISR多数确认。
• 分区分配：
  • 生产者按Key哈希或轮询分配分区，消费者通过Rebalance算法（如RangeAssignor）分配分区。

---

🔍 三、搜索与分析引擎

Elasticsearch

• 分布式共识：
  • Zen Discovery（旧版）：基于Paxos变种选举Master节点。
• 数据一致性：
  • PacificA算法：主分片同步写副本，基于版本号（Sequence ID）冲突检测。
• 搜索算法：
  • BM25相关性排序：结合词频（TF）、逆文档频率（IDF）计算得分。
  • 分布式检索：协调节点合并分片结果（Scatter-Gather模式）。
• 典型场景：日志分析、全文检索（替代Solr依赖Zookeeper的设计）。

---

💎 四、总结：各系统算法对比

系统	核心算法	类型	设计目标
Zookeeper	ZAB协议、Fast Leader选举	CP	强一致协调服务
Nacos	Raft（配置）、Distro/Gossip（服务）	CP+AP可选	灵活一致性
Eureka	Gossip协议	AP	高可用服务发现
Consul	Raft协议、Gossip健康检查	CP	多数据中心强一致
Redis Cluster	哈希槽分区、Gossip状态同步	AP	高性能分片存储
Kafka	ISR、KRaft（Raft变种）	CP	高吞吐消息流
Elasticsearch	PacificA、BM25	AP/CP可选	近实时搜索与分析

注：

• CP系统（Zookeeper、Consul、Kafka）优先保证一致性，网络分区时可能拒绝写入。
• AP系统（Eureka、Redis Cluster）优先保证可用性，容忍短暂不一致。
• 混合型（Nacos、Elasticsearch）支持按需选择一致性模型。

各系统的算法选择体现了对场景的权衡：协调服务（Zookeeper/Consul）倾向强一致，服务发现（Eureka/Nacos）倾向可用性，而数据系统（Kafka/Redis）则聚焦高性能与分区容忍。