数据总线学习

为啥要数据总线

1. 使用服务化方式发布，业务端和中间件完全解耦合。
2. 一处生产，处处消费设计理念。
3. 提供用户可定制的托管化通用消费方案（如同步mysql到缓存，同步mysql到es，消费mysql到大数据等托管服务）

特性

顺序消费

场景

刷缓存。在刷缓存的过程中，存在“回源”问题：缓存中不存在需要的数据时需要去数据库中重新查找。
在利用消息队列刷新缓存时，需要缓存的数据一般为表中某些行的值，所以保持表级别的有序即可。如果需要缓存的数据跨越多个表，则需要保持数据库级别的有序。

原理

要求整个链路是有序的

1. 数据库到binlog
   mysql的事务机制保证写入到binlog的顺序是整个mysql集群有序的
2. 总线服务拉取binlog
   分布式协调器确保一个mysql集群同时只有一个实例在消费
3. 总线写入Kafka
   在发送消息到 Kafka的过程中，会根据db标识进行hash计算，然后根据hash值执行顺序发送，保证同一个hash值的数据发送到同一个Kafka的分区
4. 总线客户端消费
   Client在消费消息时，定义顺序任务标识，放入同一队列，单线程执行队列任务，一旦用户消费失败触发重试逻辑，保证上一个消费成功才进行下一次的消费逻辑。

事务消费

场景

类似事务消息的玩法，本地数据库事务执行完成后，数据总线通知client消费方

原理

以GtidEvent、XidEvent事件作为事务起始和结束，将流式的Binlog按事务标识GTID打包，以库(Cluster)有序投递事件

全流量消费

场景

业务冷启动，数据全量校准补偿

原理

全量流的消息会被打包成insert binlog事件投递给Resolver

回溯消费

场景

消费过程中因为消费失败、上线bug或其他原因，会存在重新消费旧数据的需求。

原理

Kafka的offset回溯实现的，支持时间戳回溯，精度在秒级