Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
晶之木
advanced-java
提交
cc4305ca
A
advanced-java
项目概览
晶之木
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
3
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
cc4305ca
编写于
10月 13, 2020
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
feat: update mq-time-delay-and-expired-failure
RocketMQ 消息积压解决方案补充
上级
1df021f2
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
48 addition
and
0 deletion
+48
-0
docs/high-concurrency/mq-time-delay-and-expired-failure.md
docs/high-concurrency/mq-time-delay-and-expired-failure.md
+48
-0
未找到文件。
docs/high-concurrency/mq-time-delay-and-expired-failure.md
浏览文件 @
cc4305ca
...
...
@@ -37,3 +37,51 @@
### mq 都快写满了
如果消息积压在 mq 里,你很长时间都没有处理掉,此时导致 mq 都快写满了,咋办?这个还有别的办法吗?没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,
**消费一个丢弃一个,都不要了**
,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧。
---
对于 RocketMQ,官方针对消息积压问题,提供了解决方案。
### 1. 提高消费并行度
绝大部分消息消费行为都属于 IO 密集型,即可能是操作数据库,或者调用 RPC,这类消费行为的消费速度在于后端数据库或者外系统的吞吐量,通过增加消费并行度,可以提高总的消费吞吐量,但是并行度增加到一定程度,反而会下降。所以,应用必须要设置合理的并行度。 如下有几种修改消费并行度的方法:
同一个 ConsumerGroup 下,通过增加 Consumer 实例数量来提高并行度(需要注意的是超过订阅队列数的 Consumer 实例无效)。可以通过加机器,或者在已有机器启动多个进程的方式。
提高单个 Consumer 的消费并行线程,通过修改参数 consumeThreadMin、consumeThreadMax 实现。
### 2. 批量方式消费
某些业务流程如果支持批量方式消费,则可以很大程度上提高消费吞吐量,例如订单扣款类应用,一次处理一个订单耗时 1 s,一次处理 10 个订单可能也只耗时 2 s,这样即可大幅度提高消费的吞吐量,通过设置 consumer 的 consumeMessageBatchMaxSize 返个参数,默认是 1,即一次只消费一条消息,例如设置为 N,那么每次消费的消息数小于等于 N。
### 3. 跳过非重要消息
发生消息堆积时,如果消费速度一直追不上发送速度,如果业务对数据要求不高的话,可以选择丢弃不重要的消息。例如,当某个队列的消息数堆积到 100000 条以上,则尝试丢弃部分或全部消息,这样就可以快速追上发送消息的速度。示例代码如下:
```
java
public
ConsumeConcurrentlyStatus
consumeMessage
(
List
<
MessageExt
>
msgs
,
ConsumeConcurrentlyContext
context
)
{
long
offset
=
msgs
.
get
(
0
).
getQueueOffset
();
String
maxOffset
=
msgs
.
get
(
0
).
getProperty
(
Message
.
PROPERTY_MAX_OFFSET
);
long
diff
=
Long
.
parseLong
(
maxOffset
)
-
offset
;
if
(
diff
>
100000
)
{
// TODO 消息堆积情况的特殊处理
return
ConsumeConcurrentlyStatus
.
CONSUME_SUCCESS
;
}
// TODO 正常消费过程
return
ConsumeConcurrentlyStatus
.
CONSUME_SUCCESS
;
}
```
### 4. 优化每条消息消费过程
举例如下,某条消息的消费过程如下:
-
根据消息从 DB 查询【数据 1】
-
根据消息从 DB 查询【数据 2】
-
复杂的业务计算
-
向 DB 插入【数据 3】
-
向 DB 插入【数据 4】
这条消息的消费过程中有 4 次与 DB 的 交互,如果按照每次 5ms 计算,那么总共耗时 20ms,假设业务计算耗时 5ms,那么总过耗时 25ms,所以如果能把 4 次 DB 交互优化为 2 次,那么总耗时就可以优化到 15ms,即总体性能提高了 40%。所以应用如果对时延敏感的话,可以把 DB 部署在 SSD 硬盘,相比于 SCSI 磁盘,前者的 RT 会小很多。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录