Apache RocketMQ

分布式事务处理机制共有四种： 两阶段提交 TCC事务（事务补偿） 本地消息表（异步确保）， MQ事务消息。 两阶段提交： 与数据库XA事务一样，两阶段提交使用XA协议。 两阶段提交这种方案属于牺牲了一部分可用性来换取的一致性。 优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。 缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如分布式系统跨接口调用。 TCC事务： TCC其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿操作。分为三个阶段： Try阶段主要是对业务系统做检测和资源预留。 Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 Cancel阶段主要是在业务执行错误，需要回滚的状态下，执行的业务取消，预留资源释放。 优点：跟2阶段提交比起来，实现及流程相对简单了些，但数据的一致性也要比2阶段提交要差一些。 缺点：在2，3步中都可能失败。TCC是一种应用层的补偿方式，需要程序员在实现时写很多补偿的代码，一些场景中，一些业务流程用TCC不太好定义及处理。 本地消息表： 使用最多的，核心思想是将分布式事务拆分成本地事务进行处理，来源于ebay。 基本思路就是： 消息生产方

RocketMQ是阿里出品的一款开源的消息中间件，让其声名大噪的就是它的事务消息的功能。在企业中，消息中间件选择使用RocketMQ的还是挺多的，这一系列的文章都是针对RocketMQ的，咱们先从RocketMQ的一些基本概念和环境的搭建开始聊起。 RocketMQ由4部分组成，分别是：名称服务（Name Server）、消息队列（Brokers）、生产者（producer）和消费者（consumer）。这4部分都可以进行水平扩展，从而避免单点故障，如下图， 这是RocketMQ官网上的一张图，非常清晰的列出了4个部分，并且都是集群模式。下面我们就分别说一说这4部分。 名称服务（NameServer） Name Server扮演的角色是一个注册中心，和Zookeeper的作用差不多。它的主要功能有两个，如下： broker的管理：broker集群将自己的信息注册到NameServer，NameServer提供心跳机制检测每一个broker是否正常。 路由管理：每一个NameServer都有整个broker集群和队列的信息，以便客户端（生产者和消费者）查询。 NameServer协调着分布式系统中的每一个组件，并且管理着每一个Topic的路由信息。 Broker Broker主要是存储消息，并且提供Topic的机制。它提供推和拉两种模式，还有一些容灾的措施，比如可以配置消息副本

本文转载自微信公众号「三太子敖丙」，作者三太子敖丙。转载本文请联系三太子敖丙公众号。 前言 上一篇文章已经讲完分布式了，那暖男说要讲分布式事务那就一定会讲，只是我估计大家没料到暖男这么快就肝好了吧? 事务想必大家并不陌生，至于什么是 ACID，也是老生常谈了。不过暖男为了保证文章的完整性确保所有人都听得懂，我还是得先说说 ACID，然后再来介绍下什么是分布式事务和常见的分布式事务包括 2PC、3PC、TCC、本地消息表、消息事务、最大努力通知。 事务 严格意义上的事务实现应该是具备原子性、一致性、隔离性和持久性，简称 ACID。 原子性(Atomicity)，可以理解为一个事务内的所有操作要么都执行，要么都不执行。 一致性(Consistency)，可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。 隔离性(Isolation)，指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。 持久性(Durability)，指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。 而通俗意义上事务就是为了使得一些更新操作要么都成功，要么都失败。

什么是分布式架构？ 分布式架构是分布式计算技术的应用和工具，其中J2EE技术应用较为广泛，它简化和规范多层分布式企业应用系统的开发和部署，它可以给分布式应用软件提供在各种技术间共享资源的平台 分布式架构发展 众所周知，传统架构单一无分层，模块之间耦合性过高导致稳定性和扩展性较差，无法满足互联网高速迭代变化的脚步，技术架构也会发生很大变化。传统架构逐渐分化为分布式架构。提供更稳定、容错、高可用的特质。演变过程如下图所示 阶段1 阶段2 阶段3 阶段4 阶段5 分布式架构设计理念和目标 设计理念： 分布式架构的核心理念按照一定维度（功能、业务、领域）等，对系统进行拆分，通过合理的拆分结构，实现各业务模块解耦，同时通过系统级容错设计，在廉价硬件基础设施上构建起高可用、可扩展的开放技术体系。 目标： 设计目标可以明确方向，通过设计驱动和方向的把控，朝着既定方向前行并最终实现目标。设计目标分为以下方面： • 系统拆分 a.以业务为导向，充分了解系统业务模型，按不同层面的业务模型上可以划分为主模型、次模型。业务模型在一定的比例上能够凸显出系统的业务领域及边界 b.业务依赖范围，由于业务存在重复依赖，从业务边界中按照业务功能去细分 c.把拆分结构图梳理出来，按照系统周边影响从小到大逐渐切换 d.拆分过程中尽量不要引入新的技术或者方案，如需讨论评估后再实施 • 业务模块解耦

延迟任务 什么是延迟任务 需要延迟一段时间才需要处理的任务. 比如订单关闭, 电商平台一般会给用户30分钟左右交钱时间, 当超时未交钱就需要关闭订单. 订单的延时关闭就是一种延迟任务. 怎么实现延迟任务 定时任务 最普遍的做法应该就是定时任务了, 比如订单关闭例子, 我们会将订单存储在表中, 通过定时任务定时扫表, 比如10分钟一次, 对扫描结果进行时间处理, 如果是超时订单则执行关闭操作. 定时任务实现简单, 缺点是时间延迟时间不准确, 在订单例子中, 如果第一次扫描发现订单为29分钟未支付, 那么该订单只能在第二次扫描时执行关闭, 此时订单已经是39分钟未支付了. 为了提供时间准确性, 我们可以减少定时任务时间, 比如一分钟一次. 时间越短准确性越高, 但是资源消耗的也越多. RabbitMQ延迟队列 RabbitMQ本身没有延迟队列的概念, 但是它在处理死信时使用了类似的功能. 当队列中出现死信, 我们可以让它路由到指定的队列中, 然后再消费该队列消息, 达到延迟功能. 那么什么是死信 dead-lettered message? 官网解释在以下三种情况下message可以成为dead-lettered message 1 The message is negatively acknowledged by a consumer using basic.reject or

Sentinel ：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Nacos ：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 RocketMQ ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。 Dubbo ：Apache Dubbo™ 是一款高性能 Java RPC 框架。 Seata ：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。 Alibaba Cloud ACM ：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。 Alibaba Cloud OSS : 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。 Alibaba Cloud SchedulerX : 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。 Alibaba Cloud SMS : 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。 来源： oschina 链接： https://my.oschina.net/u

云栖号案例库： 【点击查看更多上云案例】 不知道怎么上云？看云栖号案例库，了解不同行业不同发展阶段的上云方案，助力你上云决策！ 公司介绍 南瓜电影App是国内领先的专注于影视精品化运营的垂直类视频产品，在移动互联网、OTT等客户端为用户提供差异化内容运营服务，是国内唯一为用户提供专注于精品电影电视剧的全会员制视频App。南瓜电影曾出品大量制作精良、题材健康的优质自制剧及电影，并与全球超过150家独立制片公司达成战略合作，获得优质影视内容版权。经过多年的发展，南瓜电影在国内为超过2千万的会员提供优秀精品影视服务，还在海外特别是东南亚地区积累了大量用户群体。 业务痛点 在南瓜电影的业务场景中，用户客户端与服务端之间存在频繁的双向交互，比如续费管理、内容推送、会员互动、评论提交等，其中有很多业务消息都需要同时发往多个客户端。 传统的Websocket协议或者基于TCP/UDP自建通讯协议都存在业务逻辑实现困难。 处理断线重连，错误重发等复杂的技术问题导致开发负担重，对用户体验好感度造成巨大影响。 解决方案 为了适应业务的快速发展，提升用户体验，南瓜电影决定采用MQTT方案来解决服务端与客户端之间的双向消息通讯。 阿里云提供的微消息队列MQTT+消息队列RocketMQ产品组合非常完美的实现了这个方案，让南瓜电影的技术团队通过非常简单的方式，快速接入这一套成熟、健壮的MQTT消息体系

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 一、背景 传统单体系统时代，一个系统操作一个数据库存储。在系统运行时，单次请求或者说单个线程内对同一数据库数据的多次操作，均可通过开启本地事务，依赖数据库提供的事务特性，实现单个请求涉及数据操作的事务管理。但随着系统业务快速增长，单机系统无法支撑增长后的业务体量，数据库拆分、根据存储特性选用多种数据存储、系统拆分为微服务架构等都是常见的解决手段。 但是伴随这架构演进，在微服务架构体系中，传统单体系统中依赖本地事务的方式在分布式环境中已经无法满足需求，因为一个请求涉及的数据操作可能涉及多个服务、多次远程调用甚至多个数据存储。因此，在微服务架构体系，倘若特定场景下的核心业务流程，需要在业务处理时实现单次请求的事务管理，必须引入满足架构要求、满足业务要求的分布式事务技术。 本文主要是结合笔者自身在项目中特定业务落地分布式事务管理时对各项分布式事务解决方案的一些调研和思考，由于三阶段提交并未发现有成熟的开源技术，所以本文并未涉及。另外个人建议先对分布式相关理论比如：CAP、BASE等有基本了解后，再来深入思考各种解决方案，就不会有看时懂了完事忘了的感觉。 二、常见的解决方案 一般产生分布式事务的技术场景有下面三个方面： 微服务下跨服务操作不通数据库实例 单体系统跨数据库实例

序 本文主要研究一下rocketmq-client-go的transactionProducer transactionProducer rocketmq-client-go-v2.0.0/producer/producer.go type transactionProducer struct { producer *defaultProducer listener primitive.TransactionListener } transactionProducer定义了producer及listener属性 NewTransactionProducer rocketmq-client-go-v2.0.0/producer/producer.go func NewTransactionProducer(listener primitive.TransactionListener, opts ...Option) (*transactionProducer, error) { producer, err := NewDefaultProducer(opts...) if err != nil { return nil, errors.Wrap(err, "NewDefaultProducer failed.") } return &transactionProducer{

点击蓝色“ 程序员大帝 ”关注我哟 加个“ 星标 ”，及时阅读最新技术文章 每日鸡汤，好喝 前言 本文属于《从零开始消息中间件》的系列文章，接着上篇文章 《 不要和陌生人说话，消息中间件之 Topic 》，今天来介绍一下 RocketMQ 的核心组件 NameServer。 这个东西很重要，它要管理集群里所有 Broker 的信息，让使用 MQ 的上下游系统可以通过它感知到集群的情况。 开始消息中间件学习的时候，最好有一个切入点，从而搞清楚它的架构设计细节，然后就可以申请一些机器开始落地部署了。 而 NameServer 非常适合我们入手， 因为没有 NameServer 一切都无从谈起，可以说这是 RocketMQ 运行的起点。 正文 01 什么是 NameServer？ NameServer 也称之为路由中心，它的角色主要是为了感知集群里所有的节点与组件，然后配合生产者和消费者，使其能够和 MQ 系统进行通信。 针对目前流行的三种消息中间件 Kafka、 RabbitMQ 和 RocketMQ ，它们对路由中心的实现均有所不同。 Kafka 的路由中心实现相对复杂、混乱，它由 ZooKeeper 以及某个作为 Controller 的 Broker 共同完成的。 RabbitMQ 的 话 是 集 群 每个节点同时也会扮演了路由中心的角色。 而 RocketMQ