otter 高可用策略

关于otter高可用在设计之初，提供了这样几个基本的需求：

1.网络不可靠，异地机房尤为明显.
2.manager/node的jvm不可靠，需要考虑异常crash情况
3.node的jvm不可靠，需要考虑异常crash的情况
4.数据库不可靠，需要考虑数据库切换，比如binlog获取和数据载入时，都需要考虑数据库HA机制
5.系统发布时，排除正常的jvm关闭和启动

接下来我们一起看看为了实现这些需求，otter研发团队做了哪些方面的努力；

一、部署上

       首先otter manager和node节点分开部署，node节点负责完成真正的同步任务，同时自身汇总同步任务统计数据，将统计数据推送给manager，由manager完成统计数据的落库，node节点除了在首次启用时需要获取manager上的配置信息外，后续的同步任务不再依赖于manager；所以node节点的同步任务可以说是独立于manager了，所以启动后后续的任务理论上不受manager影响。

      其次manager在otter的架构中主要是完成同步任务配置管理、同步进度收集逻辑查阅、数据源维护、系统信息维护、cannal维护等等，相当于一个后台管理系统。

二、完善的异常处理机制(引用otter官方)

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

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

(1)WARNING : 只发送报警信息，不做任何S/E/T/L调度干预
(2)ROLLBACK : 尝试获取分布式锁，避免并发修改，其次修改分布式Perm