From 8af6de3d1c6c02d2a602bb8e68e56c729436f2a8 Mon Sep 17 00:00:00 2001 From: yanglbme Date: Thu, 6 Dec 2018 14:26:47 +0800 Subject: [PATCH] fix(docs): fix typo --- README.md | 3 ++- docs/high-concurrency/mq-time-delay-and-expired-failure.md | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index fcb6df5..dde6e17 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,11 @@ [![original](https://img.shields.io/badge/original-%E4%B8%AD%E5%8D%8E%E7%9F%B3%E6%9D%89-blue.svg)](https://github.com/doocs/advanced-java) [![PRs Welcome](https://img.shields.io/badge/PRs-Welcome-brightgreen.svg)](http://makeapullrequest.com) -本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。 +本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。By the way，微信公众号**石杉的架构笔记**（id:shishan100）有其它很多架构知识，墙裂推荐~ 一点小建议：学习本系列知识之前，如果你完全没接触过 `MQ`、`ES`、`Redis`、`Dubbo`、`Hystrix` 等，那么我建议你可以先在网上搜一下每一块知识的快速入门，玩一下入门 Demo，然后再开始每一块知识的学习。这样效果更好噢~ + ## 高并发架构 ### [消息队列](/docs/high-concurrency/mq-interview.md) diff --git a/docs/high-concurrency/mq-time-delay-and-expired-failure.md b/docs/high-concurrency/mq-time-delay-and-expired-failure.md index b162f13..441f3ad 100644 --- a/docs/high-concurrency/mq-time-delay-and-expired-failure.md +++ b/docs/high-concurrency/mq-time-delay-and-expired-failure.md @@ -12,7 +12,7 @@ ### 大量消息在 mq 里积压了几个小时了还没解决 几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。 -一个消费者一秒是 1000 条，一秒 3个 消费者是 3000 条，一分钟就是是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。 +一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。 一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下： - 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。 -- GitLab