分布式事务选型

Lcn
Lock（锁定事务单元）、Confirm（确认事务）、Notify（通知事务），属于两阶段提交

LCN分布式事务框架是一款事务协调性的框架，框架本身并不创建事务，只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强，支持所有的关系型数据库事务，支持多数据源，支持与第三方数据库框架一块使用

特点
无侵入式支持分布式事务。
支持多种模式混合使用。
支持关系型数据、NoSQL数据库。
支持SpringCloud Dubbo等RPC框架。
支持负载均衡与集群化部署。
高性能与高稳定性。

Seata
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。AT模式是阿里首推的模式,阿里云上有商用版本的GTS

GTS

RocketMQ
原理分析：
生产者向Broker投递半消息，（半消息是不能被消费者进行消费的）
Broker返回消息投递成功的结果
生产者执行本地事务，再将本地事务的结果返回给Broker
本地事务提交有两种情况，如果返回的成功是，COMMIT，则代表事务成功执行，然后标记该半消息可以为消费者消费。如果事务返回的是ROLLBACK，则代表事务执行失败，进行了回滚，Broker将会把该半消息移除
broker根据事务结果决定该半消息是否让消费者消费
如果本地事务执行时间太久，或者是因为网络原因导致本地事务结果没有告诉Broker，Broker将每隔一分钟主动查询一次本地事务执行的结果。总共重试15次。以此判断半消息是否可以被消费

优点
RocketMQ具有重试机制、持久化机制、分区机制、天生抗并发能力强。
RocketMQ已经帮我们解决了分布式事务

缺点
业务侵入性大
编写麻烦

SEATA和LCN比较
seata和lcn大致的实现思路是一致的，但是回滚的机制不一样。
lcn是采取代理数据源的模式，再根据发起方执行本地事务的结果进行回滚或者提交
seata采取的是根据undo_log日志表，进行逆向生成sql语句，来解决回滚
lcn能够保证强一致性，但可能发生死锁的现象（A服务调用了B服务，A服务还没执行完宕机了，TxManage没有收到通知，B服务的事务不能顺利进行，导致死锁）
seata能保证最终一致性，但可能造成脏读

选型考虑
考虑机器成本的情况下，使用rocketmq事务消息机制，但是业务侵入性大且编写麻烦（一般没有引入分布式框架的时候为了保证一些重要业务的一致性可能会使用这个）
如果要保证强一致性，考虑Lcn，最终一致性考虑Seata（个人认为，Seata适用于更多的场景：往往事务的执行我们一般都是默认成功的，只有极少数情况下才会发生报错的情况然后回滚，所以在这种极少数情况下保证数据在达到最终一致之前不会有其他重要业务去读这个数据，脏读就可以忽略）
ICN已经停止更新，而Seata还是比较活跃的，使用的人也挺多
Seata的TCC和XA都可以实现强一致性