经典应用场景
- 服务发现
- 动态添加微服务
- 多实例的透明访问与故障重启透明化
- 使得API网关也成为无状态服务，便于水平扩容
- 消息订阅与发布
- 负载均衡
- 分布式通知
- 心跳检测，任务汇报，系统调度等
- 分布式锁
- 分布式队列（并发控制）
- 分布式选主（master节点的高可用）
- 通常情况下分布式系统和 Master 都是有状态逻辑的，无法允许多个 Master 同时运行
- 可以通过 etcd 来实现选主，将其中的一个 Master 选主成 Leader，负责控制整个集群中所有 Slave 的状态
- 当 Leader 节点发生异常之后，通过 etcd 能够选取出一个新的节点成为主节点，并且注册新的 IP 之后，Slave 又能够拉取新的主节点的 IP，从而会继续恢复服务
实现原理
架构
- HTTP Server
- 处理API请求与心跳和同步消息
- Store
- 大多数功能的具体实现
- 包括数据索引，节点状态变更，监控与反馈等
- Raft
- 强一致性算法的现实
- WAL（write ahead log）
- 储存数据在内存并进行持久化储存
处理过程
- HTTP Server接受请求并转发给store进行处理
- 如果涉及节点修改，则交给raft进行状态变更、日志记录
- 然后同步给其他节点以确认数据提交
- 最后提交数据，并再次同步
集群部署
- 由于raft算法需要多数节点投票，因此etcd部署时推荐奇数个节点构成集群
- 高可用
- 如果有3个节点，最多允许一个节点失效
- 如果有5个节点，允许两个失效
- 节点越多，读的性能越好，写的性能越差
- 配置不采用配置文件，而是使用命令行参数和环境变量
- proxy模式
- 参与选主的节点是几个核心节点，当etcd集群节点数多于核心节点上限时，新增节点是以proxy方式接入的，不会参与选主
- 因为核心节点到达一定数量后，增加带来的可靠性增强并不显著，反而降低了写性能
Raft算法
来源：CSDN
作者：_萤火
链接：https://blog.csdn.net/winter_wu_1998/article/details/104087219