分布式, 可靠的, kv 分布式系统
Raft 算法
从多个节点选出 leader,leader 负责数据的同步和分发.
### quorum=(n+1)/2
3 个节点容忍 1 个故障
5 个节点容忍 2 个故障
- API
- PUT(key,value)/Delete(key)
Get(key)/Get(keyFrom,keyEnd) key 的范围
Watch(key/keyPrefix)
Transactions(if/then/else ops).commit() 满足条件, 执行操纵
Leases:Grant/Revoke/KeepAlive
etcd 的数据版本号机制
term: 全局单调递增 (整个集群 leader 的任期, leader 进行切换, term 加 1)
revision: 全局单调递增 (代表的 kv 修改一次, revision 加 1)
KeyValue:
create_revision: 创建的次数
mod_revision: 修改的次数
version: 此次 key 修改的次数
一个数据有多个版本, 通过定期 Compaction 来清理历史数据
lease(租约)
性能优化
Ratf 层
网络 IO
节点之间的 RTT / 带宽
磁盘 IO 写入延迟
Storage
磁盘 IO fdatasync 延迟
索引层所的 block
boltdb Tx 的锁
boltdb 本身的性能
其他
内核参数
grpc API 层的延迟
服务端性能优化 - 硬件
升级 CPU/memory
选取优秀的 ssd
网络带宽优先级
独占部署
服务端性能优化 - 软件
没存索引层: 提升 etcd 内存索引性能, 优化内部锁的使用减少等待时间
lsase 规模使用: 优化 lease revoke 过期失效的算法, 解决了 lease 规模性的问题
后端 boltdb 使用优化: 端酒 batch size limit /interval, 根据不同的硬件和工作负载配置 (以前是固守保守值)
完全并发读, 优化调用 boltdb tx 读写锁使用, 提升读性能
基于 segregated hashmap 的 etcd 内部存储 freelist 分配回收算法
客户端性能优化
put 避免大 value, 精简再精简
避免创建频繁变化的 key/value
避免创建按大量 lease, 尽量选择复用
来源: http://www.bubuko.com/infodetail-3371705.html