这是一个创建于 387 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为最近在做一个电商项目，需要用到消息队列对订单进行处理，所以就选用了 RocketMQ （主要还是 java 跨平台，但是后面就全是坑了），RabbitMQ 的 Erlang 有点整不来。
版本选用：截至目前最新的版本-5.1.4 。
因为之前没用过 MQ 这个东西，所以我要从头搭建，从下载编译好的源码到正确的能够在 dashboard 上看到消费者，花了整整两天，期间也看了很多博客和教程，但大部分都不是很好，而且相当难受，各有各的说法，光依赖版本就有三种rocketmq-client，rocketmq-client-java，rocketmq-spring-boot-starter，依次增强(?)，目前使用官方推荐的 SDK rocketmq-client-java。
因为没学过，就开始跟着官方文档的 Quick Start （文档写的是真折磨人），从下载、运行 producer 都很顺利，但是到了他最新的 Broker+Proxy 的 Local 模式启动，就开始折磨人了。
坑 1：需要配置ROCKETMQ_HOME环境变量，不然无法启动
坑 2：启动失败，看日志说 Java 的 JVM 内存不够，直接改runserver.sh,runbroker.sh这两个文件的 JVM 启动内存，另外，runbroker.sh有个日志文件的大小，默认是 15g （这个是真的无语）,直接改成 500m ，不然也有可能启动失败；还有，文档里面写推荐使用最新版本的 JDK ，可是又不支持 JDK21(5.1.4 版本 10 月份发布的)，真的无语了。
坑 3：因为 Local 模式启动占用的是 8080 端口和 8081 端口，但是之前的 dashboard 也是占用的 8080 这个端口，所以得重新编译 dashboard 重新部署，官方文档也没说怎么改 proxy 启动端口（可能是我没找到？），后面知道在rmq-proxy.json里面添加配置"grpcServerPort":端口号，不得不说，这个配置是真的难找，耗时半天。
坑 4：java 版本的位数和系统版本的位数不一样，因为之前搞这台服务器的人安装了 32 位的 java ，并不是 64 位的，导致 Local 模式一直启动失败，一开始真的是百思不得其解，我的操作是跟这个官方的 Quick Start 是一步一步对应上的，真的不知道哪出了问题，日志里面也是含糊其辞，最后没办法了把系统所有 java 相关的东西重新整了一遍，才发现之前的 java 和系统位数没对上，真的是超级大坑，耗时 1 天
坑 5：grpc 的坑，因为服务器不能直接用外网进行访问，需要通过另一个域名服务器使用 Nginx 进行转发才能访问，RocketMQ 的 proxy 需要使用 gRPC 访问，之前没整过 gRPC ，所以又是一通找，最后找到了 gRPC 需要支持 http2 的协议才行，接着就改 Nginx 的 http2 ，之前的 Nginx 没有 Http2 这个模块，所以还得重新下载，安装模块，这个时候又又发现进来的是 http2 ，但是转发出去的不是 gRPC ，又改 nginx 为grpc_pass grpc://192.168.0.129:8081，耗时半天。
坑 5：到了使用 SDK 测试消息收发 这块，从 Producer 就开始不对劲了，提交 Issue 也没个人回（可能这个时间节点不对，大佬都在云栖大会？），报错Caused by: java.util.concurrent.CancellationException: Task was cancelled.,这个真的不知道是啥，gRPC 都是正确的，日志里面也没东西输出，现在卡在这了，等有进展再往下写
第 1 条附言 · 2023-11-06 11:27:43 +08:00
RocektMQ 钉钉群和 Github 好像是墓园一样，发了消息两三天了没人回，一点都不像一个活跃的中间件社区，真的很难受哇~好羡慕国外的互联网社区啊，虽然不一定对，但至少能知道有人在帮你解决问题，国内就好像你在墓碑前祈祷，你发出了请求，但是没人回复你/(ㄒoㄒ)/~~
第 2 条附言 · 2023-11-07 15:57:52 +08:00
家人们，选了 RabbitMQ 了，真好用啊！ RocketMQ 还是先等他发展发展吧
 |
1
ufan0 2023-11-03 10:45:09 +08:00
中间件这块儿强烈建议购买厂商服务，开源部分用起来是没问题，但是非专业运维尽量不要自己部署生产环境。
|
 |
2
xuanbg 2023-11-03 10:49:24 +08:00
中间件容器化部署就简单多了
|
 |
4
6IbA2bj5ip3tK49j 2023-11-03 10:50:46 +08:00
看下来，初步判断这些“坑”都是水平问题。
|
 |
6
hancai 2023-11-03 10:56:23 +08:00
docker run 一个先跑起来就行，部署居然花了 2 天
|
 |
7
JinyAa 2023-11-03 10:59:38 +08:00
直接阿里云 ONS 服务
|
 |
8
lsk569937453 2023-11-03 11:00:45 +08:00
用 docker 的话直接 docker-compose ，一行命令启动。
用 k8s 的话直接网上找个现成的 helm chart ，一行命令启动。 现代已经有了这么多现成的武器，而楼主为了做一顿饭还在钻木取火。。。。 |
 |
9
potatowish 2023-11-03 11:04:48 +08:00 via iPhone
用 docker 简单很多，自己从头安装用 kafka 、rabbitmq
|
 |
10
liuhan907 2023-11-03 11:10:20 +08:00
消息队列还是用老牌的 kafka 靠谱
|
 |
11
HuKing OP |
 |
12
ChoateYao 2023-11-03 11:12:16 +08:00
就算不用 Docker ，也应该使用 yum 、apt 之类的一键安装吧
|
 |
13
ecric 2023-11-03 11:24:19 +08:00
我还能说点什么呢
|
 |
14
rrfeng 2023-11-03 11:42:14 +08:00
@xgfan
你要是用过 RocketMQ 就会发现它的文档根本就是残废，想找个配置项参数得去翻代码。当然这几年改好了也有可能。 |
|
15
rrfeng 2023-11-03 11:46:13 +08:00
相比来说 RabbitMQ 的文档就很完善。
|
 |
16
150530 2023-11-03 11:50:54 +08:00
订单未支付过期这种延时队列一般是怎么选型？ redis 过期 key 和 rabbitMQ 的死信也不行，听说 RocketMQ 天然支持延时队列，但是看评论说 RocketMQ 文档不是很全，会不会有什么坑啊
|
|
17
HuKing OP @150530 我就是看了一些推荐所以才在 RabbitMQ 和 RocketMQ 中选了 Rocket 的，文档这几天看下来感觉确实有点不太行，官方的 Samples 里面都是云服务的，真的很头大！
|
|
20
rrfeng 2023-11-03 11:55:29 +08:00  1
@HuKing
量少用 RabbitMQ ，量大上 Pulsar ，Kafka 虽然老牌但是设计上有缺陷，对运维很不友好。 |
|
21
rrfeng 2023-11-03 11:57:43 +08:00
刚看了一眼，5.0 这是重构了啊，哈哈哈
|
|
23
potatowish 2023-11-03 12:06:47 +08:00 via iPhone
@150530 rabbitmq 支持消息、队列级别的过期机制，怎么不行，一直用这个方案，
|
|
24
150530 2023-11-03 12:21:15 +08:00
@potatowish 不是说消息过期放入死信时机不准确吗，“当消息在队列中过期时，只有当它是队列中的第一个消息时才会被放入死信队列”
|
 |
25
adoal 2023-11-03 12:38:10 +08:00
互联网大肠，尤其是国内的，开源出来的重型基础设施软件，基本上是要像原厂那样有一定规模和水平的运维团队才能玩溜的
|
|
26
potatowish 2023-11-03 12:47:05 +08:00 via iPhone
@150530 这是使用上的问题，因为过期消息到达队列头部时才会进入死信队列，只要保证同一个队列的消息过期时间相同就行，可以在队列级别设置。
|
|
27
potatowish 2023-11-03 12:53:36 +08:00 via iPhone
@150530 另外一种方式是安装 RabbitMQ 延迟消息插件，可以解决这个问题
|
|
28
150530 2023-11-03 13:03:45 +08:00
@potatowish 是不是得保证新加入数据的过期时间要比之前加入数据的过期时间要长才行，在队列级别设置是要怎么操作
|
 |
29
WashFreshFresh 2023-11-03 13:16:04 +08:00
@150530 过期时间是在队列初始化的时候就设置好的，不存在新加入的数据过期时间和之前假如数据的过期时间不一致的问题，这个过期时间是队列级别的。
|
|
30
150530 2023-11-03 13:31:29 +08:00
@WashFreshFresh 队列级别的意思是几秒钟内过期的数据或者同一时间过期的都属于一个队列 然后对队列设置过期时间吗？
|
|
31
WashFreshFresh 2023-11-03 13:42:06 +08:00
@150530 你设置队列的过期时间是 5 分钟，那么所有往这个队里 push 的消息过期时间都是 5 分钟，不存在单个消息单独定制过期时间了。所以如果需要支持过期时间不同的消息，应该是对应多个队列。
|
|
32
150530 2023-11-03 13:52:13 +08:00
@WashFreshFresh 如果每个消息的过期时间不同是不是就得一个消息对应一个队列，这样是否有点不妥
|
 |
33
RainCats 2023-11-03 13:56:59 +08:00
RocketMQ5 还没用过，4 用过，好像部署起来使用也没那么难，看下文档再结合看下其他一些博客很快就能用上了
|
|
34
WashFreshFresh 2023-11-03 14:09:35 +08:00
@150530 对的，看业务需求了。不过理论上同一个类型的消息过期时间都一样，大家都是 5 分钟，10 分钟什么的，所以一两个队列就够了。
|
|
35
150530 2023-11-03 14:12:06 +08:00
@WashFreshFresh 感谢解答
|
 |
36
8355 2023-11-03 14:17:23 +08:00
看了上面的评论有点不太能理解了，买云厂商服务的话按量付费买一个月能多少钱？浪费这么多精力暂且不说后面还有多久才能调通？
|
 |
37
emailzzjcool 2023-11-03 14:20:30 +08:00
建议买云，里面运维的话坑很多的
|
 |
38
yulgang 2023-11-03 14:21:26 +08:00
官方文档都这样坑了，换个别的 MQ 算了😁
|
 |
39
anubu 2023-11-03 14:36:36 +08:00 1
因公司项目被迫部署维护 rocketmq 、nacos 、sentinel ，得到一点经验，远离阿里主导的开源项目。文档一塌糊涂，稍微有点量级，绝对有个特性在商业版里等着你。
所以，低量级有其它更好的选择，高量级就直接用商业版。 不反对把开源作为商业策略的一种，国内外都是这么玩的，只是阿里当前的玩法太粗糙了。 |
 |
41
SoulSleep 2023-11-03 15:40:10 +08:00
我司有 8 个集群，用的好像最高是 4.7....高峰期每天百亿消息....挺好的啊
另外,,,,开发既要又要容易出问题....如果不熟悉，有没有 docker-compose 体验一下啊..... 按照你这个进展....应该还有一堆问题等着你.... |
 |
42
Scarb 2023-11-03 15:55:02 +08:00
5.x 增加了 proxy 和 gRPC 协议的客户端，新的客户端做了轻量化，把重平衡放到服务端了。
其实你没必要用 proxy 和 gRPC 客户端，用老的 java 客户端就行，这样也不用 proxy ，单独起 broker 。5.x 是兼容老的客户端的。 老客户端用的 rocketmq remoting 协议，依赖是 rocketmq-client： https://mvnrepository.com/artifact/org.apache.rocketmq/rocketmq-client 确实文档比较拉，现在的官网还是重构过的，比以前还好一点 |
 |
43
nodesolar 2023-11-03 16:05:12 +08:00
建议 kafka 哈哈哈
|
 |
44
v2e0xAdmin2 2023-11-03 16:06:43 +08:00
我有一个基于 mysql 实现的消息队列，你可以看看 https://github.com/stateIs0/ems
|
|
45
Scarb 2023-11-03 16:40:33 +08:00
@150530 支持定时消息，4.x 支持固定延迟时间的延迟消息，5.x 添加了任意时间的定时消息，使用方法： https://rocketmq.apache.org/zh/docs/featureBehavior/02delaymessage#%E4%BD%BF%E7%94%A8%E7%A4%BA%E4%BE%8B
没什么坑 |
 |
46
szmx 2023-11-03 19:13:09 +08:00
@v2e0xAdmin2 使用 redis 消息队列是否和你这个差不多
|
 |
47
nananqujava 2023-11-03 23:44:50 +08:00
RocketMQ 的文档确实一言难尽, 之前自己搭过, 确实有很多坑, 相比来说 kafka 和 rabbitmq 就要好用些
|
Select Language