1.记录canal数据库中间件在项目中的实际应用以及过程，附上代码：

增量订阅/消费设计

首先生成一个数据库连接字段，如下所示；

具体的协议格式，可参见：CanalProtocol.proto
get/ack/rollback协议介绍：

其中对应的代码，如下所示：

• Message getWithoutAck(int batchSize)，允许指定batchSize，一次可以获取多条，每次返回的对象为Message，包含的内容为：
• batchsize是可以去进行自己定义的
• 
•  
• a. batch id 唯一标识
• 代码获取如下所示：

• Message message = connector.getWithoutAck(batchSize); // 获取指定数量的数据
      //获取message对象信息
                  long batchId = message.getId();
     //去获得唯一获得ID
                  int size = message.getEntries().size();
  
                  if (batchId == -1 || size == 0) {
  //当message的ID不是正常状态，进行间隔使用

   

• b. entries 具体的数据对象，对应的数据对象格式：EntryProtocol.proto
• 因为batchId是唯一的，因
• 
• void rollback(long batchId)，顾命思议，回滚上次的get请求，重新获取数据。基于get获取的batchId进行提交，避免误操作
• void ack(long batchId)，顾命思议，确认已经消费成功，通知server删除数据。基于get获取的batchId进行提交，避免误操作
• canal的get/ack/rollback协议和常规的jms协议有所不同，允许get/ack异步处理，比如可以连续调用get多次，后续异步按顺序提交ack/rollback，项目中称之为流式api.
• 流式api设计的好处：
• get/ack异步化，减少因ack带来的网络延迟和操作成本 (99%的状态都是处于正常状态，异常的rollback属于个别情况，没必要为个别的case牺牲整个性能)
• get获取数据后，业务消费存在瓶颈或者需要多进程/多线程消费时，可以不停的轮询get数据，不停的往后发送任务，提高并行化. (作者在实际业务中的一个case：业务数据消费需要跨中美网络，所以一次操作基本在200ms以上，为了减少延迟，所以需要实施并行化)

流式api设计：

• 每次get操作都会在meta中产生一个mark，mark标记会递增，保证运行过程中mark的唯一性
•  
• 每次的get操作，都会在上一次的mark操作记录的cursor继续往后取，如果mark不存在，则在last ack cursor继续往后取
• 进行ack时，需要按照mark的顺序进行数序ack，不能跳跃ack. ack会删除当前的mark标记，并将对应的mark位置更新为last ack cusor
• 一旦出现异常情况，客户端可发起rollback情况，重新置位：删除所有的mark, 清理get请求位置，下次请求会从last ack cursor继续往后取

数据格式

canal采用protobuff:这也是cannal的数据传输格式如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Entry     Header         logfileName [binlog文件名]         logfileOffset [binlog position]         executeTime [发生的变更]         schemaName         tableName         eventType [insert/update/delete类型]     entryType   [事务头BEGIN