为什么要使用分布式事务和分布式锁？
我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。
分布式事务的解决方案
基于可靠消息的最终一致性方案
- 可独立部署、独立伸缩（扩展性）
- 兼容所有实现JMS标准的MQ中间件
- 能降低业务系统与消息系统间的耦合性
- 可实现数据可靠的前提下确保一致性
业务场景：那些不要求立即返回结果的业务，完成时间上的解耦如:对应支付系统会计异步记账业务、银行通知结果信息存储与驱动订单处理
TCC事务补偿型方案（两阶段提交）
* 不与具体的服务框架耦合（在RPC框架中通用）
* 位于业务服务层，而非资源层
* 可以灵活选择业务资源的锁定粒度
* 适用于强隔离性、严格一致性要求的业务场景
* 适用于执行时间较短的业务
业务场景：一个业务逻辑涉及了多个业务组件如：订单处理、资金账户处理、积分账户处理
最大努力通知型方案
业务场景:适用于跨平台业务
如：支付系统的商户通知业务
分布式锁
有的时候，我们需要保证一个方法在同 一时间内只能被同一个线程执行。在单机模式下，可以通过sychronized、锁等方式来实现，在分布式环境下，有以下的解决方案：
数据库锁
1.通过一个一张表的一条记录，来判断资源的占用情况
2.使用基于数据库的排它锁 （即select * from tb_User for update）
3.使用乐观锁的方式，即CAS操作（或version字段）
基于Redis的分布式锁
redis提供了可以用来实现分布式锁的方法，比如redis的setnx方法等。（即redis事务机制可以实现乐观锁CAS）
基于Zookeeper的分布式锁（这种方式最可靠）
基于zookeeper临时有序节点可以实现的分布式锁。大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。
