近期在研究分布式架构数据一致性和幂等问题，思路还比较混沌，先记录下看的文章，再其中吸收点知识，为后期梳理做下准备
《微服务架构下分布式事务解决方案——阿里GTS》
https://www.cnblogs.com/jiangyu666/p/8522547.html
大致讲了微服务化下遇到的落地问题，第二个事务问题是我关心的，介绍了几种解决方法的优劣。当然这个也是阿里gts的软文
《分布式系统数据一致性的6种方案》
https://www.cnblogs.com/wangdaijun/p/7272677.html
几种方案对比，基于消息的最终一致性方案，列举了蘑菇街交易的方案实例
《为什么分布式要有分布式锁！》
https://blog.csdn.net/bntx2jsqfehy7/article/details/81350556
主要说了分布式锁，zookeeper，redis2种的区别和优劣：zookeeper可靠性比redis强，redis读写性能高
《分布式系统中的幂等性（客户端与服务端的交易一致性，避免多次扣款）》
https://blog.csdn.net/eluanshi12/article/details/79999823
《如何确保发起的交易已完成——关于原子性问题的解决方案》
http://www.chainb.com/?P=Cont&id=13225
专业术语较多，只是描述方法，没有具体方案，当做一些概念了解
《fescar锁设计和隔离级别的理解》
https://www.jianshu.com/p/4cb127b737cf
阿里GTS社区版
总结：
看了以上文章，大致有个概念：
1.数据一致性
一个业务操作，会涉及到多个数据操作，其中一个相关业务出现异常，会导致此业务数据不一致，比如订单，订单状态更改了，库存更改失败，导致数据不一致，需要做回滚或补偿， 然后微服务化和业务拆分将数据一致性变得困难，不拆分会让程序耦合变高，吞吐量小，扩展性差。所以解决数据一致性就需要花大量工作，并且根据各个公司本身情况，解决方案不同，没有说最优解，只有最适合的方案，好的架构师需要针对不同情况提出适合的方案。
目前看了几篇文章大致解决方案
XA2次提交，需要特点数据库支持
TCC,据说目前用的最多，有个事务协调器，所有业务需要拆分成try cache cancel,开发工作量大
消息最终一致性，简单，但是需要修改业务执行流程，需要依赖消息系统
GTS，据说挺简单易用，只是要给钱
2.幂等问题
其实最终也是数据一致性问题，只是幂等描述的是重复操作的情况下，数据保持一致的问题。比如支付通知，支付通知第一次进来，业务还在处理，订单状态还未更改，但是第二次通知到来，读取订单状态为未支付，会产生重复记录。 大致解决方案描述都是用锁，具体锁的类型就看应用场景，业务独占就用悲观锁，非独占的就用乐观锁，当然不是绝对的。用锁后产生的一系列问题，又有一系列方案。比如悲观锁独占数据后，其他业务访问相同资源，如何防止数据丢失或业务执行失败等
待实操验证场景
电子商务购物场景
金融场景
erp订单,库存,拆单场景
