docs: update articles

docs/high-concurrency/mq-time-delay-and-expired-failure.md

@@ -20,11 +20,11 @@
 
 一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下：
 
-- 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
-- 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
-- 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，**消费之后不做耗时的处理**，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
-- 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
-- 等快速消费完积压数据之后，**得恢复原先部署的架构**，**重新**用原先的 consumer 机器来消费消息。
+-   先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
+-   新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
+-   然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，**消费之后不做耗时的处理**，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
+-   接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
+-   等快速消费完积压数据之后，**得恢复原先部署的架构**，**重新**用原先的 consumer 机器来消费消息。
 
 ### mq 中的消息过期失效了
 
@@ -78,10 +78,10 @@ public ConsumeConcurrentlyStatus consumeMessage(
 
 举例如下，某条消息的消费过程如下：
 
-- 根据消息从 DB 查询【数据 1】
-- 根据消息从 DB 查询【数据 2】
-- 复杂的业务计算
-- 向 DB 插入【数据 3】
-- 向 DB 插入【数据 4】
+-   根据消息从 DB 查询【数据 1】
+-   根据消息从 DB 查询【数据 2】
+-   复杂的业务计算
+-   向 DB 插入【数据 3】
+-   向 DB 插入【数据 4】
 
 这条消息的消费过程中有 4 次与 DB 的 交互，如果按照每次 5ms 计算，那么总共耗时 20ms，假设业务计算耗时 5ms，那么总过耗时 25ms，所以如果能把 4 次 DB 交互优化为 2 次，那么总耗时就可以优化到 15ms，即总体性能提高了 40%。所以应用如果对时延敏感的话，可以把 DB 部署在 SSD 硬盘，相比于 SCSI 磁盘，前者的 RT 会小很多。