精卫原理

 精卫提供如下功能:

1. 内置多种复制任务：解析MySQL的binlog到数据库（MySQL、Oracle），解析MySQL的binlog到Meta消息中间件。
2. 保证数据不丢
3. 如果有多个消费者，能够保证一个消费者挂掉或很慢，其他消费者不会受到影响。
4. 支持用户自定义复制任务：用户可以根据具体业务需求自由定制Extractor和Applier，就可以很方便地创建的新的复制任务。
5. 自定义任务灵活部署：用户自定义复制任务既可以部署在业务服务器，也可部署在精卫集群。
6. 数据过滤功能：用户通过web控制台，就可以灵活地添加、配置过滤器，虑选满足业务需求的数据。
7. 丰富的日志展现形式：用户通过web页面，不但可以查看复制任务运行时的实时数据，而且通过查看历史数据分析复制任务的运行情况，为业务分析、bug定位、监控报警提供便利。
8. 数据再散列：利用TDDL完善的分库分表规则，可以实现数据的再散列。
9. 多种途径监控、告警：用户可通过旺旺、短信、邮件的形式接受运行时告警，及时了解系统运行的监控状况，为运维提供便利。

整体结构

       精卫通过复制管道达到数据共享的目的，在不同类型的存储（RDBMS，NoSQL，倒排序等）之间构建数据流动的管道，使得存储于个节点的数据能够像河流一样流淌。除基本的复制功能外，精卫还提供日志、监控、告警等功能，为复制任务的配置、管理提供便利的web控制台。  

基本原理

       复制任务的核心是复制管道，每个管道用有一个Extractor，负责抓取源存储的Event（管道中的数据封装成事件Event），一个Applier，负责将抓取的Event投递给使用者，和一系列的过滤器Filter，用来过滤业务关注的Event。 

1. Event : 复制数据单元，对于MySQL的binlog，是一个事务。
2. Pipeline : Event传递的管道。
3. Extractor : Event生产者接口，抽取数据源的数据，转换成Pipeline通用的数据格式（称为事件Event）。
4. Applier : Event消费者接口，将Event投递给数据使用者。
5. Filter : Event在Pipeline传送，用户可定义各种过滤策略，只将有用的数据投递给消费者。

       从数据源抓渠道的Event放入队列，可由多线程消费，增加并行度。 

       针对不同的业务需求，一个复制任务可分解成多个子任务，通过增加复制管道的方式满足多变的业务需求。例如，通过Meta，使得消息最终消费者可以方便地使用消息中间件带来的便利。 

1. Task：用户业务相关的复制任务。
2. Sub Task： 完整的复制任务分解为若干子任务。
3. MySQL Extractor：抓取并解析MySQL的binlog，投递到Pipeline。
4. Meta Applier：管道的数据投递到Meta消费。
5. Meta Extractor：从Meta抓取数据投递到Pipeline。
6. MySQL Applier：管道的数据投递到MySQL数据库。

部署图

       精卫部署图表述了精卫集群其他系统之间的部署关系，包括MySQL集群，MetaQ集群，采集日志的Tlog集群，任务协同zookeeper集群，精卫web server集群，精卫复制管道末端的消费集群。 

性能

上线应用的性能数据正在采集，性能指标

1. TPS
2. 延迟时间

高可用性

       精卫是一个高可用的数据复制产品，在提供日志、监控、告警这些基本的观测和预警功能外，精卫也在复制路径关键节点发生异常时提出完善的解决方案。

MySQL主备切换

        在DBA执行主备操作的时候，精卫提供一个方案，在影响DBA操作、不需要人工介入的情况下，实现复制任务自动切换，在主备切换后，自动从备库抓取数据，而且保证不会丢失数据。 

       风险是会产生少量的重复数据。

复制管道的热备

       为应对复制任务故障或者复制任务所在主机故障，精卫采用热备复制任务的方式。即将同一个复制任务部署在不同的主机上，主、备复制任务通过Zookeeper互相检测运行健康状况，并且时间间隔记录复制位点，在主任务停掉的情况下，备任务从Zookeeper上取得最近的复制位点，取代原主任务进行复制。  
       风险是会有少量的重复数据。

复制管道的冷备

       冷备必需保证足够多的机器进行1：1的备份，现实中会出现没有足够多机器的情况，另外对于非单例任务（一个任务可同时在多台机器上运行，针对以Meta为Extractor对象的任务），实际运行的任务数量大于1，热备方案不能满足这些需求，所以设计了冷备方案。 Server进程和task进程之间通过/jinwei/tasks/**task/t-locks/lock来协同，task进程启动时先发布节点/jingwei/tasks/**task/t-locks/lock_index节点，立即注册该节点的监听器（当发现该节点消失的时候），退出进程。及时task进程和zk断掉的较长时间，后来又重新连上，zk server推送过来空节点时，task进程发现推送了空节点（认为自己进程应该消失），就把自己干掉了，当server进程扫描到/jingwei/tasks/**task/t-locks/lock_index消失的时候，认为应该调用脚本，启动复制任务。 Server进程扫描启动任务具体步骤如下：

1. 通过配置文件获取本机可执行的最大任务数E。
2. 通过sh脚本获取本机已经执行的任务数O。
3. 如果E>O，继续；否则，转到（17）。
4. 从zk获取所有任务
5. 如果迭代结束，则转到（17）；否则当前任务赋给task；
6. 判断task的op是start？如果是start则继续；如果是stop，则转到（5）迭代下一个任务
7. 获取task的指定的任务数C；
8. 获取task已经运行的实例数L；
9. 如果C<L，则继续；否则转到（5），迭代下一个任务；
10. 获取任务的token；
11. 创建互斥锁，成功则继续；否则转到（5）迭代下一个任务
12. 调用脚本启动task；
13. 注册监听器（如果task启动成功则会回调），阻塞10秒
14. 如果超时时间内回调，则说明成功启动，转到（15）；如果超时时间到了还没有回调，说明启动失败，转到（15）
15. 取消注册的监听器
16. 删除互斥锁
17. Sleep 5秒，执行（1）

       流程图如下：