42 lines
1.9 KiB
Plaintext
42 lines
1.9 KiB
Plaintext
|
etcd 可用于配置共享和服务发现
|
|||
|
|
|
|||
|
|
|
|||
|
|
特点：
|
|||
|
|
1.完全复制：集群中的每个节点都可以使用完整的存档
|
|||
|
|
2.高可用性：etcd可用于避免硬件单点故障或网络问题
|
|||
|
|
3.一致性： 每次读取都会返回跨多主机的最新写入
|
|||
|
|
4.简单：包括一个定义良好，面向用户的API（grpc）
|
|||
|
|
5.安全：实现了带有可选的客户端证书身份验证的自动化TLS
|
|||
|
|
6.快速：每秒10000次写入的基准速度
|
|||
|
|
7.可靠：使用Raft算法实现了强一致，高可用的服务存储目录
|
|||
|
|
|
|||
|
|
###本周任务：
|
|||
|
|
1.Raft协议
|
|||
|
|
1.选举
|
|||
|
|
2.日志复制机制
|
|||
|
|
3.异常处理（脑裂）
|
|||
|
|
4.zookeeper的zad协议的区别
|
|||
|
|
|
|||
|
|
etcd的应用场景：
|
|||
|
|
1.服务发现：
|
|||
|
|
在同一个分布式集群中的进程或者服务，如何找到对方并建立连接（注册中心）
|
|||
|
|
2.配置中心
|
|||
|
|
应用在启动的时候主动从etcd获取一次配置信息，同时在etcd节点上注册一个watcher并等待，以后每次配置有更新的时候，etcd都会实时通知订阅者，
|
|||
|
|
以此达到获取最新配置信息的目的（热加载）
|
|||
|
|
3.分布式锁
|
|||
|
|
1.所有获取锁的用户只有最终一个可以得到
|
|||
|
|
2.控制时序，所有想要获得锁的用户都会被安排执行
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
etcd的架构，分为4个部分
|
|||
|
|
1.HTTP server
|
|||
|
|
用于处理用户发送的API请求及与其他节点的etcd同步与心跳请求
|
|||
|
|
2.store
|
|||
|
|
用于处理etcd的各类功能的事务，包括数据索引，节点状态变更，监控与反馈，事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现
|
|||
|
|
3.Raft
|
|||
|
|
Raft强一致性算法的具体实现，是etcd的核心
|
|||
|
|
4.WAL
|
|||
|
|
write ahead log （预写式日志）是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引外。etcd就
|
|||
|
|
通过WAL进行持久化存储，WAL中，所有的数据提交前都会事先记录日志，snapshot就是为了防止数据过多而进行的状态快照
|
|||
|
|
entry表示存储的具体日志内容
|