必须采用最终一致性方案，通过Swoole协程实现本地事务+消息表双写、Redis Stream/Kafka事务消息投递及幂等消费，确保分布式数据一致。
要在分布式系统中确保跨多个服务的数据操作最终达成一致，必须放弃强一致性模型，转而采用基于消息驱动的最终一致性方案，Swoole协程能力可高效支撑消息生产、消费与本地事务绑定。
设计本地事务+消息表双写模式
第一步：在业务数据库中新建一张message_log表，字段至少包含id、topic、payload、status（0=待发送，1=已发送，2=已确认）、created_at。
第二步：业务逻辑执行时，在同一个数据库事务内完成业务数据变更 + 插入一条状态为0的消息记录。这一步必须在事务内完成，【否则消息写入失败但业务已提交，将彻底丢失事件】。
第三步：启动一个独立的Swoole Task Worker进程，定时扫描message_log表中status = 0的记录，使用Swoole协程Redis客户端或Kafka Producer异步投递消息；投递成功后，用原子UPDATE将对应记录status置为1。
实现可靠消息投递与补偿机制
方法一：基于Redis Stream的ACK机制
用Swoole协程客户端向Redis Stream写入消息，同时记录message_id到message_log表；消费者成功处理后，调用XACK标记该ID为已确认；后台Task进程每30秒扫描status = 1但未被ACK超过5分钟的消息，重新投递并更新重试次数。
方法二：Kafka事务消息（需Broker 0.11+）
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
在Swoole Server中初始化KafkaProducer并启用enable.idempotence=true；执行$producer->initTransactions()→$producer->beginTransaction()→写业务DB→$producer->send($msg)→$producer->commitTransaction()。若任意环节失败，整个事务回滚，保证“要么全不发，要么必送达”。
【注意：Kafka事务仅保证Producer端语义，Consumer端仍需幂等处理】
构建下游服务的幂等消费逻辑
第一步：消费者接收到消息后，先解析payload中的唯一业务ID（如order_id:action_timestamp）。
第二步：使用Swoole协程Redis客户端执行SETNX idempotent:{business_id} 1，并设置过期时间（建议≥业务最大处理耗时的3倍）。
第三步：若SETNX返回1，说明是首次处理，执行业务逻辑并更新状态；若返回0，直接丢弃消息——这一步是最终一致性的最后防线，【缺失它会导致重复扣款、重复发货等严重资损】。
第四步：业务逻辑执行完毕后，无论成功失败，都需在本地记录消费结果（如写入consumer_log表），用于后续人工对账与问题追溯。
