Saga只允许两个层次的嵌套，顶级的Saga和简单子事务 [1]
在外层，全原子性不能得到满足。也就是说，sagas可能会看到其他sagas的部分结果 [1]
每个子事务应该是独立的原子行为 [2]
在我们的业务场景下，航班预订、租车、酒店预订和付款是自然独立的行为，而且每个事务都可以用对应服务的数据库保证原子操作。
我们在行程规划事务层面也不需要原子性。一个用户可以预订最后一张机票，而后由于信用卡余额不足而被取消。同时另一个用户可能开始会看到已无余票， 接着由于前者预订被取消，最后一张机票被释放，而抢到最后一个座位并完成行程规划。
补偿也有需考虑的事项：
补偿事务从语义角度撤消了事务Ti的行为，但未必能将数据库返回到执行Ti时的状态。（例如，如果事务触发导弹发射， 则可能无法撤消此操作）
但这对我们的业务来说不是问题。其实难以撤消的行为也有可能被补偿。例如，发送电邮的事务可以通过发送解释问题的另一封电邮来补偿。
现在我们有了通过Saga来解决数据一致性问题的方案。它允许我们成功地执行所有事务，或在任何事务失败的情况下，补偿已成功的事务。 虽然Saga不提供ACID保证，但仍适用于许多数据最终一致性的场景。那我们如何设计一个Saga系统？
Saga LogSaga保证所有的子事务都得以完成或补偿，但Saga系统本身也可能会崩溃。Saga崩溃时可能处于以下几个状态：
Saga收到事务请求，但尚未开始。因子事务对应的微服务状态未被Saga修改，我们什么也不需要做。
一些子事务已经完成。重启后，Saga必须接着上次完成的事务恢复。
子事务已开始，但尚未完成。由于远程服务可能已完成事务，也可能事务失败，甚至服务请求超时，saga只能重新发起之前未确认完成的子事务。这意味着子事务必须幂等。
子事务失败，其补偿事务尚未开始。Saga必须在重启后执行对应补偿事务。
补偿事务已开始但尚未完成。解决方案与上一个相同。这意味着补偿事务也必须是幂等的。
所有子事务或补偿事务均已完成，与第一种情况相同。
为了恢复到上述状态，我们必须追踪子事务及补偿事务的每一步。我们决定通过事件的方式达到以上要求，并将以下事件保存在名为saga log的持久存储中：
Saga started event 保存整个saga请求，其中包括多个事务/补偿请求
Transaction started event 保存对应事务请求
Transaction ended event 保存对应事务请求及其回复
Transaction aborted event 保存对应事务请求和失败的原因
Transaction compensated event 保存对应补偿请求及其回复
Saga ended event 标志着saga事务请求的结束，不需要保存任何内容
通过将这些事件持久化在saga log中，我们可以将saga恢复到上述任何状态。
由于Saga只需要做事件的持久化，而事件内容以JSON的形式存储，Saga log的实现非常灵活，数据库（SQL或NoSQL），持久消息队列，甚至普通文件可以用作事件存储， 当然有些能更快得帮saga恢复状态。
Saga请求的数据结构