Apache RocketMQ

最近有朋友说，年底公司业务量增大，又拆分出来了很多微服务模块，对于微服务的管理、资源编排以及调度策略花费的精力成几何倍数的增长。看到微服务+k8s的云原生架构貌似能解决这些问题，所以想问下。我把对他的回答整理了一下，希望能帮助更多在这方面有问题的朋友。 大家都知道微服务和云原生架构是当前互联网行业的热门技术。微服务便利的同时，自然也存在一些问题，而 k8s 的出现则完美地解决了这些问题。 现今越来越多的企业把服务迁移在 k8s 的平台上，以 k8s 为核心的云原生技术逐渐成为企业架构的标准 。毫不夸张地说，掌握了它的技术人， 你将同时收获高薪、话语权、成就感和不可替代性。 当然想要完全搞懂也并不容易: 开发工具繁多，组件源码晦涩，业务里涉及的技术细节也十分繁杂 网上自学资料多而杂 ，官方网站大而泛，抽象且很难理解 缺乏实战，落地时还是难以系统的解决实际应用发布和部署的问题 因此，向大家推荐一个训练营——《 k8s 与微服务的完美结合 》。老师带你从基础原理、核心框架剖析到服务部署演练，全程实战案例贯穿，学完即可落地到实际业务场景中。 学完后你将： 掌握云原生架构理论，实践角度，全方位、深层次地认知 k8s 的技术细节 深度掌握 k8s 难以理解的知识点， k8s 落地 不再困难 通过对微服务架构的 云端迁移部署 ，全面掌握 服务上云 的技术细节 使用 Jenkins 构建流水线

背景： 对于存在有问题的项目（包括 代码不规范 数据库表命名不规范 ）需要改造 系统业务架构： 步骤： 1 新建工程 ： 将需要改造的项目拷贝一份 修改项目名称 2 将相应的表结构拷贝到新的数据库中 修改不直观的表名 字段的备注等 3 修改对应的代码 和数据库表字段对应 熟悉接口对应的相关类 找到与之相关的 注意： 1 并发幂等性（重试引起）控制 2 方法设置开关 3 金额存整数（元化为分） 4 解耦 （rocketMQ消息异步解耦） 加入状态机【待完成】 5 分库【垂直拆分 基本的思路就是按照业务模块来划分出不同的数据库】 分表【垂直拆分某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中】 好处： 便于 管理、维护、监控、扩展 ， 在高并发场景下，垂直分库一定程度上能够突破IO 、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段。 注意：需要改写以前的查询语句【跨库join，分布式事务等】 跨库Join的几种解决思路 1 全局表【很少发生编号 像数据字典】 系统中所有模块都可能会依赖到的一些表，将这类表在其他每个数据库中均保存一份 2 字段冗余 【最复杂的还是数据一致性问题，这点很难保证】 3 数据同步 定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步，通过ETL工具来实施 4

“我能熟练使用这个框架/软件/技术就行了， 为什么要看源码？” “平时不用看源码， 看源码太费时间，还容易忘记，工作中出现问题再针对性地阅读，效率更高。” “为了面试才需要看源码！” 。。。。。。 如果你也有类似的疑问，不妨接着往下看 1、为什么要阅读源码？ 1.1 在通用型基础技术中提高技术能力 在 JAVA 领域中包含 JAVA 集合、Java并发(JUC)等， 它们是项目中使用的高频技术，在各种复杂的场景中选用合适的数据结构、线程并发模型，合理控制锁粒度等都能显著提高应用程序的可用性、健壮性，非常容易凸显出自己的技术实力，更容易受到领导的认可，助力职场。 当然通过阅读源码并不是知晓原理的唯一方法，但作为一个名程序员、直面代码，亲自感受代码的魅力或许会显得的更加直接。 1.2 在重点领域打造自己的亮点 我所在公司使用了 Dubbo、RocketMQ，我也有幸参与到这些技术栈的运用与运维，积累了丰富的使用经验，为了突出在这两个领域的优势，我详细阅读了它们的源码，在CSDN和公众号等知识分享平台发布了大量的技术文章，成体系的剖析其实现原理、架构设计理念，理论与实战相结合，让我成为在Dubbo、RocketMQ领域当仁不让的技术专家，团队中的核心骨干。 同时由于文章是成体系的，被出版社相中，邀请出书，《RocketMQ技术内幕》一书应运而生，从而成为我职业技能列表中非常亮眼的名片

2020年度程序员洞察报告就出炉了 ： 程序员平均年薪为20.36万元 。学历水平与工资水平成正比，同时值得注意的是，即使是 大专学历群体的平均工资，也达到了16.13万之多 。 （来自猎聘） 企业热招程序员职能TOP15中， 需求占比最大的职能是Java ，占比为17.82%。 （来自猎聘） 而其中有个职位更是稳得一批—— 架构师的薪资最高达60000元 ， 依旧稳居Java 所有职能的第二 。根据全国各大高校数据显示，2021年将新增超20万程序员，而阿里腾讯京东美团字节等大厂都在大肆招人，互联网不缺程序员，缺的是高级的精尖程序员。 如果你是一名架构师 如何检验自己是否是个够格的架构师？一年一度的双十一，就是现成的考题。 高并发场景秒杀下单超卖Bug、利用Redis集群架构抗住双十一大流量洪峰 等等，都是必备技能。 每个开发人员成为高级开发、架构师的必经之路是什么呢？打开招聘网站看看大牛的必备技能， 从Redis、Zookeeper，JVM、Spring、RocketMQ，再到高并发场景下框架的运用、秒杀系统的优化实战，都是高薪技能点 ，因为企业需要你有，你有了就是大大的加分项。何况这些都是来年金三银四必问的面试考点。 涉及过，但并不深入？ 很多程序员觉得能够吃透两套架构就能躺赢了，但是实际项目中，会遇到很多问题，需要更多的技能点来支撑，却因为对这些技术点不够了解

目录 1、为什么Broker数据存储是最重要的一个环节？ 2、CommitLog消息顺序写入机制 3、MessageQueue在数据存储中是体现在哪里呢？ 4、如何让消息写入CommitLog文件近乎内存写性能的？ 5、同步刷盘与异步刷盘 6、对今天内容的一点小小总结 1、为什么Broker数据存储是最重要的一个环节？ 上次给大家分享完Producer的工作原理之后，团队整体都对RocketMQ的数据分片机制以及发送消息的时候如何写入各个Broker 机器有了一定的了解。接着小猛就开始来给大家分享最为重要的Broker数据存储的环节。 首先我们得明确一点，为什么Broker数据存储是最重要的一个环节？ 很简单，实际上类似RocketMQ、Kafka、RabbitMQ的消息中间件系统，他们不只是让你写入消息和获取消息那么简单，他们本身最 重要的就是提供强大的数据存储能力，可以把亿万级的海量消息存储在自己的服务器的磁盘上。 这样的话，各种不同的系统从MQ中消费消息的时候，才可以从MQ服务器的磁盘中读取到自己需要的消息。 否则如果MQ不在机器磁盘上存储大量的消息，如果消息都放在自己的内存里，一个是内存很可能放不下，另外一个是可能你机器重 启，内存里的消息就会全部丢失了。 所以大家首先要明确一点，Broker数据存储实际上才是一个MQ最核心的环节，他决定了生产者消息写入的吞吐量

部署准备 | IP | 配置 | 用途 | | 192.168.94.101 | 3G | namesrv服务，Borker-a，Borker-b-slave | | 192.168.94.102 | 2G | console服务，Borker-b，Borker-a-slave | http://mirrors.hust.edu.cn/apache/rocketmq/4.8.0/rocketmq-all-4.8.0-bin-release.zip 下载rockmetMQ https://github.com/apache/rocketmq-externals.git 克隆插件项目，下面需要部署console模块 部署namesrv #解压文件 [root@localhost soft]# unzip rocketmq-all-4.8.0-bin-release.zip [root@localhost soft]# mv rocketmq-all-4.8.0-bin-release /usr/local/rocketmq #101机器,修改namesrv配置，默认启动jvm内存4g,修改为512 [root@localhost rocketmq]# cd bin/ [root@localhost bin]# vi runserver.sh JAVA_OPT="${JAVA_OPT}

这是Bella酱的第 89 期分享 作者 | SnoWalker 来源 | 分布式朝闻道 学习DDD的时候，作为开发，我们更关心它在技术层面的东西，尤其体现在DDD的分包方式、编码技巧等方面。 自然的，我们不禁发问，用了DDD的分包，就是实践落地了DDD了么？ 不卖关子，直接说答案，并不是。 用了DDD的分包，只能说满足了DDD的"形"，并没有抓住DDD的"神"。DDD的神是什么，归根到底还是 面向对象，领域建模 。所谓的各种分包方式本质上还是为了满足DDD面向对象的本质,方便开发者进行代码编写而提供的一种"战术设计" 工具 。 要深入讨论这个问题,我们需要花一点时间来学习讨论一下DDD中常见的几种分包。 DDD分包概述 基于DDD的分包主要有两大流派：分层架构以及六边形架构。 分层架构以四层架构为主，基于四层架构又诞生出衍生的五层架构、六层架构等等（限于篇幅以及讨论重点，本文中我们只讨论四层架构）。 六边形架构出自 Robert C Martin（没错，就是传说中的鲍勃大叔）提出的整洁架构，后来者不断探索，又衍生出了洋葱架构。 这个过程可谓是百家争鸣。实际开发中，最为我们熟知的当属四层架构与六边形架构了，其余的各种架构都是基于这两种架构方式的变体。 四层分层架构 四层架构的分层如下图： 从上往下依次为： |- userinterface 用户界面层/表示层 |-

最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。 昨天凌晨，在生产环境进行实战调优，经过不断参数改动，现将生产者相关参数设置为以下配置： linger.ms=50 batch.size=524288 compression.type=lz4 acks=1（用户要求消息至少要发送到分区 leader） max.request.size=5242880 buffer.memory=268435456 在生产环境的一台服务器上，使用以上参数对集群进行生产发送性能压测： 从上图可以看到，使用平均 4k 大小的消息体对集群进行压测， 单个 Producer 平均吞吐量达到 2000MB/s，50w/s+ ！ 作为对比，我还是使用同一台服务器，将调优参数去掉，再压一遍： 可以看到，最高的吞吐量也不过 500M/s，最低已经来到 2M/s 了。 虽然说实际客户端环境比压测环境复杂很多，但是使用压测工具已经能够证明，该集群的负载目前现在还远远没有达到瓶颈，且生产端还有待优化。 以上参数调优思想是： 1、buffer.memory=268435456 由于发送端发送频率非常快，加上由于 Spark 客户端频繁断开连接导致生产端 Sender 线程发送延迟增高，这就会造成客户端发送速率 >

RocketMq连接工具类,提供消息发送与拉取功能 pom.xml <!-- 集成rocketMq --> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-common</artifactId> <version>4.7.0</version> </dependency> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.7.0</version> </dependency> RocketMqUtils.java import org.apache.commons.lang3.RandomUtils; import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer; import org.apache.rocketmq.client.consumer.listener.*; import org.apache.rocketmq.client.exception.MQBrokerException; import org.apache.rocketmq.client

RocketMQ作为一款高可靠、低延迟、高并发、支持海量Topic的分布式消息中间件，服务于阿里巴巴、VIPKID、 滴滴出行、微众银行、华为等国内各大企业。在阿里巴巴内的业务涵盖了阿里巴巴全部的业务，也是双11的核心链路支撑者之一。笔者所在公司选择它，也是由于RocketMQ具有高可靠、吞吐高的特点。 本篇介绍了RocketMQ的基本使用方法及其各个组件的基本原理，讲解原理时，都是采用先整体架构后详细分解的方式。详细分解时不会深入源码逐段讲，而是从代码结构出发梳理整个运行过程。 这份RocketMQ分布式消息中间件—核心原理与最佳实践的完整版已经为大家整理成了PDF格式，所以下面只能为大家展示部分的内容，完整版免费领取方式： 需要这份资料的，点击这里即可查看获取方式 第1章RoketMQ综述 什么是消息队列 为什么需要消息队列 常见消息队列 RocketMQ的发展史与未来 第2章RocketMQ的生产者原理和最佳实践 生产者原理 生产者启动流程 消息发送流程 发送消息最佳实践 生产者最佳实践总结 第3章RocketMQ的消费流程和最佳实践 消费者概述 消费者启动机制 消费者的Rebalance机制 消费进度保存机制 消费方式 消息过滤 第4章RocketMQ架构和部署最佳实践 RocketMQ架构 常用的部署拓扑和部署实践 第5章Namesrv Namesrv概述