恰好这两快都在项目中实践了，特此来记录一波
首先得了解分布式下两个重要概念cap理论与BASE理论
分别谈下：
C 一致性（Consistency）、A 可用性（Availability）和 P 分区容错性（Partition tolerance）
该理论的核心就观点是任何软件系统都无法同时满足一致性、可用性以及分区容错性。
作为一个分布式系统，分区容错性是一个必须要考虑的关键点，一个分布式系统一旦丧失了分区容错性，也就表示放弃了扩展性。所以，大部分分布式系统都会在保证分区容错性的前提下在一致性和可用性之间做权衡。
BASE是指基本可用，即允许分区失败，出了问题仅服务降级（Basically Available）、软状态即允许异步（ Soft State）、最终一致性，允许数据最终一致，而不是时刻一致（ Eventual Consistency）
如果说ACID是传统数据库常用的设计理念，追求强一致性模型。则BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
ACID和BASE代表了两种截然相反的设计哲学
基于以上理论，便引出了这次的标题。在许多的分布式系统中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等
背景：分布式系统 负责支付服务开发
分布式事务
场景：用户在前端支付成功，支付模块不仅记录数据还会需要更新订单服务的支付金额，如果使用积分的话还需更改用户积分 发送短信等根据业务场景进行操作。如果在单体系统的话包在一个事务中即可实现。如果在分布式场景中方案有哪些？
1、可靠消息异步确保一致性
项目使用的方案，重点是保证拆分后的单一步骤业务处理操作与消息记录在包同一个事务中，防止漏记录。
2、TCC型
还没弄懂。。。
3、最大努力通知定期校对
依据定时任务主动查询，获取业务消息。适合不追求时效性业务
分布式锁
场景：支付请求的防重处理，异步通知支付状态保证幂等性。
1、redis实现
项目使用的方案，核心就是基于setnx、getSet命令实现。
2、zookeeper实现
没使用过不太熟。。。
3、数据库乐观锁
区别于悲观锁方式（代码for update方式），使用版本号version，更新时检查版本号是否一致。性能是个瓶颈
- 本文标题： 捋一下分布式事务与分布式锁方案
- 文章作者： sherryriver（木木三可）
- 发布时间： 2018.01.10
- 本文链接： https://sherryriver.github.io/2018/01/10/分布式事务与分布式锁/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。