分布式事务和分布式锁

为什么要使用分布式事务和分布式锁？

我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。

事务的ACID
原子性(Atomicity)：多条指令作为一个集体，要么都执行，要么都不执行
一致性(Consistency)：比如 a=100 b=100 a、b之间交易 总和一定是200,事务必须使数据库从一个一致性状态变换到另外一个一致性状态
隔离性(lsolation)：事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰
持久性：事务一旦提交，它对数据库的改变时永久性的,一个事务一旦被提交，他对数据库中的数据的改变就是永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。

CAP原则
在分布式系统要满足CAP原则，一个提供数据服务的存储系统无法同时满足：数据一致性、数据可用性、分区耐受性。

C数据一致性：所有应用程序都能访问到相同的数据。
A数据可用性：任何时候，任何应用程序都可以读写访问。
P分区耐受性：系统可以跨网络分区线性伸缩。（通俗来说就是数据的规模可扩展）

在大型网站中通常都是牺牲C，选择AP。为了可能减小数据不一致带来的影响，都会采取各种手段保证数据最终一致。

数据强一致：各个副本的数据在物理存储中总是一致的。
数据用户一致：数据在物理存储的各个副本可能是不一致的，但是通过纠错和校验机制，会确定一个一致的且正确的数据返回给用户。
数据最终一致：物理存储的数据可能不一致，终端用户访问也可能不一致，但是一段时间内数据会达成一致。

分布式事务的解决方案

基于可靠消息的最终一致性方案

• 可独立部署、独立伸缩（扩展性）
• 兼容所有实现JMS标准的MQ中间件
• 能降低业务系统与消息系统间的耦合性
• 可实现数据可靠的前提下确保一致性

 业务场景：那些不要求立即返回结果的业务，完成时间上的解耦如:对应支付系统会计异步记账业务、银行通知结果信息存储与驱动订单处理

TCC事务补偿型方案（两阶段提交）
* 不与具体的服务框架耦合（在RPC框架中通用）
* 位于业务服务层，而非资源层
* 可以灵活选择业务资源的锁定粒度
* 适用于强隔离性、严格一致性要求的业务场景
* 适用于执行时间较短的业务

 业务场景：一个业务逻辑涉及了多个业务组件如：订单处理、资金账户处理、积分账户处理

最大努力通知型方案

业务场景:适用于跨平台业务
如：支付系统的商户通知业务

分布式锁
有的时候，我们需要保证一个方法在同 一时间内只能被同一个线程执行。在单机模式下，可以通过sychronized、锁等方式来实现，在分布式环境下，有以下的解决方案：

数据库锁
1.通过一个一张表的一条记录，来判断资源的占用情况
2.使用基于数据库的排它锁 （即select * from tb_User for update）
3.使用乐观锁的方式，即CAS(CAS(Compare And Swap)指比较并交换)操作（或version字段）

基于Redis的分布式锁
redis提供了可以用来实现分布式锁的方法，比如redis的setnx方法等。（即redis事务机制可以实现乐观锁CAS）

基于Zookeeper的分布式锁（这种方式最可靠）
基于zookeeper临时有序节点可以实现的分布式锁。大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。