适用场景
不适用场景
此处先列举两个不适用场景，除此之外，适用其他绝大多数业务场景。
数据实时性要求较高的业务场景
txle核心是解决分布式架构中的数据最终一致性，所以在数据实时一致性方面有所延迟。
唯一补偿失败的业务场景：并发 + 热点数据 + 异常 + 中间笔业务 + 非计算型赋值
当然，这里仅分析业务场景，txle框架系统、网络或硬件等故障，这里暂不做讨论。
补偿失败的业务场景需要同时满足五大因素：并发 + 热点数据 + 异常 + 中间笔业务 + 非计算型赋值，该五大因素同时出现情况，会导致补偿失败，也是目前唯一导致补偿失败的业务场景。当然，补偿失败会有上报差错平台以及本地存储分析的等补救措施。
对于一般业务系统而言，同时满足以上五大因素，相信概率不是特别大，故在此业务场景概率不大的情况下，也是相对适合的。
适用复杂场景
并发 + 热点数据 + 异常 + 最后一笔业务
当热点数据业务运行异常时，若发生异常的业务为该热点数据补偿时刻的最后一笔业务，则可以被正确地补偿成功。
示例：用户A在某店铺下单了某件商品，与此同时，用户B也在同店铺下单了同件商品
并发场景之一：
- 用户A下单成功
- 用户B下单成功
- 用户A扣减库存成功
- 用户B库存扣减失败
最终，txle对用户B的订单进行补偿操作，由于A在B之前下单，所以本次补偿完全不受A订单的影响，因此可以被成功地补偿，保证了数据的最终一致性。
并发 + 热点数据 + 异常 + 中间笔业务 + 计算型赋值
当热点数据业务运行异常时，若发生异常的业务为该热点数据补偿时刻的中间笔业务，理论上讲会收到后续业务的影响，但若被补偿的热点数据为计算型赋值的数据，则也可以被正确地补偿成功。
示例：用户A和用户B同时订购相同火车票，该票目前余票总数假设为10张，且无他人购此票情况下
并发场景之一：
- 用户A订票成功，但未支付
- 余票总数扣减成功，即SQL(简化版)：10-1=9张余票
- 用户B订票成功，且已支付
- 余票总数扣减成功，即SQL：9-1=8张余票
- 用户A在指定支付时间内未支付，故余票总数需被再加回一张，即SQL：8+1=9张余票
余票总数在数据库中以数值类型存储，即可通过计算公式对其赋值，因此即使中间笔业务出现异常，也可以被正确地补偿成功，保证了数据的最终一致性。
其它适用场景
上面介绍了几种较为复杂的业务场景，可以看出，除对实时性要求高和需满足五大因素且高概率的业务场景不太适合，其它业务场景都非常适用。再次强调，如果业务中含有满足五大因素的可能性，但概率不高，也是值得推荐的。
总结
- 适用于数据实时性要求不高的绝大多数并发业务场景
- 适用于热点数据的大多数并发业务场景
- 适用于热点数据的绝大多数非并发业务场景
- 适用于非热点数据的绝大多数并发业务场景
- 适用于热点数据的绝大多数非并发业务场景
| 并发业务 | 非并发业务 | |
|---|---|---|
| 热点数据 |   |
|
| 非热点数据 | |
|