分布式CronTab使用到的技术原理-第一篇

Raft算法:
leader 主节点,follower子节点
Raft原理是使用抽屉理论(大多数算法):
服务器必须是(N+1)奇数
假如有五个服务器,一个字符串,传递给3(n+1)个服务器,那么我随便找3个服务器肯定能拿到这个字符串
传递流程:客户端传输数据给leader,leader传输给follower 然后再返回结果给客户端(复制失败并不会提交)
选举leader需要半数以上节点参与
节点commit日志最多的允许选举为leader
commit日志同样多则term,index越大的运行选举为leader
replication: 日志再leader生成 向 follower复制,达到各个节点的日志队列最终一致
term:任期,重新选举产生的leader,其term单调递增
log index: 日志行在日志队列下标
Raft保证
提交成功的请求不会丢
各个节点最终一致
etcd:
etcd采用http+json协议 性能低效
SDK内置GRPC写于 性能高效
底层存储是按key有序排列,可以顺序遍历
etcd 天然支持按目录结构高效遍历
支持复杂事务 if else then
基于租约机制实现key的TTL过期
支持MVCC多版本控制
提交版本(revision)在etcd中单调递增
同key维护多个版本,用于实现watch机制
历史版本过多,可以通过执行compact命令完成删减
监听KV变化,通过watch机制,可以监听某个key,或者某个目录(key前缀)
lease租约
sdk通过grant 创建10秒租约 得到一个lease,带着lease去请求kv存储引擎租约过期则delete

Leave a Reply

Your email address will not be published. Required fields are marked *

微信扫一扫,分享到朋友圈

分布式CronTab使用到的技术原理-第一篇
嘿!有什么能帮到您的吗?
返回顶部

显示

忘记密码?

显示

显示

获取验证码

Close