首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

RocketMQ 可视化环境搭建和基础代码使用

RocketMQ 是一款分布式消息中间件,最初是由阿里巴巴消息中间件团队研发并大规模应用于生产系统,满足线上海量消息堆积的需求, 在 2016 年底捐赠给 Apache 开源基金会成为孵化项目,经过不到一年时间正式成为了 Apache 顶级项目。 早期阿里曾经基于 ActiveMQ 研发消息系统, 随着业务消息的规模增大,瓶颈逐渐显现,后来也考虑过Kafka,但因为在低延迟和高可靠性方面没有选择,最后才自主研发了 RocketMQ, 各方面的性能都比目前已有的消息队列要好,RocketMQ 和 Kafka 在概念和原理上都非常相似,所以也经常被拿来对比;RocketMQ 默认采用长轮询的拉模式, 单机支持千万级别的消息堆积,可以非常好的应用在海量消息系统中。 本文分为三部分,如下图所示:

03

【分布式事务】基于RocketMQ搭建生产级消息集群?

目前很多互联网公司的系统都在朝着微服务化、分布式化系统的方向在演进,这带来了很多好处,也带来了一些棘手的问题,其中最棘手的莫过于数据一致性问题了。早期我们的软件功能都在一个进程中,数据的一致性可以通过数据库本地事务来加以控制。而在分布式架构下,原本比较完整的本地功能可能被拆分成了多个独立的服务进程。与之前相比,同样一笔业务订单此时可能会经历很多服务模块的处理,调用链路会变得很长,例如某电商平台,一笔购物订单可能会经过:商品中心、订单、支付、物流等多个服务的调用,而这可能还只是比较粗粒度的划分,某些比较大型的服务,如支付系统,可能本身又会按照分布式的架构拆分成多个微服务,所以整个业务的调用链路会变得更加冗长。 而这不可避免的就会产生数据不一致的问题,为了实现业务上的最终一致性,功能比较独立的系统,如订单系统与支付系统就会通过额外的业务逻辑设计来确保彼此之间的最终一致性,如订单系统会通过订单的支付状态来保持与支付系统的数据一致,而支付系统则会提供支付状态查询接口,或者实现最大可能的主动回调功能,来确保二者数据状态的最终一致。此外可能还会通过日终的订单对账来发现不一致的数据,并进行数据校正。 但是这些都只是业务逻辑上的手段,对于某些内部服务之间的调用,如果可以通过分布式事务解决方案来加以保证的话,其实是可以大大减少一些不必要的复杂业务逻辑的。实际上,目前市面上能够提供分布式事务解决方案、又比较成熟的开源技术框架比较少,而RocketMQ在4.3.0之后的版本提供了事务消息的功能,因为RocketMQ本身拥有比较多的生产实践的关系,所以这一功能备受关注,作者所在的公司也有一些实践。 以此为契机,为了给大家关于分布式事务一个比较清晰的认识,这里我打算以RocketMQ的事务消息功能为示例,来相对全面的总结下分布式事务的内容。本篇文章的主要内容,是先介绍如何搭建一套生产级的RocketMQ消息集群,以此准备下试验环境。在下一篇《【分布式事务】基于RocketMQ的分布式事务实现》会整体介绍下分布式事务的概念和原理,并做一些代码级的试验。

03
领券