一、rabbitmq工作模式及特点
1. 点对点模式(Point-to-Point)
点对点模式也称为工作队列模式。在这种模式中,生产者将消息发送到一个队列,消费者从队列中读取消息进行处理。每条消息只会被一个消费者处理一次。
特点:
- 消息分发:消息被分发到一个队列中,队列的消费者从中获取消息。
- 负载均衡:多个消费者可以共享一个队列,系统可以通过轮询或其他策略将消息均匀地分配给消费者。
- 适用场景:适用于需要将任务分配给多个消费者并进行负载均衡的场景,例如后台任务处理、工作负载分担等。
2. 发布/订阅模式(Publish/Subscribe)
发布/订阅模式也称为主题模式。在这种模式中,生产者将消息发送到一个主题或交换机,多个消费者可以订阅一个主题,接收来自该主题的所有消息。
特点:
- 广播消息:一个消息会被发送到所有订阅了该主题的消费者。
- 灵活的订阅:消费者可以根据需要订阅一个或多个主题。
- 适用场景:适用于需要将消息广播到多个订阅者的场景,例如实时通知、新闻推送等。
3. 路由模式(Routing)
路由模式允许通过路由键(Routing Key)将消息发送到一个或多个队列。这种模式适用于需要根据消息的属性进行精确路由的场景。
特点:
- 灵活路由:生产者在发送消息时指定路由键,消息会根据路由键的规则被发送到匹配的队列。
- 适用场景:适用于需要根据消息的内容进行特定处理的场景,例如订单处理、任务分配等。
4. 主题模式(Topic)
主题模式是一种更复杂的发布/订阅模式,允许使用通配符对消息进行更加灵活的路由。消费者可以根据消息的主题模式(例如 "order.*"
或 "order.123"
)来过滤和接收消息。
特点:
- 复杂的路由规则:通过使用通配符,消费者可以根据复杂的规则订阅消息。
- 灵活性:可以匹配多个主题,使得消息的过滤和分发更加灵活。
- 适用场景:适用于需要灵活的消息过滤和路由规则的场景,例如复杂的事件通知、动态的消息分发等。
5. RPC模式(Remote Procedure Call)
RPC模式用于远程过程调用。生产者发送请求消息到队列,消费者处理请求并将结果发送回另一个队列。RPC模式使得请求和响应的过程变得简单和可靠。
特点:
- 请求/响应模式:生产者发送请求消息,消费者处理请求并将响应消息返回。
- 同步处理:客户端通常会等待响应消息,直到操作完成。
- 适用场景:适用于需要远程调用和同步响应的场景,例如远程服务调用、异步处理等。
6. 延迟队列模式(Dead Letter Exchange, DLX)
延迟队列模式涉及将处理失败或超时的消息发送到一个备用队列或交换机,称为死信交换机(Dead Letter Exchange, DLX)。这有助于处理不能立即处理或需要特别处理的消息。
特点:
-
错误处理:将无法处理的消息或超时消息重定向到死信队列。
-
消息恢复:可以从死信队列中分析和恢复失败的消息。
-
适用场景:适用于需要处理失败或超时消息的场景,例如重试机制、故障分析等。
二、死信队列和延迟处理什么区别
死信队列用于处理无法被正常消费的消息,如消息过期、队列满或处理失败等。它将这些“死信”转发到专门的死信队列进行后续处理或分析。
延迟处理则是将消息在一定时间后再投递到目标队列,常用于控制消息的处理时机或实现定时任务。两者的关键区别在于目的:死信队列处理无法正常消费的消息,而延迟处理控制消息的处理时间。
三、主题模式和路由模式什么区别
生产者将消息发送到direct交换机,在绑定队列和交换机的时候有一个路由key,生产者发送的消息会指定一个路由key,那么消息只会发送到相应key相同的队列,接着监听该队列的消费者消费消息。
特点:指定路由key值,消费者有选择性的接收消息。
-
适用于需要将消息发送到特定队列的场景,消息是通过路由键进行分发的,消息的路由决定了它会被放入哪个队列中进行处理。
-
又称通配符模式 *星号代表一个单词 #井号代表0个或多个单词
使用直连交换机可以改善我们的系统,但是它仍有局限性,它不能实现多重条件的路由。
在消息系统中,我们不仅想要订阅基于路由键的队列,还想订阅基于生产消息的源。这时候可以使用topic交换机。
rabbitmq怎么保证消息的可靠性
死信队列怎么理解的
四、悲观锁和乐观锁
悲观锁
悲观的任务数据会被别人修改,所以在处理数据时,先对数据加锁
select XXXX for update
乐观锁
乐观的认为数据不会被别人修改,在修改数据时,再判断能不能修改(修改时要求待修改的记录和之前查询的记录要一致,如果不一致,不能修改,可以借助版本号字段判断是否一致)
表中增加版本号的字段,修改数据时,判断版本号并修改版本号
update employee set salary=2500,version=version+1 where id=1 and version=4;
五、实现点赞功能时为什么用Redis存储当天的点赞数,不把点赞总数存放在数据库当中
如果把点赞数都存放在数据库中,一般需要全量更新,但对于一些发布比较早的文章,点赞数几乎无变化。