Apache RocketMQ

#<center> SpringBoot整合RocketMQ </center> 上篇博客讲解了服务器集群部署RocketMQ 博客地址： RocketMQ(2)---Docker部署RocketMQ集群 这篇在上篇搭建好的基础上,将SpringBoot整合RocketMQ实现生产消费。 GitHub地址 : https://github.com/yudiandemingzi/spring-boot-study <font color=#FFD700> 一、搭建步骤 </font> 先说下技术大致架构 SpringBoot2.1.6 + Maven3.5.4 + rocketmq4.3.0 + JDK1.8 +Lombok(插件) 1、添加rocketmq包 <!--注意： 这里的版本,要和部署在服务器上的版本号一致--> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.3.0</version> </dependency> 2、JmsConfig（配置类） 连接RocketMQ服务器配置类，这里为了方便直接写成常量。 /** * @Description: 安装实际开发这里的信息 都是应该写在配置里，来读取

1.rocketmq图形化控制台安装 　　虽然rocketmq为用户提供了使用命令行管理主题、消费组以及broker配置的功能，但对于不够熟练的非运维人员来说，命令行的管理界面还是较难使用的。为此，我们可以使用图形化的管理界面来简化管理操作。 　　rocketmq官方推荐的图形化控制台目前还处在不成熟的孵化阶段。仓库地址为( https://github.com/apache/rocketmq-externals )，其中包含了rocketmq相关拓展的、属于孵化期的各种项目。下载源码之后，找到rocketmq-console文件夹，这就是rocketmq官方推荐的图形化控制台项目，基于springboot和angularJS。 　　打开application.properties，能看到一些重要参数的配置，例如端口，nameServer地址，登录权限控制等等。对于启动参数的设置，可以选择直接在配置文件中修改；也可在启动项目时通过命令行指定。 　　 　　为部署项目，先执行maven的打包命令(mvn clean package)，生成jar包。 　　然后执行java -jar rocketmq-console-ng-1.0.1.jar --rocketmq.config.namesrvAddr=localhost:9876(nameServer地址) --server.port

1.消息队列介绍 　　消息队列本质上来说是一个符合先进先出原则的单向队列：一方发送消息并存入消息队列尾部( 生产者投递消息 )，一方从消息队列的头部取出消息( 消费者消费消息 )。但对于一个成熟可靠的消息队列来说，所需要解决的主要问题还包括： 高效可靠的消息投递、存储；能承受高并发的流量冲击，可通过集群部署来解决单点故障 等等。 　　由于消息队列具备了以上特点，因此在如今的微服务架构中能够作为一种中间件，提供许多重要的功能以解决微服务架构中的诸多痛点： 1.应用解耦 　　微服务架构中，存在着众多子系统，共同完成对外部用户的服务。 　　举个例子：当用户在订单系统下单时，订单子系统除了需要执行自己系统的业务逻辑之外，可能还需要调用库存子系统去扣减库存；调用会员子系统去增加用户的积分；调用数据分析子系统去插入用户下单的分析数据等等。用户的一个下单行为横跨了N个业务子系统，如果按照传统的同步串行方式一个接一个的调用，用户的下单操作将会执行较长的时间，对用户不友好。同时，由于是同步调用，一旦某一个子系统出现了宕机，访问超时等问题，整个下单业务都将陷入瘫痪。 　　 消息队列可以将同步的系统调用转为异步的消息投递，一定程度上解除业务子系统间的耦合。 当订单子系统执行完本地逻辑后，只需发送一个标识下单成功的消息，让下游依赖的子系统订阅此消息，消费处理消息来完成对应的业务。这样

温馨提示：建议参考代码RocketMQ4.4版本，4.5版本引入了多副本机制，实现了主从自动切换，本文并不关心主从切换功能。 @ TOC 1、初识主从同步 主从同步基本实现过程如下图所示： RocketMQ 的主从同步机制如下： A. 首先启动Master并在指定端口监听； B. 客户端启动，主动连接Master，建立TCP连接； C. 客户端以每隔5s的间隔时间向服务端拉取消息，如果是第一次拉取的话，先获取本地commitlog文件中最大的偏移量，以该偏移量向服务端拉取消息； D. 服务端解析请求，并返回一批数据给客户端； E. 客户端收到一批消息后，将消息写入本地commitlog文件中，然后向Master汇报拉取进度，并更新下一次待拉取偏移量； F. 然后重复第3步； RocketMQ主从同步一个重要的特征：主从同步不具备主从切换功能，即当主节点宕机后，从不会接管消息发送，但可以提供消息读取。 温馨提示：本文并不会详细分析RocketMQ主从同步的实现细节，如大家对其感兴趣，可以查阅笔者所著的《RocketMQ技术内幕》或查看笔者博文： https://blog.csdn.net/prestigeding/article/details/79600792 2、提出问题 主，从服务器都在运行过程中，消息消费者是从主拉取消息还是从从拉取？ RocketMQ主从同步架构中

MQ初窥门径 全称(message queue)消息队列,一个用于接收消息、存储消息并转发消息的中间件 应用场景 用于解决的场景，总之是能接收消息并转发消息 用于异步处理，比如A服务做了什么事情，异步发送一个消息给其他B服务。 用于削峰，有些服务(秒杀)，请求量很高，服务处理不过来，那么请求先放到消息队列里面，后面按照能力处理，相当于蓄水池。 应用解耦、消息通讯等等 总之MQ是可以存放消息并转发消息的中间件，场景取决于拿这个能力去解决什么问题 MQ概念模型 MQ向别人承诺的场景是接收消息，存储，并可以转发消息 接收消息 接收消息，那么接收谁的消息，为了说明这个问题，那么mq需要引入一个概念，叫做生产者，也就是发送消息的服务，否则没有办法来区分是谁发的消息，生产者通过网络发送消息就可以，中间的细节我们先不探讨。 那么还有一个问题就是消息发送给谁？ 我在发送消息的时候，指明我要发送给谁，就像发送短信一样，你需要指明你要发送给谁？ 这种方案在使用中是有问题的，因为在现在业务很多场景中, 发送方其实根本不知道对方是谁，他只是将自己的状态发送出来，那么谁需要这个消息，谁就接收，第二个如果指明了接收方，那么以后增加一个接收方就要改一下配置或者代码，将发送消息的人跟接收消息的人绑定在一起了 那么有没有方案，解耦的最好办法就是中间人，也叫中间层，我只发送给第三方，谁要消息，问第三方要

【推荐阅读】微服务还能火多久？>>> 最近学习使用 rocketmq，需要搭建 rocketmq 服务端，本文主要记录 rocketmq 搭建过程以及这个过程踩到的一些坑。至于有多简单呢，在本机已有Docker环境的情况下只需要三步即可。 从github上面拉取项目 修改 broker.conf 中的 brokerIP1 参数，修改为本机IP 进入 docker-compose.yml 文件所在路径，执行 docker-compose up 命令即可 前言 首先我们是使用 Docker 进行搭建环境的，所以我们先要在自己机器上的安装Docker，具体的安装过程以及对于Docker的介绍官方文档里面说的很清楚了 https://docs.docker.com/get-started/ 。 我们要搭建RocketMQ服务器，那么我们就要知道大概搭建RocketMQ服务器需要部署哪些东西。对于RocketMQ有一个架构图，如下所示。而图中所示的Producer（生产者）和Consumer（消费者）无需我们搭建，因为那是作为一个服务器进行启动的。nameserver就是一个注册中心一样组件，我们可以将其简单理解成springcloud中的Eureka，那么nameserver是需要我们搭建的。broker就是真正处理消息的地方，也是需要我们搭建的。

【推荐阅读】微服务还能火多久？>>> 保险上云解决方案总体架构 原文链接： https://www.aliyun.com/solution/finance/insurancecloud 1. 保险行业云服务解决方案总体架构 2. 上云方案优势 （1）扩展性 （2）容灾 3. 应用案例 （1）众安保险 众安保险仅用5个月的时间就实现了两地三中心的容灾部署，并实现对海量互联网业务的支持。首家将核心系统建立在云计算平台上的金融机构 （2）长安保险 长安保险仅用5个月时间就把除核心数据库外的所有系统搬站上云，基本消除了自建机房，同时也用云计算实现了同城双活和异地灾备。是采用混合云架构数据中心的首个案例 （3）中国太平 全系统上云，建设成本从数千万降低到数百万，且完全符合监管要求；搭建互联网金融的技术平台和利用大数据助力互联网保险和科技保险的发展；从业务、技术和大数据等多个方面实施互联网金融创新战略 （4）中国人民健康保险 人保健康用3个月时间，把原单体系统改造成为新一代电商核心系统，实现了高性能、高可用、高安全的设计目标，支撑业务上快速创收。实现从5秒处理1单，到每秒处理1000单，人保健康正式进入互联网保险业务新时代 4. 相关云产品 （1）云服务器ECS（Elastic Cloud Service，弹性云服务） 弹性可伸缩的计算服务，多规格示例满足保险公司的不同应用要求，助您降低 IT

【推荐阅读】微服务还能火多久？>>> 说在前面 RocketMQ在底层存储上借鉴了Kafka，但是也有它独到的设计，本文主要关注深刻影响着RocketMQ性能的底层文件存储结构，中间会穿插一点点Kafka的东西以作为对比。 例子 Commit Log，一个文件集合，每个文件1G大小，存储满后存下一个，为了讨论方便可以把它当成一个文件，所有消息内容全部持久化到这个文件中；Consume Queue：一个Topic可以有多个，每一个文件代表一个逻辑队列，这里存放消息在Commit Log的偏移值以及大小和Tag属性。 为了简述方便，来个例子 假如集群有一个Broker，Topic为binlog的队列（Consume Queue）数量为4，如下图所示，按顺序发送这5条内容各不相同消息。 发送消息 先简单关注下Commit Log和Consume Queue。 RMQ文件全貌 RMQ的消息整体是有序的，所以这5条消息按顺序将内容持久化在Commit Log中。Consume Queue则用于将消息均衡地排列在不同的逻辑队列，集群模式下多个消费者就可以并行消费Consume Queue的消息。 Page Cache 了解了每个文件都在什么位置存放什么内容，那接下来就正式开始讨论这种存储方案为什么在性能带来的提升。 通常文件读写比较慢，如果对文件进行顺序读写，速度几乎是接近于内存的随机读写

随着新需求的增加，需要开发新的模块, 开闭原则（对扩展开发，对修改关闭） 低耦合性 软件架构师最大的价值不在掌握多少先进的技术，而在于具有将一个大系统切分成 N 个低耦合的子模块的能力。这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自于专业的技术和经验，还有一部分源于架构师对业务场景的理解，对人性的把握，甚至对世界的认知。 利用分布式消息队列降低耦合性 事件驱动架构 消息队列的方式，无论是增加生产者，还是消费者，对于其他功能都是无感知的。 分布式消息队列 实际上 KAFKA 就是这种, 只不过架构图比这个复杂， 还有 ActiveMQ, RocketMQ 等. 伸缩性： 比较简单，只要新增加一个消息队列服务器，并通知生产者，多了一个消息队列服务器即可. 可用性:如果消费者进程处理缓慢，导致内存队列已满，会将消息写入磁盘，消息推送模块在将内存队列消息处理完以后，将磁盘内容加载到队列继续处理 分布式服务打造可复用业务平台 拆分, 将复用的业务拆分出来, 独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码。 web service 与 企业级分布式服务 分布式服务设计, 比如 阿里巴巴开源框架 Dubbo 平台级别 API 接口: RESTful, WebService, RPC 等 安全: 身份识别，权限控制， 带宽限制。 审计:

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。