File tree 1 file changed +4
-4
lines changed
docs/high-performance/message-queue
1 file changed +4
-4
lines changed Original file line number Diff line number Diff line change @@ -164,9 +164,9 @@ RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都
164
164
165
165
## 说说 Broker 服务节点、Queue 队列、Exchange 交换器?
166
166
167
- - ** Broker** :可以看做 RabbitMQ 的服务节点。一般请下一个 Broker 可以看做一个 RabbitMQ 服务器。
168
- - ** Queue** : RabbitMQ 的内部对象,用于存储消息。多个消费者可以订阅同一队列,这时队列中的消息会被平摊(轮询)给多个消费者进行处理。
169
- - ** Exchange** : 生产者将消息发送到交换器,由交换器将消息路由到一个或者多个队列中。当路由不到时,或返回给生产者或直接丢弃。
167
+ - ** Broker** :可以看做 RabbitMQ 的服务节点。一般情况下一个 Broker 可以看做一个 RabbitMQ 服务器。
168
+ - ** Queue** : RabbitMQ 的内部对象,用于存储消息。多个消费者可以订阅同一队列,这时队列中的消息会被平摊(轮询)给多个消费者进行处理。
169
+ - ** Exchange** : 生产者将消息发送到交换器,由交换器将消息路由到一个或者多个队列中。当路由不到时,或返回给生产者或直接丢弃。
170
170
171
171
## 什么是死信队列?如何导致的?
172
172
@@ -244,4 +244,4 @@ Demo 级别的,一般就是你本地启动了玩玩儿的?,没人生产用
244
244
245
245
RabbtiMQ 是可以设置过期时间的,也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉,这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里,而是大量的数据会直接搞丢。我们可以采取一个方案,就是批量重导,这个我们之前线上也有类似的场景干过。就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上 12 点以后,用户都睡觉了。这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入 mq 里面去,把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面,没有处理,其中 1000 个订单都丢了,你只能手动写程序把那 1000 个订单给查出来,手动发到 mq 里去再补一次。
246
246
247
- <!-- @include: @article-footer.snippet.md -->
247
+ <!-- @include: @article-footer.snippet.md -->
You can’t perform that action at this time.
0 commit comments