服务间调用难以保持一致性。例如上图中的两次调用。因为三个步骤操作的不是同一个数据库，导致无法使用jdbc事务管理以达到一致性。而且两次服务调用，因为涉及到复杂的网络环境，很容易出现，服务调用失败。

有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。 想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。 比如电商系统里订单从创建到处

单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已。普通模式：默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节...

使用Mq有哪些优点？解耦：A系统依赖B,C,D系统，A只需要发送topic，B,C,D后期不需要消息自行取消消费即可，类似消息总线异步：异步执行消息发送，通知等消峰：应对突发的流量高峰时段（错峰与流控

最近被问到这样的问题，如何让你设计一套消息队列，你会从哪些角度去设计。于是我回顾了自己对目前两款主流的消息队列RabbitMQ与Kafka的原理，并收集了一些大佬们对此问题的解答，于是给出了自己的一些理解与认识。解耦：基于消息的模型，关心的是“通知”，而非“处理”，相对而言更关心...

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

消息是不具名的，它有消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等 消息队列，用来保存消息直到发送给消…

之前有听到很多开发同事，一提到MQ就说是消息队列，其实这二者不是等同的。 这里消费意味着消息从队列里删除了，那么倘若有多个消费者消费这个队列的话，那么每个消费者之间就存在着竞争关系，同一条消息不会被多个消费者所消费，每个消费者呢只会消费该队列里部分消息。那么如何让每个消费者消费…

画外音：发送方只要将邮件协议里的时间调整为 1970 年或者 2970 年，就可以在接收方收到邮件后一直 “置顶” 或者“置底”。 对于严格时序的业务场景，可以利用单点写 db 的 seq/auto_inc_id 生成单调递增的 id，来保证顺序性。 画外音：这个生成 id 的…