消息均发 前言 由前文 RabbitMq初探——消息分发 可知,rabbitmq自带分发机制——消息会按顺序的投放到该队列下的多个消费者,例如1,3,5投放消费者C1,2,4,6投放消费者C2. 这就有个隐含的缺点:每个消息的消费时间可能不一样,极端情况下,投放给C1的每个消息消费都需要很长时间,而投放给C2的每个消息消费需要很短,就会导致C1进程 负担重,C2进程很悠闲. 所以,我们需要根据任务量来均发消息. 均发消息实现 1. 开启消息确认机制. 2. 为每个消费者分配且只分配一个消息,待r…

消息确认机制 前言 消息队列的下游,业务逻辑可能复杂,处理任务可能花费很长时间.若在一条消息到达它的下游,任务刚处理了一半,由于不确定因素,下游的任务处理进程 被kill掉啦,导致任务无法执行完成.而沿用我们前面几章的消息删除[消息一旦抛给下游,就立马从队列删除],这可能会引发问题——消息没有处理完,但是队列 里的消息已经被删除了. 因此,rabbitmq内含 消息确认机制[Message acknowledgment],简称ack.rabbitmq将消息发送给consumer,此刻消息不会从队…

消息持久化 前言 通过上一节,我们知道,有消息确认机制,保证了当消费者进程挂掉后,消息的不丢失. 但是如果rabbitmq挂掉呢?它的队列和消息都会丢失的.为了保证消息在rabbitmq挂掉重启后不丢失, 我们需要用到rabbitmq的持久化机制. 开启持久化功能 1. 首先保证queue的持久化,在publisher和consumer声明queue时,开启持久化功能.本章例子可以通过下面代码开启 //函数第三个参数置为true,代表开启队列的持久化 $channel->queue_declar…

消息分发 前言 我们在用到消息队列的场景,一般是处理逻辑复杂,耗时,所以将同步改为异步处理,接入队列,下游处理耗时任务. 队列消息数量很大,且下游worker进程(消费者)处理耗时长,所以就有了任务的积压.rabbitmq提供了任务分发的机制. 流程弱化如下图: 可以接入多个消费者,rabbitmq会将消息均匀的分发给每一个消费者. 耗时任务 我们可以在consumer端用sleep()函数来模拟耗时任务,通过判断消息的点的个数,来进行相应的sleep几秒. sender.php require…

前言 本篇博客已被收录GitHub:https://zhouwenxing.github.io/ 文中所涉及的源码也已被收录GitHub:https://github.com/zhouwenxing/lonely-wolf-note (message-queue模块) 使用消息队列必须要保证生产者发送的消息能被消费者所接收,那么生产者如何接收消息呢?下图是 RabbitMQ 的工作模型: 上图中生产者会将消息发送到交换机 Exchange 上,再由 Exchange 发送给不同的 Queue ,…

最近的工作我在做一个有关于消息发送和接受封装工作.大概流程是这样的,消息中间件是采用rabbitmq,为了保证消息的绝对无丢失,我们需要在发送和接受前对消息进行DB落地.在发送前我会先进行DB的插入,单表插入,所以在性能上也是能接受的,单表插入做了压测基本上是一到两毫秒的时间,加上消息的发送(有ACK)再加上集群是两个节点的高可用(一个磁盘持久化节点),单台TPS基本上是在2000-3000左右.这对于我们的业务场景来说是够用了.一旦当消息丢失或者由于网络问题.集群问题业务不会中断,消息就算发不…

在上篇<RabbitMQ-高效的Work模式>中,我们了解了Work模型,该模型包括一个生产者,一个消息队列和多个消费者. 我们已经通过实例看出消息队列中的消息是如何被一个或者多个消费者消费的了,但是对于具体的实现细节和原理并没有介绍.这篇就来详细介绍下在消息派发这个过程中还有那些我们需要关注的点和细节. 这篇主要讨论细节都集中在接收端,我们还是来看下上篇中,接收端的代码实现 package com.ximalaya.openapi.rabbitmq.work; import com.rabb…

在之前的有关线程,进程的博客中,我们介绍了它们各自在同一个程序中的通信方法.但是不同程序,甚至不同编程语言所写的应用软件之间的通信,以前所介绍的线程.进程队列便不再适用了:此种情况便只能使用socket编程了,然而不同程序之间的通信便不再像线程进程之间的那么简单了,要考虑多种情况(比如其中一方断线另一方如何处理:消息群发,多个程序之间的通信等等),如果每遇到一次程序间的通信,便要根据不同情况编写不同的socket,还要维护.完善这个socket这会使得编程人员的工作量大大增加,也使得程序更易崩溃…

从前面文章可以看出,消息总线是EDA(事件驱动架构)与微服务架构的核心部件,没有消息总线,就无法很好的实现微服务之间的解耦与通讯.通常我们可以利用现有成熟的消息代理产品或云平台提供的消息服务来构建自己的消息总线:也可以自己完全写一个消息代理产品,然后基于它构建自己的消息总线.通常我们不用重复造轮子(除非公司有特殊的要求,比如一些大型互联网公司考虑到自主可控的白盒子),可以利用比如像RabbitMq这样成熟的消息代理产品作为消息总线的底层支持. RabbitMq核心组件解释: Connection…

简要介绍 RabbitMQ RabbitMQ是实现AMQP(高级消息队列协议)的消息中间件的一种,最初起源于金融系统,用于在分布式系统中存储转发消息,在易用性.扩展性.高可用性等方面表现不俗.消息中间件主要用于组件之间的解耦,消息的发送者无需知道消息使用者的存在,反之亦然. Redis 是一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用. 具体对比 可靠消费 Redis:没有相…