随着企业级应用的业务复杂度和规模的不断扩大, 传统的单体应用系统在维护、部署、扩展以及稳定性、并发性等方面, 普遍存在难以逾越瓶颈, 这也导致各种相对独立的传统软件系统在集成时面临的困难, 如系统堆砌、问题定位难、扩展性差、可靠性不高、维护成本高等[, 为适应移动互联网高速发展以及在项目开发敏捷、精益、持续交付等应用需求背景, 传统的单体应用系统面临功能重复开发、功能监控与评估(性能)难以进行, 由于软件构件复用效率低, 当面对业务需求变更时, 使得应用系统臃肿、维护困难, 频繁部署, 甚至给软件测试带来更多不确定性, 导致系统无法持续工作[, 此外高并发性是单体应用难以逾越的鸿沟, 为解决上述问题, 使用微服务(micro-service)实现组件化成为系统设计的新选择, 并得到飞速发展和应用, 微服务架构通过将系统按服务组件化分解, 服务之间通过Http等通信协议进行协作, 并且各个服务都可单独开发、部署, 最终通过服务之间组合与调用对外完成系统功能[.
微服务在解决上述问题同时, 也引入了诸多不确定因素, 如执行一项完整的业务, 需要调用多个微服务协同工作, 当依赖微服务调用出现故障(操作失败), 已经完成的微服务如何处理[, 此时主要涉及微服务的可用性与数据一致性等问题, 针对上述问题, 本文首先阐述了单体系统中事务与分布式系统事务的基本原理, 分析了微服务在数据一致性问题上遵循的原则, 提出了一种使用事务型消息队列实现微服务数据最终一致性方法, 通过典型应用场景分析, 给出使用RocketMQ消息队列实现了分布式数据一致性方法, 通过实验表明事务型消息在解决上述问题时具有易于实现、可靠性高、并发处理能力强等特点, 最后总结RocketMQ事务型消息队列实现难点及不足.
1 数据一致性基本原则
传统的单体应用系统中, 通常使用一个关系型数据库, 通过关系型数据库事务保证数据的一致性, 这种事务有四个基本要素(ACID)[: 原子性、一致性、隔离性、持久性. 为了应对高并发的挑战, 应用系统需要多个数据库来支持, 可通过分布式事务来保证数据一致性, 根据CAP理论: 分布式系统不可能同时满足一致性、可用性和分区容错性这三个要求, 最多只能同时满足两个[. 鉴于网络硬件出现闪断、延迟丢包等问题不可避免, 分区容忍性必须需要实现, 同时可用性体现了分布式应用系统持续提供服务的能力, 若满足一致性则需付出在满足一致性之前阻塞其他并发访问的代价[, 事实上可用性与分区容忍性优先级要高于数据一致性, 所以只能在数据一致性上做出取舍, 分布式数据一致性级别又可分为:
强一致性: 类似于单体事务数据一致性, 但实现起来往往对系统的并发性能影响大.
弱一致性: 约束了数据更新成功后, 不承诺立即可以读到写入的数据, 也不久承诺多久之后数据能够达到一致, 但会尽可能地保证到某个时间级别(比如秒级), 数据能够达到一致状态.
最终一致性: 作为弱一致性的一个特例, 系统会保证在一定时间内, 能够达到数据一致的状态.
在微服务架构中, 数据访问与分布式架构相比更加复杂, 通常情况下, 数据都是每个微服务私有, 只能通过API的方式访问数据. 这种方式可以实现微服务间