springboot 服务最终一致性方案

目前市面上现有的最终一致性方案有：

1.分布式事务

一致性第一个想到的方案，但性能低下，数据源限制，等等问题，基本没用

2.RPC直调

最便宜，最省事，也是最没有保障的一种方案

3.MQ,KAFKA中间件

使用得最多，也是最容易入坑的方式，看看你的项目中是否有注意以下问题：
0.埋点问题，在一个复杂的业务中，是写个拦截器呢还是所有地方都来埋个点呢？
1.发送端埋点上报与数据库事务非原子性操作问题，先操作数据库，还是先上报MQ?
2.发送端发送消息是否有确认机制？
3.发送端发送消息在内存重试过程中，服务重启，数据能否有保障，是否有做持久化处理？
4.当生产者的能力，大于消费者能力时，MQ是否开启了持久化?，默认的阻塞拒绝策略是否有了解？(服务假死的一种方式)
5.消费端是否有做消息确认机制？
6.消费端是否有做去重处理，以及有效性验证（发送端可能误报，也有可能重复消费）?
7.当消费失败时的处理方式？是否是再扔回队列"死循环"式消费,还是尝试几次就丢掉,丢弃的策略又是什么？
8.都说MQ可以实现单通道下的数据时序性消费问题，但当引入重试问题（发送或消费的重试）后，时序性你又是通过什么来保证的呢？是否是阻塞式，直到这条消费成功再消费下一条？

!!! 还有些其他问题，没有细举，这些都可能会导致需求没有达到预期,MQ很棒，但你姿势对了吗

4.Canal

阿里的优秀的MYSQL数据库增量同步方案，Canal ,除了只限于MYSQL数据库类型，版本，以及binlog需要row模式，似乎没有缺点
1.与业务解耦，我同步你的数据与你无关
2.通过解析binlog日志，模拟从库dump log,来获取增量数据

5.Otter

Canal是其子项目， Otter 定位： 基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统，很棒的一个方案

6.Flink CDC

和Canal类似，都是监听日志来获取变更的数据，如mysql的binlog,mongo的oplog，能够实现增量和全量的同步，达到的效果和Canal相同，更好的是有统一平台能够监控每一个任务的执行状态

7.DataLink

神州优车的方案，DataLink 一个更加通用，和功能全面的一个方案，抽象了输入输出，将Canal作为其输入的其中一种方式，意味着他将不受限于MYSQL数据库，还能有其他输入方式，比如ES，Kafka，Hadoop，或者自定义。当然，它的能力不仅于此。它的定位为 完成各种异构数据源之间的实时增量同步，一个分布式、可扩展的数据库同步系统。他借见了Canal,和Otter以及其他的一些设计方案

目前我们公司还在第3步挣扎(“尴尬”)，准备迈入4,5,6步。不过我们公司的业务特性以及数据量与运营成本考虑，可能会自研一个轻量级的方案