Apache RocketMQ

背景 笔者所在的业务线，最初化分为三个服务，由于业务初期业务复杂度相对简单，三个业务服务都能很好的独立完成业务功能。 随着产品迭代，业务功能越来越多后慢慢也要面对高并发、业务解耦、分布式事务等问题，所以经过团队内部讨论，引入 RocketMQ 消息中间件来更好的处理业务。 由于公司内部业务线部署相互独立，我们业务线对引入 RocketMQ 的需求也比较急切，所以打算自己搭建一套高可用的 RocketMQ 集群，同时对于自建的 RocketMQ 集群需要如下特性： 高可用 高并发 可伸缩 海量消息 命名服务（NameServer） 首先第一步要让 NameServer 高可用，前期规划了三台机器部署 NamseServer 这样可以充分保证可用性，即使两台机器挂掉也能保证集群的正常使用，只要有一个 NamseServer 还在运行，就能保证 RocketMQ 系统的稳定性。 NameServer 的设计是相互的独立的，任何一台 NameServer 都可以的独立运行， 跟其他机器没有任何通信 。 每台 NameServer 都会有完整的集群路由信息，包括所有的 Broker 节点的信息，我们的数据信息等等。所以只要任何一台 NamseServer 存活下来，就可以保存 RocketMQ 信息的正常运行，不会出现故障。 Broker 集群部署架构 开始部署 RocketMQ 之前

主从模式环境可以保障消息的即时性与可靠性 投递一条消息后，关闭主节点 从节点继续可以提供消费者数据进行消费，但是不能接收消息 主节点重新上线后会自动进行消费进度offset的同步 准备两台机器，一主一从： 机器IP hostname 角色 192.168.243.169 rocketmq01 master 192.168.243.170 rocketmq02 slave 我这里事先在两台机器上安装好了RocketMQ，关于RocketMQ的安装可以参考如下文章： RocketMQ源码编译安装 接下来，我们开始搭建RocketMQ主从集群。首先，配置两台机器的 hosts ： $ vim /etc/hosts 192.168.243.169 rocketmq-nameserver1 rocketmq-master1 192.168.243.170 rocketmq-nameserver2 rocketmq-slave1 修改master节点的配置文件： [root@rocketmq01 /usr/local/rocketmq-4.7.1]# echo "" > conf/2m-2s-async/broker-a.properties [root@rocketmq01 /usr/local/rocketmq-4.7.1]# vim conf/2m-2s-async/broker-a

你听说过任督二脉吗？像这样~ 咳咳~今天不讲武功，讲电商平台设计的功夫~ 背景 当今的电商可不仅仅是B2C商城，接下来还会有O2O，往后可能还会有商超、奥莱、二手交易。。。且称之为业务模式~而每个业务模式下还会有预售、竞拍、拼团等不同组合的子模式。 可是我商城的商品列表页不想展示O2O的商品啊，商品列表的数据希望按一定规则相互隔离。其他模块，有的出于操作习惯的考虑不隔离，有的出于用户行为的考虑需要隔离。 各模块数据隔离需求如下 列表页 商详页 商品组 优惠券 活动 订单 ... 原商城 隔离 隔离 隔离 暂时不隔离 暂时不隔离 隔离 O2O 隔离 隔离 隔离 暂时不隔离 暂时不隔离 隔离 各模块流程差异 新建商品 列表页 购物车 订单 ... 原商城 店铺创建，门店设置库存 基于item建es文档 跨门店 状态流转走快递 O2O 门店创建（沿用原模型但弱化店铺的概念） 基于item建es文档 单个门店 状态流转走配送 于是我们就会面临不同的改造的场景。 场景1，新建商品就是新建商品啊！！！ 例如商品的新建保存，是基础服务，已经具备通用存储模型。为了支持新模式我还得改服务接口、发布二方包？咱可不可以这样？ 商品服务 Integer bizMode = BizModeContext.getBizMode(); itemDO.setBizMode(bizMode); // ...

众所周知，程序员这个圈子工资差异还是蛮大的，很多猿猿在一线城市少的拿8k+，多的10k+也有，都是凭自己的能力赚钱。 今年受疫情影响， 不少企业开始缩减招聘名额，更别说涨薪了！据统计，今年 7 月程序员平均工资为 14357 元。作为第一编程语言的 Java，平均工资 14448 元（ 6 月为 14433 元 ），被前端 TypeScript 赶超。 程序员薪资相较于 6 月继续下跌，不少猿猿感叹互联网环境大不如从前， 已哭晕在电脑前。 而且近些年学习 Java 的人也越来越多，竞争激烈。 想拿到一份理想薪酬的工作越来越“南”！ 一个好哥们因为前一份工作薪水不理想，最近去面试，被问到消息队列的问题。具体的问题是这样的： “你们公司为什么会选择用RocketMQ，而不是ActiveMQ、RabbitMQ？” 他当时一脸懵，脱口而出：是领导决定的！ 一个用消息队列好几年的人，却不知道它的工作原理，也没有评估引入这些不同的组件会给项目带来何种风险的意识，面试结果我就不多说了。 也就是这样，他开始意识到了自己的问题。 公司在引入基础组件时，需要根据公司业务场景选择合适的基础组件。一般我们需要调研组件技术性能，开源社区活跃程度等 。 大型的软件公司，OLTP场景下都会倾向于使用RocketMQ。 现在很多技术同学只停留在如何使用上，对于基础组件的实现细节，设计思考知之甚少，更别说二次开发

微服务越来越火。很多互联网公司，甚至一些传统行业的系统都采用了微服务架构。体会到微服务带来好处的同时，很多公司也明显感受到微服务化带来的一系列让人头疼的问题。本文是笔者对自己多年微服务化经历的总结。 如果你正准备做微服务转型，或者在微服务化过程中遇到了困难，此文很可能会帮到你！ 写在前面 正文开始前，为了让各位读友更好的理解本文内容，先花两分钟了解一下微服务的优缺点。 微服务的好处 聊起微服务，很多朋友都了解微服务带来的好处，罗列几点： 模块化，降低耦合 将单体应用按业务模块拆分成多个服务，如果某个功能需要改动，大多数情况，我们只需要弄清楚并改动对应的服务即可。只改动一小部分就能满足要求，降低了其他业务模块受影响的可能性。从而降低了业务模块间的耦合性。 屏蔽与自身业务无关技术细节 例如，很多业务需要查询用户信息，在单体应用的情况下，所有业务场景都通过 DAO 去查询用户信息，随着业务发展，并发量增加，用户信息需要加缓存，这样所有业务场景都需要关注缓存，微服务化之后，缓存由各自服务维护，其他服务调用相关服务即可，不需要关注类似的缓存问题。 数据隔离，避免不同业务模块间的数据耦合 不同的服务对应不同数据库表，服务之间通过服务调用的方式来获取数据。 业务边界清晰，代码边界清晰 单体架构中不同的业务，代码耦合严重，随着业务量增长，业务复杂后，一个小功能点的修改就可能影响到其他业务点

后面会连载 好友丁威 的Canal系列文章，今天为第一篇。 1、应用场景 提到 Canal，大家应该都能想到这是一个用于解析 MySQL binlog 日志的工具，并将 MySQL 数据库中数据同步到其他存储介质中，例如 Elasticsearch。 即 Canal 一个非常常用的使用场景：数据异构，一种更高级别的数据读写分离架构设计方法。 随着业务不断的发展，企业发展到一定阶段，发现单体的关系型数据库已无法支撑业务高速发展带来数据不断累积的压力，从而会诞生出一种设计架构：分库分表。分库分表对缓解单库数据库压力确实是一种非常好的解决方案，但又衍生出另外一种困境，关联查询不友好，甚至跨库JOIN就更加如此。 举例说明如下：例如一个订单系统，通常有两类用户需要去查询订单，一类是顾客，一类是商家，在对数据库进行分库分表时，如果以顾客(buy_id)进行分库的话，同一个商家的订单数据会分布在不同的库中，如果以商家(shop_id)进行分库的话，同一个用户购买的所有订单数据将会分布在不同的库中，这样进行关联查询，就必然需要跨库进行join，其成本都会偏高。而且上面的场景只能满足一方的需求，那如何是好呢？ Canal 这个时候就闪亮登场了，在电商设计中，其实商家、顾客会被拆分成两个不同的服务，我们可以为两个不同的服务搭建不同的数据库集群，我们可以用户订单库、商家订单库进行分库

1、结构不一样 　　kafka broker：topic+partition rocketmq broker：topic+queue 　　kafka 注册中心：zookeeper rocketmq 注册中心：nameserver 2、消费 　　kafka中同一个consumergroup下消费实例无法广播消费，rocketmq可以实现广播消费 　　kafka如果实现广播，只要每个consumer有一个独立的group即可 3、吞吐量 　　kafka>rocketmq 　　kafka在消息存储时根据topic+partition数量创建物理文件，也就是说我们创建一个topic并指定了3个partition，那么就会有3个物理文件目录，也就说说partition的数量和对应的物理文件是一一对应的。 　　rocketmq消息实际上是存储在commitlog中的，consumequeue存储消息索引。 　　kafka多文件并发写入，而rocketmq是单文件写入，显然kafka吞吐量更大 4、nameserver VS zookeeper 　　kafka具备选举功能，当master挂掉会选举slave为master 　　rocketmq如果master挂掉，slave不会变为master；原本发送到该broker改为发送到另外broker上 来源： oschina 链接： https:/

mxs-exchange 介绍 mxs-exchange 是10万级内存交易撮合系统。基于 OpenHFT Chronicle-Bytes ， OpenHFT Chronicle-Wire ， lz4 lz4-java ,RocketMq。 mxs-exchange还是一个以撮合引擎为核心的项目，别的项目都只是辅助。和 match-trade 不一样，这是一个生产级项目，目前已有多家交易所使用。PS：这个是一个付费使用版本，如有需要加VX：BP-666666 细节 我们做了那些： WEB容器选择，对比容器容器的性能； WEB容器连接数，线程数最优配置； 数据库连接池选择与对比； 数据库连接池最优配置（MYSQL,TIDB,POSTGRESQL）； JDK的G1、CMS与ZGC的对比、参数调优； Linux内核参数调优； 测试ROCKETMQ单/多线程发单/多QUEUE时性能瓶颈和差距； 软件架构 不同币队分发撮合引擎 订单匹配引擎 快速快照模块 交易，管理和报告API 安装教程 本地安装rocketmq 并自动创建topic,或者创建topic:mxs-local-request-command 运行exchange-match 运行exchange-order 使用说明 通过exchange-match下单及其操作去： http://127.0.0.1:8410/order

点击上方 蓝色字体 ，关注我们 作者：孤独烟 出处： http://rjzheng.cnblogs.com/ 声明:本文版权归作者和博客园共有) 引言 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 1.小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。 2.小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。 庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点 复习要点 本文大概围绕如下几点进行阐述: 1.为什么使用消息队列？ 2.使用消息队列有什么缺点? 3.消息队列如何选型? 4.如何保证消息队列是高可用的？ 5.如何保证消息不被重复消费? 6.如何保证消费的可靠性传输? 7.如何保证消息的顺序性？ 我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大 正文 1

底层通过Netty实现； Broker写文件的方式存储消息，消息内容先写到内存中，然后异步刷到磁盘，算盘方式有三种； 异步 +内存缓冲池 ：先写入内存字节缓冲区(writeBuffer) ----> 从内存字节缓冲区(write buffer)提交(commit)到文件通道(fileChannel) ----> 文件通道(fileChannel)定时flush到磁盘 异步 ：默认，写入映射文件字节缓冲区(mappedByteBuffer) ----> 映射文件字节缓冲区(mappedByteBuffer)定时flush； 同步 ：发送消息时，消息内容刷到磁盘才会返回； 主从同步HA 同步双写 SYNC_MASTER 异步复制 ASYNC_MASTER 重试机制（每次重试都会重新进行负载均衡）： Producer： 如果是 异步 发送 那么 重试次数只有1次 对于 同步 而言，非超时异常（ 内部异常 ）重试两次， 超时异常不会重试 。 如果设置了重试次数， 不管是否是同步 ，是在一个for 循环里去重试，所以它是立即重试而不是隔一段时间去重试。 Consumer： 重试的情况： 用户返回status为RECONSUME_LATER 用户返回null 用户业务逻辑处理抛出异常 在消息消费失败时，会把该消息回发给B r o ker ，如果回发失败，会重试一次； 默认是16次