tag: springboot

在之前的《浅入浅出消息队列》一文中，我们了解了消息队列的作用、优缺点和使用场景，相信你对消息队列已经有了一个大致的概念，文末给自己埋的坑说日后会写一篇实战教程，正好现在实习结束了，也许久没有写实战教程了，于是这就来填坑了。 前置知识 阅读本文前，建议有一些前置知识，包括且不限于： 常见的 Linux 命令 消息队列的相关知识 Docker 的基本使用 docker-compose 的基础知识 SpringBoot 的基本使用 那废话不多说，我们就开始吧。 本文的所涉及到的代码可在微信公众号「01 二进制」后台回复「rocketmq」获得。 为什么要以 RocketMQ 为例？ 本文主要是为了通过实例的方式直观的了解消息队列。那么问题来了，消息队列那么多（ActiveMQ、RabbitMQ、Kafka），我为什么要选择 RocketMQ 呢？这里我们不谈原理，只说说体验，仅是个人选择，不喜勿喷。 背靠阿里，不看测评，纯粹看他经历过多次双十一的检验就已经知道其性能是处于第一批次的。 作为一个 Java 程序员，如果选择一个纯 Java 编写的软件，后期阅读其源码难度也会小很多。（RabbitMQ 底层是 Erlang，kafka 底层是 Scala） 在阿里实习的时候一直都是使用 RocketMQ 的内部版本，于我而言，RocketMQ 更熟悉。 初识 RocketMQ 在使用消息队列前，我们要知道消息队列是什么，这一块内容参考之前的文章《浅入浅出消息队列》，这里不再赘述。 本段节来讲解 RocketMQ 所涉及到的相关概念，我们先来简单看下官方给出的 RocketMQ 架构图 从上图我们可以很直观的看出，一个完整的 RocketMQ 架构包含四个部分：NameServer、Broker、Producer 和 Consumer。 NameServer：主要用作注册中心，用于管理 Topic 信息和路由信息的管理 Broker：负责存储、消息 tag 过滤和转发。需将自身信息上报给注册中心 NameServer Producer：生产者 Consumer：消费者 从寄信的角度理解 上面的解释可能难以理解，我们从寄信这一实例来看以下四个部分所承担的责任。 Producer 和 Consumer 不必多说，消息的生产者和消费者，生产者负责投递消息，消费者负责接收消息，是我们要编写的应用程序。可以理解为寄信人和收信人。 Broker 负责消息存储，以 Topic（主题）为维度，以队列的形式存储消息。可以理解为信箱，专门存储信件，收信人（Consumer）可以从这里获取信件。 NameServer 负责对源数据进行管理，包括了对 Topic 和 Broker 的管理。可以理解为邮局，负责管理邮件的分发，维护信箱（Broker）的状态。 由上各部分角色的功能可知，我们需要先安装启动 NameServer，再启动 Broker 即可搭建完 RocketMQ...