Apache RocketMQ

来自：小姐姐味道 redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。 Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。 使用规范 冷热数据区分 虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。 业务数据分离 不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 消息大小限制 由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。 连接数限制 连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置。 缓存 Key

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

点击蓝色“ 程序员大帝 ”关注我哟 加个“ 星标 ”，及时阅读最新技术文章 每日鸡汤，好喝 前言 本文属于《从零开始消息中间件》的系列文章，之前的几篇文章向大家介绍了消息中间件 MQ 并进行了初步入门 ，大家可以看： 《 十分钟入门消息中间件 》 《 还在纠结秒杀？看看 MQ 如何搞定 》 《 消息中间件的正确打开方式 》 本篇文章开始，整个系列都会基于目前流行的 RocketMQ 为基础，开始对每个组件和场景进行深入的讲解，首先咱们来学习下 Topic。 正文 01 什么是Topic？ Topic 中文含义大家肯定不陌生，直接翻译过来是话题。而在 MQ 里，无论是 RocketMQ 还是 Kafka，都用 Topic 这个名词来代表一种 数据的集合 。 比如说，现在需要往 MQ 中发送订单的消息，那么我们就可以将这一种类的消息归为一个 Topic，给它取名为 order_info_topic，也就是一个包含了订单信息的数据集合。 接下来物流系统可以去这个 order_info_topic 中获取订单信息进行发货。简单的总结一下，Topic 并不具有真正的属性，它只是一类数据的集合，不同类型的数据我们应该放到不同的 Topic 中。 也就是说当有商品数据时，这时应该新建一个Topic，假设取名为 product_info_topic，代表这里面放的商品信息。获取商品数据时

1. 批量消息 为什么使用批量消息 在很多调优的时候，比如数据库批量处理，有些请求进行合并发送等都是类似批量的实现。 RocketMQ 批量发送也是为了追求性能，特别在消息数据量特别大的时候，批量效果就非常明显。 使用批量消息的限制 同一批次的消息应该具有相同主题、相同的消息配置。 不支持延迟消息。 建议一个批量消息大小最好不要超过 1MB。 使用批量消息 http://rocketmq.apache.org/docs/batch-example/ 2. 事务消息 什么是事务消息 RocketMQ 的事务消息，是指 Producer 端消息发送事件和本地事务事件，同时成功或同时失败。 RocketMQ 事务消息设计 当第四步未能及时提交时，MQ Server 会进行主动查询(第五步)。 事务消息的约束 事务消息不支持定时和批量。 为了避免一个消息被多次检查，导致半数队列消息堆积。RocketMQ 限制了单个消息的默认检查次数为 15 次。通过修改 broker 配置文件中的 transactionCheckMax 参数进行调整。 特定的时间段之后才检查事务。通过 broker 配置文件参数 transactionTimeout 或用户配置 CHECK_IMMUNITY_TIME_IN_SECONDS 调整时间。 一个事务消息可能被多次检查或消费多次。

1. 有序消息的基本概念 为什么要用有序消息 有序消息是什么 有序消息又叫顺序消息(FIFO消息)。 是指消息的消费顺序和产生顺序相同，在有些业务逻辑下，必须保证顺序。 比如订单的生成、付款、发货，这个消息必须按顺序处理才行。 顺序消息氛围全局顺序和分区(queue)顺序。 全局消息 一个 Topic 内所有的消息都发布到同一个 queue，按照先进先出的顺序进行发布和消费。 适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景。 分区顺序 对于指定的一个 Topic，所有消息根据 sharding key 进行区块(queue)。 同一个 queue 内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 key 是完全不同的概念。 适用场景：性能要求高，根据消息中的 sharding key 去决定消息发送到哪一个 queue。 全局顺序和分区顺序对比 消息类型对比 消息类型 支持事务消息 支持定时消息 性能 无序消息(普通、事务、定时/延迟消息) 是 是 最高 分区顺序消息 否 否 高 全局顺序消息 否 否 一般 发送方式对比 消息类型 支持可靠同步发送 支持可靠异步发送 支持 Oneway 发送 无序消息(普通、事务、定时/延迟消息) 是 是 是 分区顺序消息 是 否

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近，又重新学习了下Redis，深深被Redis的魅力所折服，我才知道Redis不仅能快还能慢（我想也这么优秀o(╥﹏╥)o），简直是个利器呀。 好了，接下来回到我们的话题，我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。（这就是为什么Redis既能快又能慢啦！） 那接下来开始讲讲我们的楷模Redis在队列中如何实现延时的情况： 在我们日常生活中，我们可以发现， 在淘宝、京东等购物平台上下单，超过一定时间未付款，订单会自动取消。 打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。 点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。 收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。 在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。 .......还有很多这样的场景。 这时，我们可以想想为什么要这样做？ 因为这样可以保证商品的库存可以释放给其他人购买，你可以不用一直等待打车却得不到回复，你可以及时换一家店点到外卖。

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 物流系统的难题 菜鸟的物流系统脱胎于天猫、共享交易，系统之间存在着 " 打断腿连着皮 " 的紧密的联系，多年来双方配合默契，承担着整个泛电商业务最核心的链路。 随着集团业务的蓬勃发展，线上购物更加深入人心，在每年双十一订单峰值纪录不断被打破的背后，技术投入和成本也在不断增加，特别是近几年，支付的能力提升已经渐渐可以和下单持平，这对物流系统的压力也越来越大。交易和物流两者间密不可分的技术脐带逐步变成了缠绕在菜鸟脚上的链条。 双十一的巨大成本压力 仅分析 2015 年双十一峰值背后的业务数据，其中 0 点起创建的订单，在前一个小时完成发货的订单仅有几十万, 相比支付订单量可以说九牛一毛，可以看出，支撑大流量高并发的订单创建，并非物流领域自身业务的刚需驱动，而更多的是为了保障交易 - 支付 - 物流链路的稳定。 再从业务场景上来看，物流在双十一是以单据驱动的核心业务，即发货。发货对应的是实物的实操业务，需要大量的人力物力投入，这种物理空间上的线下协同能力，具有流量相对平稳，无明显峰值的特点，整个业务流程复杂、业务执行周期长、参与角色较多。从用户的核心诉求来说，用户只关心交易订单是否成功创建，而物流订单是否能马上创建出来，并不是刚需。 因此，如果交易订单的创建峰值每年持续上涨

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

1、RocketMQ概念模型 Producer: 消息生产者, 复制生产消息, 一般由业务系统负责产生消息 Consumer: 消息消费者, 负责消费消息, 一般是由后台系统负责异步消费 Push Consumer: Consumer的一种, 需要向Consumer对象注册监听 Pull Consumer: Consumer的一种, 需要主动请求Broker拉取消息 Producer Group: 生产者集合, 一般用于发送一类消息 Consumer Group: 消费者集合, 一般用于接受一类消息进行消费 Broker: MQ消息服务, 中转角色, 用于消息存储与生产消费转发 2、启动命令 1、启动nameserver: nohup sh mqnamesrv & 2、启动broker: nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-async/broker-a.properties >/dev/null 2>&1 & 来源： oschina 链接： https://my.oschina.net/liwanghong/blog/4289417

在实际开发中，经常需要排查一条消息是否成功发送到底层MQ中，或者查看MQ中消息的内容，以及如何将消息发送给指定的/所有的消费者组重新消费。本文对RocketMQ提供到的查询机制和背后原理进行深入的介绍。文章主要包括4个部分： 消息查询介绍：介绍消息查询中使用到的Message Key 、Unique Key、Message Id 的区别 消息查询工具：分别介绍命令行工具、管理平台、客户端API这三种工具的详细用法，以及如何让消费者重新消费特定的消息。 核心实现原理：介绍Message Key & Unique Key与Message Id的实现机制上区别，Unique Key在Exactly Once语义下的作用，以及为什么Message Id查询效率更高。 索引机制：介绍Message Key & Unique Key底层使用的哈希索引机制 1 消息查询介绍 RocketMQ提供了3种消息查询方式： 按照Message Key 查询：消息的key是业务开发同学在发送消息之前自行指定的，通常会把具有业务含义，区分度高的字段作为消息的key，如用户id，订单id等。 按照Unique Key查询：除了业务开发同学明确的指定消息中的key，RocketMQ生产者客户端在发送发送消息之前，会自动生成一个UNIQ_KEY，设置到消息的属性中，从逻辑上唯一代表一条消息。 按照Message