rocketmq怎么保证消息一致性_采用消息队列实现数据一致性方法

随着企业级应用的业务复杂度和规模的不断扩大, 传统的单体应用系统在维护、部署、扩展以及稳定性、并发性等方面, 普遍存在难以逾越瓶颈, 这也导致各种相对独立的传统软件系统在集成时面临的困难, 如系统堆砌、问题定位难、扩展性差、可靠性不高、维护成本高等[, 为适应移动互联网高速发展以及在项目开发敏捷、精益、持续交付等应用需求背景, 传统的单体应用系统面临功能重复开发、功能监控与评估(性能)难以进行, 由于软件构件复用效率低, 当面对业务需求变更时, 使得应用系统臃肿、维护困难, 频繁部署, 甚至给软件测试带来更多不确定性, 导致系统无法持续工作[, 此外高并发性是单体应用难以逾越的鸿沟, 为解决上述问题, 使用微服务(micro-service)实现组件化成为系统设计的新选择, 并得到飞速发展和应用, 微服务架构通过将系统按服务组件化分解, 服务之间通过Http等通信协议进行协作, 并且各个服务都可单独开发、部署, 最终通过服务之间组合与调用对外完成系统功能[.

微服务在解决上述问题同时, 也引入了诸多不确定因素, 如执行一项完整的业务, 需要调用多个微服务协同工作, 当依赖微服务调用出现故障(操作失败), 已经完成的微服务如何处理[, 此时主要涉及微服务的可用性与数据一致性等问题, 针对上述问题, 本文首先阐述了单体系统中事务与分布式系统事务的基本原理, 分析了微服务在数据一致性问题上遵循的原则, 提出了一种使用事务型消息队列实现微服务数据最终一致性方法, 通过典型应用场景分析, 给出使用RocketMQ消息队列实现了分布式数据一致性方法, 通过实验表明事务型消息在解决上述问题时具有易于实现、可靠性高、并发处理能力强等特点, 最后总结RocketMQ事务型消息队列实现难点及不足.

1 数据一致性基本原则

传统的单体应用系统中, 通常使用一个关系型数据库, 通过关系型数据库事务保证数据的一致性, 这种事务有四个基本要素(ACID)[: 原子性、一致性、隔离性、持久性. 为了应对高并发的挑战, 应用系统需要多个数据库来支持, 可通过分布式事务来保证数据一致性, 根据CAP理论: 分布式系统不可能同时满足一致性、可用性和分区容错性这三个要求, 最多只能同时满足两个[. 鉴于网络硬件出现闪断、延迟丢包等问题不可避免, 分区容忍性必须需要实现, 同时可用性体现了分布式应用系统持续提供服务的能力, 若满足一致性则需付出在满足一致性之前阻塞其他并发访问的代价[, 事实上可用性与分区容忍性优先级要高于数据一致性, 所以只能在数据一致性上做出取舍, 分布式数据一致性级别又可分为:

强一致性: 类似于单体事务数据一致性, 但实现起来往往对系统的并发性能影响大.

弱一致性: 约束了数据更新成功后, 不承诺立即可以读到写入的数据, 也不久承诺多久之后数据能够达到一致, 但会尽可能地保证到某个时间级别(比如秒级), 数据能够达到一致状态.

最终一致性: 作为弱一致性的一个特例, 系统会保证在一定时间内, 能够达到数据一致的状态.

在微服务架构中, 数据访问与分布式架构相比更加复杂, 通常情况下, 数据都是每个微服务私有, 只能通过API的方式访问数据. 这种方式可以实现微服务间

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值