随手记-为了保证实时一致需要使用强制事务

事务相关原则

1. 强制事务保证实时一致：为确保数据在任何时刻的一致性，对于一些关键场景需要使用强制事务来保障数据的实时准确性。
2. 互联网强调最终一致：在互联网环境中，允许业务线在时间轴上的某个阶段数据和动作存在不一致情况，但最终必须保证数据的一致性。
3. 第三方交互的消息机制：当与第三方系统进行交互时，务必采用消息机制作为中间层，以避免第三方系统的问题导致自身系统被拖垮。

消息中间件应用场景

1. 大数据量请求扩展：主要用于减少系统中重要业务的压力，可处理大数据量请求。不过并非所有请求都适合用消息中间件异步处理，对于像ajax的主要业务且需要实时更新数据的情况，仍需采用同步方式。
2. 特殊消息类型：
   • 顺序消息：在一些业务场景中，如订单下单后通知出库信息，若消息顺序错误，可能导致报表统计数据不一致，所以需要保证消息顺序。同时存在后发消息先被消费的可能，因此要处理好顺序消息。
   • 定时消息：按照设定的时间进行消息发送。
   • 重复消息：当消费者未响应时，投递者会重复投递消息，例如气象系统通知消息。且要保证消息的幂等性，即无论消息投递多少次，都不会影响请求或数据的一致性，如订单通知始终只对应一条订单操作。
3. 高并发场景：例如直播业务中更新粉丝数的操作，可利用消息中间件应对高并发情况。

消息中间件对比

1. RabbitMQ：其特点是放弃一定的吞吐量来保证数据一致性，当达到一定吞吐量时，可能需要进行特定的定制。
2. RocketMQ：目前已不再进行维护。
3. KafkaMQ：具有高吞吐量，但数据一致性表现不佳，存在数据丢失的风险。

DRDs（分布式关系型数据库服务）

DRDs通过member_id来定位数据库，用于分布式数据库的管理和数据定位。

TXC（Taobao Transaction Construction）

1. 数据库事务业务场景：由于单库存储在容量和性能上存在限制，TXC可用于解决分布式数据库事务相关问题，以满足业务需求。
2. 分布式session处理：在分布式系统中，需要将session存放在redis中，以保证在不同节点间session的共享和一致性。

下订单业务示例

1. 操作消耗差异：下订单操作中，insert操作消耗相对较低，而update操作消耗较高。在高并发情况下，为避免性能瓶颈，需要将update等操作进行异步化处理。
2. 消息中间件与事务：消息中间件无法保证消息一定能发送成功，且本身不支持事务。但在分布式系统中，可通过半事务机制实现最终一致性。
3. 半事务理解：
   • 第一次理解：客户端以分布式、高并发的方式发送消息给消息中间件，而消费者（服务端）在消费消息时必须遵循事务规则（此理解可能存在错误）。
   • 第二次理解：对于分布式事务，假设有两个存在先后顺序的事务，如事务1为消费10，事务2为增加10。通过消息中间件处理，事务1的消息发送给消息中间件后，消费者可消费事务1，但事务2必须在事务1执行完成后才能启动。
4. 消费顺序：以双十一的下订单、付款、扣款流程为例，消费者必须按照事务的执行顺序，先消费下订单消息并提示用户下订单成功，接着处理付款消息并提示付款成功，最后进行扣款操作。按照这样的顺序逐步实现业务逻辑，以保证业务流程的正确和数据的一致性。