Skip to content

Commit 217ce16

Browse files
committedSep 11, 2023
Update rabbitmq-questions.md
1 parent 4f89499 commit 217ce16

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed
 

‎docs/high-performance/message-queue/rabbitmq-questions.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -164,9 +164,9 @@ RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都
164164

165165
## 说说 Broker 服务节点、Queue 队列、Exchange 交换器?
166166

167-
- **Broker**:可以看做 RabbitMQ 的服务节点。一般请下一个 Broker 可以看做一个 RabbitMQ 服务器。
168-
- **Queue** :RabbitMQ 的内部对象,用于存储消息。多个消费者可以订阅同一队列,这时队列中的消息会被平摊(轮询)给多个消费者进行处理。
169-
- **Exchange** : 生产者将消息发送到交换器,由交换器将消息路由到一个或者多个队列中。当路由不到时,或返回给生产者或直接丢弃。
167+
- **Broker**:可以看做 RabbitMQ 的服务节点。一般情况下一个 Broker 可以看做一个 RabbitMQ 服务器。
168+
- **Queue**RabbitMQ 的内部对象,用于存储消息。多个消费者可以订阅同一队列,这时队列中的消息会被平摊(轮询)给多个消费者进行处理。
169+
- **Exchange**生产者将消息发送到交换器,由交换器将消息路由到一个或者多个队列中。当路由不到时,或返回给生产者或直接丢弃。
170170

171171
## 什么是死信队列?如何导致的?
172172

@@ -244,4 +244,4 @@ Demo 级别的,一般就是你本地启动了玩玩儿的?,没人生产用
244244

245245
RabbtiMQ 是可以设置过期时间的,也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉,这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里,而是大量的数据会直接搞丢。我们可以采取一个方案,就是批量重导,这个我们之前线上也有类似的场景干过。就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上 12 点以后,用户都睡觉了。这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入 mq 里面去,把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面,没有处理,其中 1000 个订单都丢了,你只能手动写程序把那 1000 个订单给查出来,手动发到 mq 里去再补一次。
246246

247-
<!-- @include: @article-footer.snippet.md -->
247+
<!-- @include: @article-footer.snippet.md -->

0 commit comments

Comments
 (0)
Please sign in to comment.