-----分布式事务------
单系统事务ACID特性不适用分布式系统，建议把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。不论任何一
种方案都会增加系统的复杂度，这样的成本实在是太高，千万不要因为追求某些设计，而引入不必要的成本和复杂度。
CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架构师来说，CAP 就是你的入门理论。
C (强一致性)：对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据来说，如果在某个
节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是
分布式不一致。
A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，
一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返
回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。
P (分区容错性)：当出现网络分区后，系统能够继续工作。打个比方，这里集群有多台机器，有台机器网络出现了问题，但是
这个集群仍然可以正常工作。
CAP不可能共存，P是必然性，所以只能选择CP或AP架构。但是也不是说完全放弃C或A。于是提出以下：
BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写，
是对 CAP 中 AP 的一个扩展。
基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致。
最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
1、2PC(两阶段提交):采用XA Transactions的预提交和提交。
保证了一致性(还是有可能不一致)，容易形成阻塞性能较低。
2、TCC 补偿功能和重试
Try阶段：尝试执行，完成所有业务检查（一致性），预留必需业务资源（准隔离性）。
Confirm 阶段：确认真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等
设计，Confirm 失败后需要进行重试。
Cancel 阶段：取消执行，释放Try阶段预留的业务资源，Cancel操作满足幂等性。Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。
3、MQ事务
异步确保，向银行转账就可以。
转账放扣钱后向MQ消费方发送一个消息，如果收款方失败可以不断重试直到成功。
-------分布式锁---------------
可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器-上的一个线程执行。
这把锁要是一把可重入锁（避免死锁）。
这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）。
这把锁最好是一把公平锁（根据业务需求考虑要不要这条）。
有高可用的获取锁和释放锁功能。
获取锁和释放锁的性能要好。
乐观锁
基于表字段做分布式锁
悲观锁
Redis的setnx()、 delete()和expire()方法
1)setnx 的含义就是 SET if Not Exists，其主要有两个参数setnx(key,value)。该方法是原子的，
如果key不存在，则设置当前ke 成功，返回1；如果当前key已经存在，则设置当前key失败，返回0。
2)expire 设置过期时间，要注意的是 setnx 命令不能设置 key 的超时时间，只能通过 expire() 来对 key 设置。
ZooKeeper
zk一般由多个节点构成（单数），采用zab一致性协议。因此可以将zk看成一个单点结构，对其修改数据其内部自动将所有节点数据进行修改而后
才提供查询服务。zk的数据以目录树的形式，每个目录称为znode，znode中可存储数据（一般不超过1M），还可以在其中增加子节点。子节点有
三种类型。序列化节点，每在该节点下增加一个节点自动给该节点的名称上自增。临时节点，一旦创建这个znode的客户端与服务器失去联系，这个
znode也将自动删除。最后就是普通节点。Watch 机制，client 可以监控每个节点的变化，当产生变化会给 client产生一个事件。