Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
wushizhenking
advanced-java
提交
0584822e
A
advanced-java
项目概览
wushizhenking
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
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,发现更多精彩内容 >>
提交
0584822e
编写于
1月 03, 2019
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
差异文件
Merge branch 'master' of github.com:doocs/advanced-java
上级
13c77548
8f18479d
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
2 addition
and
2 deletion
+2
-2
docs/high-concurrency/mq-time-delay-and-expired-failure.md
docs/high-concurrency/mq-time-delay-and-expired-failure.md
+2
-2
未找到文件。
docs/high-concurrency/mq-time-delay-and-expired-failure.md
浏览文件 @
0584822e
...
...
@@ -15,7 +15,7 @@
一个消费者一秒是 1000 条,一秒 3 个消费者是 3000 条,一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概 1 小时的时间才能恢复过来。
一般这个时候,只能临时紧急扩容了,具体操作步骤和思路如下:
-
先修复 consumer 的问题,确保其恢复消费速度,然后将现有 c
no
sumer 都停掉。
-
先修复 consumer 的问题,确保其恢复消费速度,然后将现有 c
on
sumer 都停掉。
-
新建一个 topic,partition 是原来的 10 倍,临时建立好原先 10 倍的 queue 数量。
-
然后写一个临时的分发数据的 consumer 程序,这个程序部署上去消费积压的数据,
**消费之后不做耗时的处理**
,直接均匀轮询写入临时建立好的 10 倍数量的 queue。
-
接着临时征用 10 倍的机器来部署 consumer,每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍,以正常的 10 倍速度来消费数据。
...
...
@@ -29,4 +29,4 @@
假设 1 万个订单积压在 mq 里面,没有处理,其中 1000 个订单都丢了,你只能手动写程序把那 1000 个订单给查出来,手动发到 mq 里去再补一次。
### mq 都快写满了
如果消息积压在 mq 里,你很长时间都没有处理掉,此时导致 mq 都快写满了,咋办?这个还有别的办法吗?没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,
**消费一个丢弃一个,都不要了**
,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧。
\ No newline at end of file
如果消息积压在 mq 里,你很长时间都没有处理掉,此时导致 mq 都快写满了,咋办?这个还有别的办法吗?没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,
**消费一个丢弃一个,都不要了**
,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录