摘要:Kafka v.s. RabbitMQ 优先选择Kafka的条件 ·严格的消息顺序 ·延长消息留存时间,包括过去消息重放的可能 ·传统解决方案无法满足的高伸缩能力 优先选择RabbitMQ的条件 ·高级灵活的路由规则 ·消息时序控制(控制消息过期或消息延迟) ·高级的容错处理能力,在消费者更有可能处
阅读全文
摘要:一、关键概念 1.1 元数据 元数据包含以下内容: queue元数据:queue名称、属性 exchange元数据:exchange名称、类型、属性 binding元数据:exchange和queue之间、exchange和exchange之间的绑定关系 vhost元数据:vhost内部的命名空间、
阅读全文
摘要:建立连接Connection。由producer和consumer创建连接,连接到broker的物理节点上。 建立消息Channel。Channel是建立在Connection之上的,一个Connection可以建立多个Channel。producer连接Virtual Host 建立Channel
阅读全文
摘要:一、数据丢失的三个场景 一条消息从生产者发送到消费者消费的过程: 可以看出,一条消息整个过程要经历两次的网络传输: 从生产者发送到RabbitMQ服务器,从RabbitMQ服务器发送到消费者 在消费者未消费前存储在队列(Queue)中 所以可以知道,有三个场景下是会发生消息丢失的: 生产者发送消息到
阅读全文
摘要:vhost本质上是一个mini版的RabbitMQ服务器,拥有自己的队列、绑定、交换器和权限控制; vhost通过在各个实例间提供逻辑上分离,允许你为不同应用程序安全保密地运行数据; vhost是AMQP概念的基础,必须在连接时进行指定,RabbitMQ包含了默认vhost:“/”; 当在Rabbi
阅读全文
摘要:总结 1.异步处理: 用户注册后,发送“注册邮件”和“注册短信”。用户注册完成后,提交任务到 MQ,发送模块并行获取 MQ 中的任务。 2.系统解耦:比如用注册完成,再加一个发送微信通知。只需要新增发送微信消息模块,从 MQ 中读取任务,发送消息即可。无需改动注册模块的代码,这样注册模块与发送模块通
阅读全文
摘要:一、使用场景 二、两种方式设置惰性队列 三、内存开销对比
阅读全文
摘要:一、使用场景 在我们系统中有一个订单催付的场景,我们的客户在天猫下的订单,淘宝会及时将订单推送给我们,如 果在用户设定的时间内未付款那么就会给用户推送一条短信提醒,很简单的一个功能对吧,但是,tmall 商家对我们来说,肯定是要分大客户和小客户的对吧,比如像苹果,小米这样大商家一年起码能给我们创 造
阅读全文
摘要:一、什么是幂等性? 二、消息重复消费场景 三、消费端的幂等性保障 3.1 唯一ID+指纹码 3.2 Redis原子性
阅读全文
摘要:前言:“发布确认” vs “高级发布确认” RabbitMQ - [核心] 发布确认 :是在“信道channel”上进行确认 RabbitMQ - [高级] 高级发布确认:是确保“交换机exchange”和“队列queue”有问题时,会有消息给发送者 一、为什么需要“高级发布确认” 偶尔由于不明原因
阅读全文
摘要:一、延迟队列概念 二、延迟队列使用场景 三、RabbitMQ 中的 TTL TTL 是什么呢? TTL 是 RabbitMQ 中一个消息或者队列的属性,表明一条消息或者该队列中的所有 消息的最大存活时间,单位是毫秒。 换句话说,如果一条消息设置了 TTL 属性或者进入了设置TTL 属性的队列,那么这
阅读全文
摘要:一、死信的概念 二、死信的来源 三、死信实战 消费者C1,要声明两个交换机,两个队列。 消费者C2,只需要声明死信交换机即可。 原因一:消息TTL过期 原因二:队列达到最大长度 原因三:消息被拒
阅读全文
摘要:前言:为何使用交换机 Exchanges? 在简单模式和工作模式中,生产者发布一个消息,会通过默认路由,路由到一个队列中,只能被一个消费者消费,不能重复消费。 如果想让一个消息被多个消费者消费,就需要通过交换机exchanges将消息路由routing到多个队列中即可。这就是发布订阅模式。 一、Ex
阅读全文
摘要:发布确认的原理 发布确认的开启 发布确认的策略 单个确认发布(同步+阻塞) 批量确认发布(同步+阻塞) 其代码与单个确认相比,仅仅多了批处理的逻辑而已 异步确认发布(异步+非阻塞) 代码 如何处理异步未确认消息 需要修改的代码 1.在发布之前,把所有的消息先存在ConcurrentHashMap中
阅读全文
摘要:一、公平分发 (轮询) (感觉订阅到同一个队列的工作线程,默认就是轮询...没有特殊的设置) 用同一套代码,跑起来两个线程: 第一个线程先跑起来 然后勾选“allow parallel run” 还能修改代码 再跑起来第二个线程 二、消息应答 2.1 自动应答(不用) 不是很靠谱,尽量不使用! 2.
阅读全文
摘要:总结 场景1:单发送单接收 使用场景:简单的发送与接收,没有特别的处理。 场景2:单发送多接收 使用场景:一个发送端,多个接收端,如分布式的任务派发。为了保证消息发送的可靠性,不丢失消息,使消息持久化了。同时为了防止接收端在处理消息时down掉,只有在消息处理完成后才发送ack消息。 场景3:Pub
阅读全文
摘要:1.Broker: 简单来说就是消息队列服务器实体。 2.Virtual Host(vhost): 虚拟主机,一个broker里可以开设多个vhost,用作权限分离,把不同的系统使用的rabbitmq区分开,共用一个消息队列服务器,但看上去就像各自在用不用的rabbitmq服务器一样。。详细:Vir
阅读全文
摘要:总结 ActiveMQ 优点: 可用性比较高,单机吞吐量万级,时效毫秒ms级; 可靠性高,低概率丢失数据 缺点: ActiveMQ 5.x 维护越来越少; 高吞吐量场景较少使用 RabbitMQ(最常用) 天生为金融互联网领域而生,消息0丢失 优点: 可用性极高,单机吞吐量万级,时效性微妙μs级 支
阅读全文