分布式CronTab使用到的技术原理

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

分布式CronTab使用到的技术原理
1

分布式CronTab使用到的技术原理

痛点分析

传统crontab痛点
机器故障,任务停止调度,甚至crontab配置找不回来
迁移麻烦
人工ssh配置
日志不好查看
核心
调度器
执行器
常见开源项目
全是JAVA编写 划重点
zookeeper + RPC下发
伪分布式设计
分布式网络环境不可靠,RPC异常经常
Master下发任务RPC异常,导致Master与Worker状态不一致
Worker上报任务RPC异常,导致Master状态信息落后
异常
状态不一致
并发执行
状态丢失
经过网络,都可能出现异常
应用状态放在存储中,内存和存储状态不一致
利用raft管理状态,但成本太高

理论

CAP理论(常见于分布式存储理论)
C:一致性,写入立即读到新值
A:可用性,通常保障最终一致
P:分区容错性,分布式必须面对网络分区
P必须保证
BASE理论(常用与应用架构)
基本可用:损失部分可用性。保证整体可用性(熔断服务)
软状态:允许状态同步延迟,不会影响系统即可
最终一致 经过一段时间后,系统能够达到一致性
架构简化,减少有状态服务,秉承最终一致
架构折衷:确保异常可用自愈
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
咱很菜的,是个智障。 人设非常容易崩。
上一篇

离散数学 Discrete Mathematics 数理逻辑:基本概念

下一篇

淘宝量贩咖啡豆随缘试水

你也可能喜欢

1 条评论

  1. 大佬啊

发表评论

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

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

插入图片
返回顶部