Otter高可用性

最新推荐文章于 2023-01-13 15:49:57 发布

weixin_34102807

最新推荐文章于 2023-01-13 15:49:57 发布

阅读量291

点赞数

原文链接：https://my.oschina.net/sansom/blog/157873

版权

基本需求

manager对于node来说可以是一个optional的环境，只有在第一次启动任务时需要，node一旦启动了同步任务后，无论manager是否可用，不能影响正常同步。

需要考虑的点：

目前otter内部，manager部署2台，manager主要集中在杭州机房，node部署70+，node分布在各个机房。

otter调度系统在设计的时候，会有个假定，认为90%的情况都是正常工作的，所以一旦出现异常，处理的代价相对比较高，会使用分布式锁机制。

仲裁器设计了三种异常机制指令：

WARNING : 只发送报警信息，不做任何S/E/T/L调度干预
ROLLBACK : 尝试获取分布式锁，避免并发修改，其次修改分布式Permit为false，停止后续的所有S/E/T/L调度，然后删除所有当前process调度信息，通过zookeeper watcher通知所有相关node，清理对应process的上下文，pipe的数据存储会通过TTL来进行清理，不需要ROLLBACK干预。完成后，释放锁操作
RESTART ：前面几个步骤和ROLLBACK基本类似，唯一不同点在于，在释放锁之前会尝试修改分布式Permit为true，重新开启同步，然后释放锁.

罗列了一下不同异常对应的处理机制：

每个node在启动完成后，都会在zookeeper中创建一个Ephemerals节点(此节点特点，当node节点发生crash之后，与zookeeper建立的sesstion因为没有心跳，超过一定时间后就会出现SesstionExpired，然后zookeeper会删除该节点)
manager监听整个node节点列表的变化，任何一个node节点的消失，都会收到zookeeper watcher通知，与内存中上一个版本进行比较，判断出当前消失的node节点
针对该消失的node节点，会有一段保护期(因为可能正常的发布，会关闭node，同样会触发该watcher)，如果该node在保护期内重新启动了，则不做任何处理。默认保护期为90秒
如果保护期内node节点未正常启动，说明node是异常crash，通过查询配置，找到使用了该node的所有同步任务，对每个同步任务发起一个RESTART指令，让所有同步任务重新做一次负载均衡选择，避免挂死在老的node上，一直死等其结果返回。