etcd 基本原理

经典应用场景

• 服务发现
  • 动态添加微服务
  • 多实例的透明访问与故障重启透明化
• 消息订阅与发布
• 负载均衡
• 分布式通知
  • 心跳检测，任务汇报，系统调度等
• 分布式锁
• 分布式队列

实现原理

架构

• HTTP Server
  • 处理API请求与心跳和同步消息
• Store
  • 大多数功能的具体实现
  • 包括数据索引，节点状态变更，监控与反馈等
• Raft
  • 强一致性算法的现实
• WAL（write ahead log）
  • 储存数据在内存并进行持久化储存

处理过程

• HTTP Server接受请求并转发给store进行处理
• 如果涉及节点修改，则交给raft进行状态变更、日志记录
• 然后同步给其他节点以确认数据提交
• 最后提交数据，并再次同步

集群部署

• 由于raft算法需要多数节点投票，因此etcd部署时推荐奇数个节点构成集群
• 高可用
  • 如果有3个节点，最多允许一个节点失效
  • 如果有5个节点，允许两个失效
• 节点越多，读的性能越好，写的性能越差
• 配置不采用配置文件，而是使用命令行参数和环境变量
• proxy模式
  • 参与选主的节点是几个核心节点，当etcd集群节点数多于核心节点上限时，新增节点是以proxy方式接入的，不会参与选主
  • 因为核心节点到达一定数量后，增加带来的可靠性增强并不显著，反而降低了写性能
    

Raft算法