幂等性： 接口不论调用多少次，结果一致；可以通过本地事物，记录状态的方式完成幂等性处理；
TCC方案：包括 Try、Confirm、Cancel三个操作，第一步先调用try，然后根据try的返回情况调用Confirm或者Cancel
TPS： 每秒的访问量


分布式系统的特性
在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的，这比现实中找对象需同时满足“高、富、帅”或“白、富、美”更加困难。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
 


分布式事务场景 
无需分布式事务
最常用
最优先使用
使用消息队列完成的最终一致性事务
适用于业务主逻辑无需外部数据变更协助来完成的最终一致性事务
常见
若一定要与其他服务写接口发生交互，则优先使用
依据是否保证投递到订阅者，分为可靠消息及最大努力交付消息
有时业务要求一些本质是异步的操作同步返回结果，若同步返回失败则后台异步补单。这种业务本质也归属于无需外部数据变更以协助完成的最终一致性，但介于其同步时要返回结果，其有区别于可靠消息。
事务补偿机制--完成的最终一致性事务
适用于需要获取远程执行结果来决定逻辑事务走向 且 可以进行补偿的业务
次常见
若使用消息队列不能解决的事务问题优先考虑使用基于补偿的最终一致性事务
使用TCC完成最终一致性事务
适用于需要获取远程执行结果来决定逻辑事务走向 且 不可以进行补偿的业务
最不常见
最终解决办法，囊括所有必须使用2PC实现的场景。编码量最大，性能消耗最大，应尽量避免使用本类型的事务

分布式事务处理
分布式事务处理项目代码：https://github.com/QNJR-GROUP/EasyTransaction
博客： https://www.cnblogs.com/dinglang/p/5679542.html#commentform
原文：   http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
阿里中间件GTS： https://www.aliyun.com/aliware/txc
微服务架构下分布式事务解决方案——阿里GTS： http://www.cnblogs.com/jiangyu666/p/8522547.html
微服务架构的分布式事务解决方案： http://www.roncoo.com/article/detail/124243