当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时，此时可以通过 RabbitMQ 集群来进行扩展，从而达到提升吞吐量的目的。RabbitMQ 集群是一个或多个节点的逻辑分组，集群中的每个节点都是对等的，每个节点共享所有的用户，虚拟主机，队列，交换器，绑定关系，运行时参…

MQ就是消息队列。是软件和软件进行通信的中间件产品 异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。 应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。 流量削锋 - 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。 日志处理 - 解决大量日志…

任何一个服务，如果仅仅是单机部署，那么性能总是有上限的，RabbitMQ 也不例外，当单台 RabbitMQ 服务处理消息的能力到达瓶颈时，可以通过集群来实现高可用和负载均衡。 内存节点：元数据存放于内存中。为了重启后能同步数据，内存节点会将磁盘节点的地址存放于磁盘之中，除此之…

对于消息确认消费/不重复消费，主要是针对消费者端对消息的确认消费机制。 对于消息是否发送成功，在rabbitmq自定义操作组件中可以统一设置消息生产确认相关逻辑rabbitTemplate.setConfirmCallback和rabbitTemplate.setReturnC…

对于这种业务逻辑的处理，传统的做法是采用“定时器的方式”，定时轮询获取已经超过指定时间的订单，然后执行一系列的处理措施（比如再争取给用户发送短信，提醒超过多长时间订单就要失效了等等。。。），在这个秒杀系统中，我们将借助RabbitMQ死信队列这一组件，对该订单执行“失效”的措施…

1. 前情回顾 截止目前，我们能够保证消息成功地被生产者发送到RabbitMQ服务器，也能保证RabbitMQ服务器发生异常（重启，宕机等）后消息不会丢失，也许你认为现在消息应该很安全了吧？其实还不够安全，不信你接着往下看。 2. 本篇概要 其实，还有1种场景需要考虑：当消费者…

最近接到一个需求,要求在数据状态变更10分钟后向用户推送一条微信消息;分析:按照传统做法,这个可能要使用定时任务去扫描对应表中的数据,但是这样做会造成两个问题:1.频繁扫描数据库,会增加数据库开销;2

最近开发一个活动功能，需要在活动结束后给榜单 Top10 用户发放奖励。由于活动的榜单是通过 RabbitMQ 进行异步统计分值排名的，因此在活动结束时队列中可能还存在消息未消费完全，排名不准确，此时发放活动奖励必然会出错。 那么，如果解决这个问题呢？ 与产品经理协商，允许延迟…

说道消息队列，你肯定会想到Kafka、Rabbitmq等消息中间件，这些专业的消息中间件提供了很多功能特性，当然他的部署使用维护都是比较麻烦的。如果你对消息队列没那么高要求，想要轻量级的，使用Redis就没错啦。 上面代码会有个问题如果队列长时间是空的，那pop就不会不断的循环…