![](https://img-blog.csdnimg.cn/20201014180756922.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
MQ
文章平均质量分 87
遇见更好的自己、
勤奋是改变命运的唯一途径
展开
-
kafka的请求处理机制
无论是 Kafka 客户端还是 Broker 端,它们之间的交互都是通过。比如,客户端会通过网络发送消息生产请求给 Broker,而 Broker 处理完成后,会发送对应的响应给到客户端。Kafka 自己定义了一组请求协议,用于实现各种各样的交互操作。比如常见的。原创 2023-10-08 18:18:21 · 539 阅读 · 0 评论 -
kafka副本机制
现在的很多的分布式系统都支持副本的机制,比如Mysql就有副本的机制,一般使用副本有如下特性和好处。提供数据冗余。即使系统部分组件失效,系统依然能够继续运转,因而增加了整体可用性以及数据持久性。提供高伸缩性。支持横向扩展,能够通过增加机器的方式来提升读性能,进而提高读操作吞吐量。改善数据局部性。允许将数据放入与用户地理位置相近的地方,从而降低系统延时。而kafka的副本机制仅仅享受到了第一个好处。但是即使是这样,kafka的副本机制也是确保系统高可用和消息高持久性的重要基石。原创 2023-09-21 18:28:02 · 516 阅读 · 0 评论 -
kafka消费者多线程开发
目前,计算机的硬件条件已经大大改善,即使是在普通的笔记本电脑上,多核都已经是标配了,更不用说专业的服务器了。如果跑在强劲服务器机器上的应用程序依然是单线程架构,那实在是有点暴殄天物了。不过,Kafka Java Consumer 就是单线程的设计,你是不是感到很惊讶。所以,探究它的多线程消费方案,就显得非常必要了。原创 2023-09-20 18:18:24 · 1039 阅读 · 0 评论 -
kafka的commitFaildException异常处理
CommitFailedException,顾名思义就是 Consumer 客户端在提交位移时出现了错误或异常,原创 2023-09-12 10:02:11 · 378 阅读 · 0 评论 -
kafka位移提交
因为 Consumer 能够同时消费多个分区的数据,所以位移的提交实际上是在分区粒度上进行的,原创 2023-09-07 16:51:40 · 565 阅读 · 0 评论 -
kafka如何避免消费组重平衡
Rebalance 就是让一个 Consumer Group下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中,所有 Consumer 实例共同参与,在协调者组件的帮助下,完成订阅主题分区的分配。但是,在整个过程中,所有实例都不能消费任何消息,因此它对 Consumer 的 TPS 影响很大。组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组,抑或是有 Consumer 实例崩溃被“踢出”组。订阅主题数发生变更。原创 2023-08-28 18:30:53 · 629 阅读 · 0 评论 -
kafka消费组及位移主题
消费者组,即 Consumer Group,应该算是 Kafka 比较有亮点的设计了。那么何谓 Consumer Group 呢?用一句话概括就是:Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。原创 2023-08-24 18:29:21 · 724 阅读 · 0 评论 -
kafka生产者幂等与事务
幂等性 Producer 和事务型 Producer 都是 Kafka 社区力图为 Kafka 实现精确一次处理语义所提供的工具,只是它们的作用范围是不同的。幂等性 Producer 只能保证单分区、单会话上的消息幂等性;而事务能够保证跨分区、跨会话间的幂等性。从交付语义上来看,自然是事务型 Producer 能做的更多。不过,切记天下没有免费的午餐。比起幂等性 Producer,事务型 Producer 的性能要更差,在实际使用过程中,我们需要仔细评估引入事务的开销,切不可无脑地启用事务。原创 2023-08-14 18:53:03 · 1419 阅读 · 0 评论 -
RabbitMQ的confirm机制
关于RabbitMQ的confrim使用机制我相信大家有了一定的了解,我这边就不在这边过多的介绍,如果还有不太清楚的朋友,可以去朱小厮的博客去学习,我把对应的博客链接放在下面的位置。RabbitMQ之消息确认机制(事务+Confirm)_朱小厮的博客-CSDN博客_rabbitmq生产者确认机制。.........原创 2022-08-01 20:25:46 · 5200 阅读 · 0 评论 -
分布式幂等设计方案
幂等设计作为网络通信重要的一环,在消息队列的使用中、在接口调用的场景中,我们或多或少的都要对自己提供的接口进行幂等设计。当我们的接口涉及到金额相关的操作。我们一定要考虑幂等,不然就可能存在。退款多退、订单多下、佣金多发等重大生产事故。幂等其实是数学概念,它的定义是这样的:如果一个函数 f(x) 满足:f(f(x)) = f(x),则函数 f(x) 满足幂等性。回到我们的软件设计的过程中:例如:我们提供出去的接口:被调用一次和调用10次,调用100次,对业务执行的结果都是一样的。比如: 我们设计这样的接原创 2022-06-13 20:54:08 · 450 阅读 · 0 评论 -
RabbitMQ的ack和nack机制
当生产者的发送消息到exchange,并路由到对应的队列后,MQ主动push消息到channel,由应用线程从channel中获取消息。主动ACK是指在MQ主动push到channel中后,channel立马自动的给到MQ ack响应,然后MQ删除消息。MQ使用的问题点:1、当消费者宕机的情况下,会导致消息丢失,因为MQ已经删除了对应的消息。2、只要队列中存在消息,MQ就会全部推送给消费者的channel。如果数据量过大,存在拖垮消费者的风险。所以,一般使用MQ的时候选择使用手动ACK避免因消费者宕原创 2022-06-01 11:38:16 · 7574 阅读 · 0 评论 -
《消息队列高手课》Kafka和RocketMQ的消息复制实现的差异点在哪?
之前我在《[05 | 如何确保消息不会丢失?]》那节课中讲过,消息队列在收发两端,主要是依靠业务代码,配合请求确认的机制,来保证消息不会丢失的。而在服务端,一般采用持久化和复制的方式来保证不丢消息。把消息复制到多个节点上,不仅可以解决丢消息的问题,还可以保证消息服务的高可用。即使某一个节点宕机了,还可以继续使用其他节点来收发消息。所以大部分生产系统,都会把消息队列配置成集群模式,并开启消息复制,来保证系统的高可用和数据可靠性。这节课我们来讲一下,消息复制需要解决的一些问题,以及 RocketMQ 和转载 2022-05-24 11:41:14 · 174 阅读 · 0 评论 -
《消息队列高手课》Kafka Consumer源码分析:消息消费的实现过程
我们在上节课中提到过,用于解决消息队列一些常见问题的知识和原理,最终落地到代码上,都包含在收、发消息这两个流程中。对于消息队列的生产和消费这两个核心流程,在大部分消息队列中,它实现的主要流程都是一样的,所以,通过这两节课的学习之后,掌握了这两个流程的实现过程。无论你使用的是哪种消息队列,遇到收发消息的问题,你都可以用同样的思路去分析和解决问题。上一节课我和你一起通过分析源代码学习了 RocketMQ 消息生产的实现过程,本节课我们来看一下 Kafka 消费者的源代码,理清 Kafka 消费的实现过程,并转载 2022-05-24 11:40:23 · 715 阅读 · 0 评论 -
《消息队列高手课》RocketMQ Producer源码分析:消息生产的实现过程
对于消息队列来说,它最核心的功能就是收发消息。也就是消息生产和消费这两个流程。我们在之前的课程中提到了消息队列一些常见问题,比如,“如何保证消息不会丢失?”“为什么会收到重复消息?”“消费时为什么要先执行消费业务逻辑再确认消费?”,针对这些问题,我讲过它们的实现原理,这些最终落地到代码上,都包含在这一收一发两个流程中。在接下来的两节课中,我会带你一起通过分析源码的方式,详细学习一下这两个流程到底是如何实现的。你在日常使用消息队列的时候,遇到的大部分问题,更多的是跟 Producer 和 Consumer转载 2022-05-24 11:38:09 · 420 阅读 · 0 评论 -
《消息队列高手课》如何正确使用锁保护共享数据,协调异步线程?
在前几天的加餐文章中我讲到,JMQ 为了提升整个流程的处理性能,使用了一个“近乎无锁”的设计,这里面其实隐含着两个信息点。第一个是,在消息队列中,“锁”是一个必须要使用的技术。第二个是,使用锁其实会降低系统的性能。那么,如何正确使用锁,又需要注意哪些事项呢?今天我们就来聊一聊这个问题。我们知道,使用异步和并发的设计可以大幅提升程序的性能,但我们为此付出的代价是,程序比原来更加复杂了,多线程在并行执行的时候,带来了很多不确定性。特别是对于一些需要多个线程并发读写的共享数据,如果处理不好,很可能会产出不转载 2022-05-18 11:14:45 · 642 阅读 · 0 评论 -
《消息队列高手课》缓存策略:如何使用缓存来减少磁盘IO?
现代的消息队列,都使用磁盘文件来存储消息。因为磁盘是一个持久化的存储,即使服务器掉电也不会丢失数据。绝大多数用于生产系统的服务器,都会使用多块儿磁盘组成磁盘阵列,这样不仅服务器掉电不会丢失数据,即使其中的一块儿磁盘发生故障,也可以把数据从其他磁盘中恢复出来。使用磁盘的另外一个原因是,磁盘很便宜,这样我们就可以用比较低的成本,来存储海量的消息。所以,不仅仅是消息队列,几乎所有的存储系统的数据,都需要保存到磁盘上。但是,磁盘它有一个致命的问题,就是读写速度很慢。它有多慢呢?一般来说 SSD(固态硬盘)每转载 2022-05-18 11:05:23 · 590 阅读 · 0 评论 -
《消息队列高手课》Kafka如何实现高性能IO?
Apache Kafka 是一个高性能的消息队列,在众多消息队列产品中,Kafka 的性能绝对是处于第一梯队的。我曾经在一台配置比较好的服务器上,对 Kafka 做过极限的性能压测,Kafka 单个节点的极限处理能力接近每秒钟 2000 万条消息,吞吐量达到每秒钟 600MB。你可能会问,Kafka 是如何做到这么高的性能的?我们在专栏“进阶篇”的前几节课,讲的知识点一直围绕着同一个主题:怎么开发一个高性能的网络应用程序。其中提到了像全异步化的线程模型、高性能的异步网络传输、自定义的私有传输协议和序转载 2022-05-18 10:50:27 · 185 阅读 · 0 评论 -
《消息队列高手课》内存管理:如何避免内存溢出和频繁的垃圾回收?
不知道你有没有发现,在高并发、高吞吐量的极限情况下,简单的事情就会变得没有那么简单了。一个业务逻辑非常简单的微服务,日常情况下都能稳定运行,为什么一到大促就卡死甚至进程挂掉?再比如,一个做数据汇总的应用,按照小时、天这样的粒度进行数据汇总都没问题,到年底需要汇总全年数据的时候,没等数据汇总出来,程序就死掉了。之所以出现这些情况,大部分的原因是,程序在设计的时候,没有针对高并发高吞吐量的情况做好内存管理。要想解决这类问题,首先你要了解内存管理机制。现代的编程语言,像 Java、Go 语言等,采用的都是转载 2022-05-18 10:49:28 · 340 阅读 · 0 评论 -
《消息队列高手课》传输协议:应用程序之间对话的语言
*传输协议就是应用程序之间对话的语言。**设计传输协议,并没有太多规范和要求,只要是通信双方的应用程序都能正确处理这个协议,并且没有歧义就好了。这节课,我们就来说一下设计高性能传输协议的一些方法和技巧。如何“断句”?既然传输协议也是一种语言,那么在应用程序之间“通话”的过程中,与我们人类用自然语言沟通有很多相似之处,但是需要处理的问题却又不同。现代语言,无论是汉语还是英语,都是通过标点符号来分隔句子的,这个叫“断句”。古代汉语是没有标点符号的,断句全靠上下文,但这种断句方式有的时候会出现歧义转载 2022-05-18 10:14:07 · 136 阅读 · 0 评论 -
《消息队列高手课》序列化与反序列化:如何通过网络传输结构化的数据?
我们知道,在 TCP 的连接上,它传输数据的基本形式就是二进制流,也就是一段一段的 1 和 0。在一般编程语言或者网络框架提供的 API 中,传输数据的基本形式是字节,也就是 Byte。一个字节就是 8 个二进制位,8 个 Bit,所以在这里,二进制流和字节流本质上是一样的。那对于我们编写的程序来说,它需要通过网络传输的数据是什么形式的呢?是结构化的数据,比如,一条命令、一段文本或者是一条消息。对应到我们写的代码中,这些结构化的数据是什么?这些都可以用一个类(Class)或者一个结构体(Struct)来转载 2022-05-18 10:12:30 · 243 阅读 · 0 评论 -
《消息队列高手课》如何实现高性能的异步网络传输?
我们开发的绝大多数业务系统,它都是 IO 密集型系统。跟 IO 密集型系统相对的另一种系统叫计算密集型系统。通过这两种系统的名字,估计你也能大概猜出来 IO 密集型系统是什么意思。IO 密集型系统大部分时间都在执行 IO 操作,这个 IO 操作主要包括网络 IO 和磁盘 IO,以及与计算机连接的一些外围设备的访问。与之相对的计算密集型系统,大部分时间都是在使用 CPU 执行计算操作。我们开发的业务系统,很少有非常耗时的计算,更多的是网络收发数据,读写磁盘和数据库这些 IO 操作。这样的系统基本上都是 I转载 2022-05-13 19:15:03 · 123 阅读 · 0 评论 -
《消息队列高手课》如何使用异步设计提升系统性能?
对于开发者来说,异步是一种程序设计的思想,使用异步模式设计的程序可以显著减少线程等待,从而在高吞吐量的场景中,极大提升系统的整体性能,显著降低时延。因此,像消息队列这种需要超高吞吐量和超低时延的中间件系统,在其核心流程中,一定会大量采用异步的设计思想。接下来,我们一起来通过一个非常简单的例子学习一下,使用异步设计是如何提升系统性能的。异步设计如何提升系统性能?假设我们要实现一个转账的微服务 Transfer( accountFrom, accountTo, amount),这个服务有三个参数转载 2022-05-12 15:24:14 · 169 阅读 · 0 评论 -
《消息队列高手课》学习开源代码该如何入手?
掌握这些开源软件的最佳方式就是去学习它的源代码。很多同学跟我说:“我也很想去看一些开源软件的代码,也尝试去看过,但是面对上千个源码文件,几十万行代码,完全不知道从哪儿入手啊。”这节课我们就针对这个情况来聊一聊,学习开源软件的代码该如何入手。有一点我提前说明一下,对于这节课里面涉及到的一些名词,我会直接使用英文,主要目的是方便你直接对应到那些开源软件英文官网上的标题。通过文档来了解开源项目学习源代码应该从哪儿入手呢?最佳的方式就是先看它的文档。通过看文档,你可以快速地掌握这个软件整体的结构转载 2022-05-12 15:04:57 · 81 阅读 · 0 评论 -
《消息队列高手课》 消息积压了该如何处理?
据我了解,在使用消息队列遇到的问题中,消息积压这个问题,应该是最常遇到的问题了,并且,这个问题还不太好解决。我们都知道,消息积压的直接原因,一定是系统中的某个部分出现了性能问题,来不及处理上游发送的消息,才会导致消息积压。所以,我们先来分析下,在使用消息队列时,如何来优化代码的性能,避免出现消息积压。然后再来看看,如果你的线上系统出现了消息积压,该如何进行紧急处理,最大程度地避免消息积压对业务的影响。优化性能来避免消息积压在使用消息队列的系统中,对于性能的优化,主要体现在生产者和消费者这一收转载 2022-05-12 14:52:13 · 207 阅读 · 0 评论 -
《消息队列高手课》如何处理消费过程中的重复消息?
在消息传递过程中,如果出现传递失败的情况,发送方会执行重试,重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说,如果没有对重复消息进行处理,就有可能会导致系统的数据出现错误。比如说,一个消费订单消息,统计下单金额的微服务,如果没有正确处理重复消息,那就会出现重复统计,导致统计结果错误。你可能会问,如果消息队列本身能保证消息不重复,那应用程序的实现不就简单了?那有没有消息队列能保证消息不重复呢?消息重复的情况必然存在在 MQTT 协议中,给出了三种传递消息时能够提供的服务质量标转载 2022-05-12 14:24:43 · 395 阅读 · 0 评论 -
《消息队列高手课》如何确保消息不会丢失
对于刚刚接触消息队列的同学,最常遇到的问题,也是最头痛的问题就是丢消息了。对于大部分业务系统来说,丢消息意味着数据丢失,是完全无法接受的。其实,现在主流的消息队列产品都提供了非常完善的消息可靠性保证机制,完全可以做到在消息传递过程中,即使发生网络中断或者硬件故障,也能确保消息的可靠传递,不丢消息。绝大部分丢消息的原因都是由于开发者不熟悉消息队列,没有正确使用和配置消息队列导致的。虽然不同的消息队列提供的 API 不一样,相关的配置项也不同,但是在保证消息可靠传递这块儿,它们的实现原理是一样的。这转载 2022-05-12 11:48:56 · 207 阅读 · 0 评论 -
《消息队列高手课》如何利用事务消息实现分布式事务?
一说起事务,你可能自然会联想到数据库。的确,我们日常使用事务的场景,绝大部分都是在操作数据库的时候。像 MySQL、Oracle 这些主流的关系型数据库,也都提供了完整的事务实现。那消息队列为什么也需要事务呢?其实很多场景下,我们“发消息”这个过程,目的往往是通知另外一个系统或者模块去更新数据,消息队列中的“事务”,主要解决的是消息生产者和消息消费者的数据一致性问题。依然拿我们熟悉的电商来举个例子。一般来说,用户在电商 APP 上购物时,先把商品加到购物车里,然后几件商品一起下单,最后支付,完成购物转载 2022-05-12 11:44:09 · 419 阅读 · 0 评论 -
《消息队列高手课》主题和队列有什么区别?
如果你研究过超过一种消息队列产品,你可能已经发现,每种消息队列都有自己的一套消息模型,像队列(Queue)、主题(Topic)或是分区(Partition)这些名词概念,在每个消息队列模型中都会涉及一些,含义还不太一样。为什么出现这种情况呢?因为没有标准。曾经,也是有一些国际组织尝试制定过消息相关的标准,比如早期的 JMS 和 AMQP。但让人无奈的是,标准的进化跟不上消息队列的演进速度,这些标准实际上已经被废弃了。那么,到底什么是队列?什么是主题?主题和队列又有什么区别呢?想要彻底理解这些,我们需转载 2022-05-12 11:26:46 · 157 阅读 · 0 评论 -
《消息队列高手课》该如何选择消息队列
作为一个程序员,相信你一定听过“没有银弹”这个说法,这里面的银弹是指能轻松杀死狼人、用白银做的子弹,什么意思呢?我对这句话的理解是说,在软件工程中,不存在像“银弹”这样可以解决一切问题的设计、架构或软件,每一个软件系统,它都是独一无二的,你不可能用一套方法去解决所有的问题。在消息队列的技术选型这个问题上,也是同样的道理。并不存在说,哪个消息队列就是“最好的”。常用的这几个消息队列,每一个产品都有自己的优势和劣势,你需要根据现有系统的情况,选择最适合你的那款产品。选择消息队列产品的基本标准虽然这些转载 2022-05-12 11:11:27 · 193 阅读 · 0 评论 -
《消息队列高手课》为什么需要消息队列
消息队列是最古老的中间件之一,从系统之间有通信需求开始,就自然产生了消息队列。但是给消息队列下一个准确的定义却不太容易。我们知道,消息队列的主要功能就是收发消息,但是它的作用不仅仅只是解决应用之间的通信问题这么简单。我们举个例子说明一下消息队列的作用。话说小袁是一家巧克力作坊的老板,生产出美味的巧克力需要三道工序:首先将可可豆磨成可可粉,然后将可可粉加热并加入糖变成巧克力浆,最后将巧克力浆灌入模具,撒上坚果碎,冷却后就是成品巧克力了。最开始的时候,每次研磨出一桶可可粉后,工人就会把这桶可可粉送到加工转载 2022-05-12 11:01:47 · 150 阅读 · 0 评论 -
消息队列高手课-开篇词
前言: 最近在工作中MQ的治理项目,在极客时间上看到一门课程、消息队列高手课由京东的架构师讲解、我这边主要是记录讲师所讲的内容进行学习记录。有兴趣的同学可以去极客时间上去学习大佬的课程。2018 年,作为首席架构师,我和我的团队一起重构了京东自研的消息队列产品:JMQ(即将开源)。我们在京东实现了超过 2000 个节点的超大规模集群部署,经过 2018 年“11.11”和 2019 年“618”两次大促的实战考验,JMQ 很好地承载了大促期间超过万亿的流量洪峰。在设计开发 JMQ ..转载 2022-05-12 10:32:15 · 337 阅读 · 0 评论 -
RabbitMQ的消息补偿机制
文章目录前言 一、pandas是什么? 二、使用步骤 1.引入库 2.读入数据 总结前言提示:这里可以添加本文要记录的大概内容:例如:随着人工智能的不断发展,机器学习这门技术也越来越重要,很多人都开启了学习机器学习,本文就介绍了机器学习的基础内容。提示:以下是本篇文章正文内容,下面案例可供参考一、pandas是什么?示例:pandas 是基于NumPy 的一种工具,该工具是为了解决....原创 2022-04-21 11:35:39 · 9791 阅读 · 0 评论 -
RabbitMQ优秀博文整理
1、关于主流MQ的介绍,各MQ的优缺点。MQ的使用选举等MQ消息队列详解、四大MQ的优缺点分析_从百草园杀到三味书屋&的博客-CSDN博客_几种消息队列的优缺点2、RabbitMQ常见问题的整理,以及解决思路。图文并茂,比较详细RabbitMQ常见问题与解决方案_蝎子莱莱爱打怪的博客-CSDN博客_rabbitmq常见问题及解决3、RabbitMQ基础入口介绍,其中关于MQ消费方式说的比较好。对镜像模式的了解,以及为啥RabbitMQ只能支持万级的并发入门RabbitMQ,.原创 2022-04-11 11:38:26 · 1692 阅读 · 0 评论 -
事务提交后发送MQ消息
事务的事务扩展项目中的应用场景是当订单成功之后,发送一条消息到 MQ 当中去。由于事务是和数据库连接相绑定的,如果把发送消息和数据库操作放在一个事务里面。当发送消息时间过长时会占用数据库连接,所以就要把数据库操作与发送消息到 MQ 解耦开来。可以利用 TransactionSynchronization#afterCommit 的这个方法,当数据成功保存到数据库并且事务提交了就把消息发送到 MQ 里面。@Transactionalpublic void finishOrder(Order order原创 2022-03-29 15:14:22 · 1934 阅读 · 1 评论 -
ZooKeeper面试题整理
1. ZooKeeper 是什么?ZooKeeper 是一个开源的分布式协调服务。它是一个为分布式应用提供一致性服务的软件,分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。ZooKeeper 的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。Zookeeper 保证了如下分布式一致性特性:(1)顺序一致性(2)原子性(3)单一视原创 2021-08-31 22:01:52 · 156 阅读 · 0 评论 -
RabbitMQ的推拉模式
在rabbitmq中有两种消息处理的模式,一种是推模式/订阅模式/投递模式(也叫push模式),消费者调用channel.basicConsume方法订阅队列后,由RabbitMQ主动将消息推送给订阅队列的消费者;另一种是拉模式/检索模式(也叫pull模式),需要消费者调用channel.basicGet方法,主动从指定队列中拉取消息。推模式:消息中间件主动将消息推送给消费者拉模式:消费者主动从消息中间件拉取消息推模式(push)1:推模式接收消息是最有效的一种消息处理方式。channel.原创 2022-03-28 11:04:26 · 7310 阅读 · 3 评论 -
MQ线上平滑迁移方案
一、迁移的问题点:1.多生产者/多消费者切换排期跨度较大场景一: 多个生产者/一个消费者, 如何保证多个生产者不同排期切换平滑稳定过渡, 不漏消费/不重复消费场景二: 一个生产者/多个消费者, 如何保证多个消费者不同排期切换平滑稳定过渡, 不漏消费/不重复消费2.消费端消费不幂等, 不能接受重复发送/消费场景一: 如果一个生产者/多个消费者这种场景, 消费者切换排期不一致.3、广播模式的消费如何保证不漏消费/重复消费4、迁移过程中需要增量上线的MQ消息如何处理二、生产迁移顺序原创 2022-03-11 08:33:09 · 1071 阅读 · 0 评论 -
RabbitMQ高级特性整理
RabbitMQ的高级特性整理如下: 参考:朱忠华老师的著作:Rabbit实战指南channel参数mandatory设置为true,当消息没有找到任何队列的时候,可以返回给客户端。 备份交换机(AE)的设置、避免消息丢失。AE和mandatory同时存在的时候、只有AE生效 DLX (dead-letter-exchange)死信交换器,死信队列进入条件:消息被拒绝(basic.reject/basic.Nack)并且设置request参数为false 消息过期...原创 2022-03-01 11:41:58 · 1734 阅读 · 0 评论 -
Kafka原理分析
在基础篇中我们介绍MQ的一些基础原理:这篇文章,我们针对kafka进行较深入的分析:上篇文章中我们提到了kafka中一个名词broker,其实broker可以理解成为一台kafa服务器。kafka的特性和功能:在kafka设计之初是为了实时计算大数据量的场景:例如:运营活动场景:记录用户的浏览、搜索、点击、活跃度等行为。 系统运维场景:监控服务器的 CPU、内存、请求耗时等性能指标。Kafka 从0.8 版本开始,就已经在提供一些和数据处理有关的组件了,比如:1、Kafka..原创 2021-09-05 11:18:10 · 382 阅读 · 0 评论 -
Kafka原理分析基础篇
我们都知道Kafka我们平时开发中使用比较多也是比较成数的消息中间件之一。消息中间件MQ,在我们理解kafka之前,我们先来了解下MQ:MQ是什么. MQ给我们带来的好处. 如何设计一个简单的MQ.一:MQ简述MQ:简单来说就是一个生产者用于生产消息、一个消费者用于消费消息、一个消息队列用于存放消息。其中有两个关键的信息:1.消息:消息就是值我们可以按照自己的约定生产者封装成一个对象或者是一个json的字符串。消费者,能按照预定比如:序列化出对象或者解析json数据,在MQ中都可以原创 2021-09-02 22:43:00 · 89 阅读 · 0 评论