1.分布式事务
普通事务，通过数据库回滚，通常用Spring的@transactional注解实现，原理时数据库的代理模式与数据库的事务
分布式事务，有以下几种模式:
(1) 可靠消息最终一致性方案
** A先发送准备信息个体MQ，MQ收到后（未收到则事务不执行），通知A执行，A执行后，发送确认消息给MQ，如果这条确认消息丢失，MQ会通过准备消息回查A是否成功（定时轮询），成功通知B，否则询问A回滚还是重来一次，收到确认消息后，再给B发消息不断执行**
大多分布式事务用这种
（2）努力通知方案
和可靠消息方案类似，但不会一直重复执行，而是执行一定次数就不执行了
并且不发准备消息，直接执行A事务，执行完了定期通知中间件，通知几次失败就不通知了，中间件通知B系统也一样，通知几次失败就不通知了
这种适用于B事务不是很重要的情况，如发送提醒短信
（3）TCC 强一致性方案
- Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
- Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
- Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。
B系统事务执行失败时，通过回滚代码，使A事务进行回滚，保证强一致性
一般涉及金钱交易时用，但代码补偿很严重
2.分布式事务的方案
分时方案：
- 严格划分时间片，交替运行计划任务，当主系统宕机后，备用系统仍然工作，但是处理初期被拉长了。
- 缺点：周期延长了。
** HA高可用方案：**
- 正常情况下主系统工作，备用系统守候，心跳检测发现主系统出现故障备用系统启动。
- 缺点：单一系统，不能做负载均衡，只能垂直扩展，也就是硬件层面的升级，无法做水平扩展
多路心跳方案：
* 采用多路心跳，做服务级，进程级的，IP和端口级别的心跳检测，正常情况是主系统工作，备用系统守候，心跳检测主系统出现故障，备用系统启动，当再次检测到主系统工作，则将执行权交回主系统。* 缺点：开发比较复杂，程序健壮性要求高。
** 任务抢占方案（最优）：**
* A，B两台服务器同时工作，启动需要存在一前一后，谁先启动谁率先加锁，其他服务器只能等待，他们同时对互斥锁进行监控，一旦发现锁被释放，其他服务那个先抢到，那个运行，运行前加排他锁。* 优点：可以进一步实现多服务器横向扩展。* 缺点：开发复杂，程序健壮性要求高，有时候会出现不释放锁的问题。
quartz是一个典型的分布式任务框架，通过将任务分布到多个应用中实现，多个节点彼此独立没有通信，都是通过数据库表的形式感知，一个应用调用了一个服务后会在数据库加上锁，另外的应用便不可以读取了，保证了任务不会重复执行
