Apache RocketMQ

在 RocketMQ 重复消费问题 | 订单系统核心流程引入幂等性机制 一文中，我们讨论了消息重复消费的问题，比较好的方案是采用在消费侧使用业务判断法来保证接口的幂等性，这样就能避免消息重复消费的问题。 今天要讨论的是消费者代码执行过程中出现异常，我们应该如何处理？ 手动提交 offset 首先来看一段代码， Consumer 类是一个消费者类，它我们为它注册了一个监听器，在处理完消息之后，会将消息的状态返回给 RocketMQ，执行成功返回的是消息状态是 CONSUME_SUCCESS 。 public class Consumer { public static void main(String[] args) throws MQClientException { DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("test_consumer"); // 设置 NameServer 地址 consumer.setNamesrvAddr(""); // 订阅 Topic consumer.subscribe("TopicTest", "*"); // 这次回调接口，接收消息 consumer.registerMessageListener(new MessageListenerConcurrently() {

今天要给大家介绍RocketMQ中的两个功能，一个是“广播”，这个功能是比较基础的，几乎所有的mq产品都是支持这个功能的；另外一个是“延迟消费”，这个应该算是RocketMQ的特色功能之一了吧。接下来，我们就分别看一下这两个功能。 广播 广播是把消息发送给订阅了这个主题的所有消费者。这个定义很清楚，但是这里边的知识点你都掌握了吗？咱们接着说“广播”的机会，把消费者这端的内容好好和大家说说。 首先，消费者端的概念中，最大的应该是消费者组，一个消费者组中可以有多个消费者，这些消费者必须订阅同一个Topic。 那么什么算是一个消费者呢？我们在写消费端程序时，看到了setConsumeThreadMax这个方法，设置消费者的线程数，难道一个线程就是一个消费者？错！这里的一个消费者是一个进程，你可以理解为ip+端口。如果在同一个应用中，你实例化了两个消费者，这两个消费者配置了相同的消费者组名称，那么应用程序启动时会报错的，这里不给大家演示了，感兴趣的小伙伴私下里试一下吧。 同一个消息，可以被不同的消费者组同时消费。假设，我有两个消费者组cg-1和cg-2，这两个消费者组订阅了同一个Topic，那么这个Topic的消息会被cg-1和cg-2同时消费。那这是不是广播呢？错！当然不是广播，广播是同一个消费者组中的多个消费者都消费这个消息。如果配置的不是广播，像前几个章节中的那样

消息队列 所谓的"消息队列"就是：在消息的传输过程中保存消息的容器。上次有朋友面试，面试官就问，redis可以用作消息队列吗？当时一懵。每当想到消息队列：我们都会想到 RabbitMQ ， ActiveMQ ，RocketMQ，等等一些专业的消息中间件。但是如果我们做的事情比较简单业务逻辑不是很复杂，只需要有一个消息队列，使用专业的消息中间件是非常麻烦的，因此我们可以使用Redis做消息队列。 如果对消息的可靠性没有较高的要求的话，那么就可以使用Redis去实现。 Redis做消息队列，可以使用List这个数据类型。List里面有两个命令， lpush/rpush 操作来实现 入队 ，然后使用 lpop/rpop 实现 出列 。 在客户端中，我们会 维护一个死循环来不停的从队列中pop读取数据 ，如果队列中有消息，则直接读取，如果没有，就会陷入死循环，直到下一次有消息进入。这种死循环会造成大量的资源浪费，这个时候我们可以使用， blpop/brpop 去处理，相当于lpop的阻塞，当没有消息到来的时候就会休眠，直到消息来临，才唤醒，pop去读取数据。 在java中可以使用while循环去实现 。 延迟消息队列 延迟消息队列，可以用zset实现，里面有 score 分数浮动数值，数据 可以根据 core 排序，zset可用于高效的检索，我们可以将时间作为score

相较传统中间件，云原生中间件更能为企业解决SLA 保障难、运维难、成本高等一系列问题。然而， 中间件技术栈复杂 ， 对专业程度要求高 ， 如果 缺少生产环境的大规模实践 ， 往往难以落地 。 作为云原生中间件的长期实践者， 轻舟中间件 经过可靠性、可扩展性、性能及稳定性测试，已历经网易严选、网易云音乐、网易传媒等 众多大规模 、 高性能业务的 生产环境实战验证。 电商：高 SLA 保障业务连续性 网易严选采用 轻舟中间件 Kafka、RocketMQ ，实现容器化分布式消息中间件，支持从环境搭建、软件安装、服务管理/配置、应用部署/配置/升级，以及监控、告警、故障恢复等端到端的自动化，为 SLA 提供了更可靠的保障。 另外，网易严选也引入了轻舟中间件 RDS MySQL，为其提供 MySQL 组复制（MGR）集群的多数据中心高可用、自动的故障检测修复以及全方位的告警监控，最大限度保障服务可用性。 音乐：节约资源成本30%以上 网易云音乐引入 轻舟中间件 Redis，以容器技术为核心，避免虚拟化开销，通过精细化编排，实现高效率、高密度混合部署、租户隔离，提高资源利用率，节约资源成本 30% 以上。并且针对极致性能场景，从计算、网络到服务层进行了全方位的优化。 传媒：轻松运维，业务不间断 网易传媒借助 轻舟中间件 Kafka、Elasticsearch

作者 | 禾易 在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。恭喜李响！ 去年，全球顶级开源社区云原生计算基金会 CNCF 正式宣布其技术监督委员会席位改选结果。阿里云资深技术专家李响入选，成为该委员会有史以来首张中国面孔。 李响是 CoreOS 最早期的工程师之一，参与创建了 etcd、operator framework、rkt 等开源项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知，etcd 是国际知名且被最为广泛使用的分布式一致性存储系统，被阿里巴巴、腾讯、华为、腾讯、微软、谷歌、VMWare 等企业在生产环境和客户产品中使用，用来解决分布式系统中重要元信息存储、管理和备份的问题，以及分布式系统组件一致性协调的问题。 在加入阿里云后，李响一直在推动云原生领域自动化运维相关理念、Operator 概念、OAM 标准的建立。Operator 给予开发和运维人员在云原生平台构建无状态和复杂应用运维的理论标准和实践基础，大幅度提高了云原生运维平台的覆盖度，在开源生态中涌现出了超过 500 个 Operator 具体实现，覆盖了几乎所有的主流云原生软件的运维，其中包含 RocketMQ、Kafka、ZooKeeper、Consul、Argo、Kubeflow 等

Redis使用规范 在公司项目中，redis属于高频使用，在使用中，我们遇到了各种各样的redis问题，于是针对自身情况梳理了一个redis使用规范。 一、键名设计 1、key名设计 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符) 建议以业务名为前缀，以冒号分割来构造一定规则的key名(比如业务名:表名:id) 比如:teach:leeson_id:21 控制key的长度 key太长量一大起来就会非常占用内存 2、value设计 拒绝大key操作 禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。 错误示范：直接将laravel的整个模型或者对象当成value存储 设计key时使用合适的数据类型(在资源利用和性能之间作平衡) 错误示范：一个普通字符串弄成hash类型进行存储 一定要控制key的生命周期 错误示范：key设置为永不过期 控制value长度 比如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。 数据按需存储 不需要的数据千万不要存储在redis

RocketMQ的基本概念在上一篇中给大家介绍了，这一节将给大家介绍环境搭建。RocketMQ中最基础的就是NameServer，我们先来看看它是怎么搭建的。 NameServer RocketMQ要求的环境是JDK8以上，我们先检查一下环境， [root@centOS-1 ~]# java -version openjdk version "11.0.3" 2019-04-16 LTS OpenJDK Runtime Environment 18.9 (build 11.0.3+7-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7-LTS, mixed mode, sharing) 我的这个机器并没有刻意的安装JDK，而是系统自带的OpenJDK 11，这应该也是没有问题的。然后我们从RocketMQ官网下载最新的安装包，并且上传到 /opt 目录下， [root@centOS-1 opt]# ll -rw-r--r--. 1 root root 13838456 6月 3 08:49 rocketmq-all-4.7.0-bin-release.zip 然后我们解压这个zip包， [root@centOS-1 opt]# unzip rocketmq-all-4.7.0-bin-release.zip

这份面试清单是我17年转管理岗位之后开始整理的，一方面是用来给公司新员工面试一用，另一方面也是想用它来挖掘我在 Java 技术栈中的技术盲点，然后修复和完善它，以此来提高自己的技术水平。虽然我从2014年就开始参加编程工作了，但依旧觉得还有很多东西要学，当然学习的过程也给我带来了很多成就感，这些成就感也推动我学习更多的技术知识。 不多逼逼，上才艺： 消息中间件面试题（RocketMq+ActiveMQ+RocketMq） 什么是 ActiveMQ? ActiveMQ 服务器宕机怎么办？ ActiveMQ 中的消息重发时间间隔和重发次数吗？ RabbitMQ 上的⼀个 queue 中存放的 message 是否有数量限制？ 如何确保消息正确地发送⾄RabbitMQ？ 如何保证消息队列高可用? RocketMq是什么? RocketMq逻辑结构 Dubbo服务框架面试题及答案 Dubbo 支持哪些协议，每种协议的应用场景，优缺点？ Dubbo 超时时间怎样设置？ Dubbo 集群的负载均衡有哪些策略　 Dubbo 的主要应用场景？ Dubbo 的架构设计？ Dubbo有些哪些注册中心? Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通信么？ Dubbo 在安全机制方面是如何解决？ 等......... Java多线程面试题 什么是线程安全和线程不安全？ 什么是原⼦操作

本文主要介绍RocketMQ的多端口监听机制，通过本文，你可以了解到Broker端源码中remotingServer和fastRemotingServer的区别，以及客户端配置中，vipChannelEnabled的作用。 1 多端口监听 在RocketMQ中，可以通过broker.conf配置文件中指定listenPort配置项来指定Broker监听客户端请求的端口，如果不指定，默认监听 10911 端口。 listenPort=10911 不过，Broker启动时，实际上会监听3个端口：10909、10911、10912，如下所示： $ lsof -iTCP -nP | grep LISTEN java 1892656 tianshouzhi.robin 96u IPv6 14889281 0t0 TCP *:10912 (LISTEN) java 1892656 tianshouzhi.robin 101u IPv6 14889285 0t0 TCP *:10911 (LISTEN) java 1892656 tianshouzhi.robin 102u IPv6 14889288 0t0 TCP *:10909 (LISTEN) 而其他两个端口是根据listenPort的值，动态计算出来的。这三个端口由Broker内部不同的组件使用，作用分别如下：

为了方便大家理解我把之前方案的图片复制过来了，如下： 上图的方案存在一个问题，就是我们今天文章要聊的内容。 这个问题就是当 MQ Consumer 收到消息后，就直接发布 Event 了，如果是同步的，没有问题。如果某个 EventListener 中处理失败了，那么这条消息将不会 ACK。 如果是异步发布 Event 的场景，发布完消息马上就 ACK 了。就算某个 EventListener 中处理失败了，MQ 也感知不到，不会进行消息的重新投递，这就是存在的问题。 解决方案 方案一 既然消息已经 ACK 了，那就不利用 MQ 的重试功能了，使用方自己重试是不是也可以呢？ 可肯定是可以的，内部处理是否成功肯定是可以知道的，如果处理失败了可以默认重试，或者有一定策略的重试。实在不行还可以落库，保存记录。 这样的问题在于太烦了呀，每个使用的地方都要去做这件事情，而且对于未来接手你代码的程序小哥哥来说，这很有可能让小哥哥头发慢慢脱落啊。。。。 脱落不要紧，关键他还不知道要做这个处理，说不定哪天就背锅了，惨兮兮。。。。 方案二 要保证消息和业务处理的一致性，就不能立马进行 ACK 操作。而是要等业务处理完成后再决定是否要 ACK。 如果有处理失败的就不应该 ACK，这样就能复用 MQ 的重试机制了。 分析下来，这就是一个典型的异步转同步的场景。像 Dubbo 中也有这个场景