干货

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

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

分布式CronTab使用到的技术原理-第一篇
0 0
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
我还没有学会写个人说明!

Github私有仓库免费了

上一篇

项目千万个 挖坑第一个 开工第一天 开发两行泪

下一篇

你也可能喜欢

发表评论

您的电子邮件地址不会被公开。 必填项已用 * 标注

提示:点击验证后方可评论!

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

长按储存图像,分享给朋友