<>强前言
目前很多互联网公司的系统都在朝着微服务化,分布式化系统的方向在演进,这带来了很多好处,也带来了一些棘手的问题,其中最棘手的莫过于数据一致性问题了。早期我们的软件功能都在一个进程中,数据的一致性可以通过数据库本地事务来加以控制。而在分布式架构下,原本比较完整的本地功能可能被拆分成了多个独立的服务进程。与之前相比,同样一笔业务订单此时可能会经历很多服务模块的处理,<强>调用链路会变得很长强,例如某电商平台,一笔购物订单可能会经过:<强>商品中心,订单,支付,物流等多个服务的调用,而这可能还只是比较粗粒度的划分,某些比较大型的服务,如支付系统,可能本身又会按照分布式的架构拆分成多个微服务,所以整个业务的调用链路会变得更加冗长。
而这不可避免的就会产生数据不一致的问题,为了实现业务上的最终一致性,然后功能比较独立的系统,如订单系统与支付系统就会通过额外的业务逻辑设计来确保彼此之间的最终一致性,如订单系统会通过订单的支付状态来保持与支付系统的数据一致,而支付系统则会提供支付状态查询接口,或者实现最大可能的主动回调功能,来确保二者数据状态的最终一致。此外可能还会通过日终的订单对账来发现不一致的数据,并进行数据校正。
但是这些都只是业务逻辑上的手段,对于某些内部服务之间的调用,如果可以通过分布式事务解决方案来加以保证的话,其实是可以大大减少一些不必要的复杂业务逻辑的。实际上,目前市面上能够提供分布式事务解决方案,又比较成熟的开源技术框架比较少,而<强> RocketMQ安装在4.3.0之后的版本提供了事务消息的功能强劲,因为RocketMQ本身拥有比较多的生产实践的关系,所以这一功能备受关注,作者所在的公司也有一些实践。
以此为契机,为了给大家关于分布式事务一个比较清晰的认识,这里我打算以RocketMQ的事务消息功能为示例,来相对全面的总结下分布式事务的内容。本篇文章的主要内容,是先介绍如何搭建一套生产级的RocketMQ消息集群,以此准备下试验环境。
<>强什么是RocketMQ
RocketMQ是阿里开源的并贡献给Apache基金会的一款分布式消息平台,它具有低延迟,高性能和可靠性,万亿级容量和灵活的可伸缩性的特点,单机也可以支持<强>亿级的消息堆积能力强,单机写入<强> TPS单实例约7万条/秒强,单机部署3个代理,可以跑到最万高12条/秒。
基于以上强大的性能,以及阿里的技术影响力,RocketMQ目前在国内互联网公司中被使用得比较广泛。那么,我们先大概来了解一下RocketMQ的整体结构吧!
整个RocketMQ消息系统主要由如下<强> 4个部分组成:
从中间件服务角度来看整个RocketMQ消息系统(服务端)主要分为:<强> NameSrv和经纪人两个部分。
<强> NameSrv :在RocketMQ分布式消息系统中,NameSrv主要提供两个功能:
提供服务发现和注册,这里主要是管理代理,NameSrv接受来自代理的注册,并通过心跳机制来检测代理服务的健康性;
提供路由功能,集群(这里是指以集群方式部署的NameSrv)中的每个NameSrv都保存了代理集群(这里是指以集群方式部署的代理)中整个的路由信息和队列信息。这里需要注意,在NameSrv集群中,每个NameSrv都是相互独立的,所以每个代理需要连接所有的NameSrv,每创建一个新的话题都要同步到所有的NameSrv上。
<强>代理:主要是负责消息的存储,传递,查询以及高可用(HA)保证等。其由如下几个子模块(源码总体上也是这么拆分的)构成:
<李> remoting,是代理的服务入口,负责客户端的接入(生产者和消费者)和请求处理。 <李>客户端、管理客户端和维护消费者对于主题的订阅。 <李>商店,提供针对存储和消息查询的简单的API(数据存储在物理磁盘)。 <李>哈,提供数据在主从节点间同步的功能特性。 <李>指数,通过特定的关键构建消息索引,并提供快速的索引查询服务。
而从客户端的角度看主要有:<强>生产者,消费者两个部分。
* 生产商:消息的生产者,由用户进行分布式部署,消息由生产者通过多种负载均衡模式发送到代理集群,发送低延时,支持快速失败。
消费者:消息的消费者,也由用户部署,支持推和拉两种消费模式,支持集群消费和广播消息,提供实时的消息订阅机制,满足大多数消费场景。
教你一手如何基于RocketMQ搭建生产级消息集群
