消息队列具有高性能，高可用性，高并发的特点，是后端程序员必备的技能，本文叙述常见的使用消息队列的问题和最佳实践应用场景：消息队列最常被使用的三种场景：异步处理、流量控制和服务解耦一手资料地址：RabbitMQ...G0 消费了哪些消息，G1 是不知道的，也不用知道。G0 消费过的消息，G1 还可以消费。即使 G0 积压了很多消息，对 G1 来说也没有任何影响。...为了保证消息可靠，Broker和消费者都会存在重复消息，并且按着MQTT消息的质量标准要求，我们大部分的消息队列中间件采用At least once语义，Broker无法去除重复消息，只能依靠消费者在业务层进行幂等处理从对系统的影响结果来说...比如说，对于同一条消息：“全局 ID 为 8，操作为：给 ID 为 666 账户增加 100 元”，有可能出现这样的情况：t0 时刻：Consumer A 收到条消息，检查消息执行状态，发现消息未处理过...，开始执行“账户增加 100 元”；t1 时刻：Consumer B 收到条消息，检查消息执行状态，发现消息未处理过，因为这个时刻，Consumer A 还未来得及更新消息执行状态。
对于网络通讯来说，解决丢数据最好的办法就是，消息确认机制，而rabbitmq里面是通过两个方式来保证：一种是事务机制，这个是在amqp协议层面保证的，具体操作如下所示： RabbitMQ中与事务机制有关的方法有三个...（包含消息的唯一ID）,这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会将消息写入磁盘之后发出，broker回传给生产者的确认消息中deliver-tag域包含了确认消息的序列号...尽管如此，也有可能会丢数据，特别是当rabbitmq在buffer没有写到磁盘的时候，就死掉了。...不过rabbitmq也提供了镜像队列的方式，利用主备的方式来防止消息丢掉，不过当master和salve同时挂掉的话，还是会丢数据，只不过这种同时挂掉的概率会小很多。...（笔者觉得，没有百分之百的不丢消息，只是丢消息的概率变的很低而已。）
Kafka 是一个分布式的高可用、高性能消息队列，它可以用于大规模的数据处理和流式计算场景。...在 Kafka 中丢失消息是一件非常不好的事情，因为这会导致数据的不连续性、计算结果的准确性下降等问题，从而影响到系统的功能和运行效率。...消费方问题 Kafka 的消息发布和消费是一种异步操作，消费者可能因为各种原因滞后于消息队列发布消息的速率，这就容易导致消息积压或者工作不及时。...此外，消费者处理消息异常、死亡或重新启动也可能会导致消息丢失。解决该问题的方法是在消费信息时确保足够的消费能力，并尽可能避免处理出现崩溃的情况。...总结来说，Kafka 为什么会丢失消息可能有许多原因，涉及到硬件、网络、配置、自身、消费方以及其他因素。
需求缘起 当发送方用户A发送消息给接收方用户B时，如果用户B在线，之前的文章《微信为啥不丢“在线消息”？》聊过，可以通过应用层的确认，发送方的超时重传，接收方的去重保证业务层面消息的不丢不重。...问题：如何保证可达性，上述步骤第三步执行完毕之后，第四个步骤离线消息返回给客户端过程中，服务器挂点，路由器丢消息，或者客户端crash了，那离线消息岂不是丢了么（数据库已删除，用户还没收到）？...如同在线消息的应用层ACK机制一样，离线消息拉时，不能够直接删除数据库中的离线消息，而必须等应用层的离线消息ACK（说明用户B真的收到离线消息了），才能删除数据库中的离线消息。...SMC理论：系统层面无法做到消息不丢不重，业务层面可以做到，对用户无感知。 ? 问题：假设有N页离线消息，现在每个离线消息需要一个ACK，那么岂不是客户端与服务器的交互次数又加倍了？...（2）分页拉取，先拉取计数再按需拉取，是无线端的常见优化 （3）应用层的ACK，应用层的去重，才能保证离线消息的不丢不重 （4）下一页的拉取，同时作为上一页的ACK，能够极大减少与服务器的交互次数 即时通讯系统中
1：Storm作为一个实时处理的框架，产生的消息需要快速的进行处理，比如存在消息队列ZeroMQ里面。 由于消息队列ZeroMQ是C++写的，而我们的程序是运行在JVM虚拟机里面的。...ZeroMQ的官方网址：http://zeromq.org/ 1：MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，思路起源于LinkedIn的Kafka，但并不是...MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，目前在淘宝和支付宝有着广泛的应用。...2：MetaQ概念 Producer (消息生产者) Consumer (消息消费者) Topic (消息的主题) Partition (分区) Message (消息).../killme2008/Metamorphosis 2：ZeroMQ的安装过程如下所示（首先将zeromq-2.1.7.tar.gz上传到自己的虚拟机里面，过程省略）： 然后进行解压缩操作，如下所示：
主动向client-B发送一个消息通知包，即msg:N（当然，如果client-B不在线，则消息会存储离线） 三、上述消息投递流程出现的问题 从流程图中容易看到，发送方client-A收到msg:A后，...只能说明im-server成功接收到了消息，并不能说明client-B接收到了消息。...要想实现应用层的消息可靠投递，必须加入应用层的确认机制，即：要想让发送方client-A确保接收方client-B收到了消息，必须让接收方client-B给一个消息的确认，这个应用层的确认的流程，与消息的发送流程类似...1）im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递，不丢不重 2）一个“你好”的发送，包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文 3）im系统难以做到系统层面的不丢不重...，只能做到业务层面的不丢不重 末了，微信的消息是不是这么发送的，偶不太清楚，清楚的同学可以说一说。
许多消息都会各种保证自己的产品不会丢消息或者消息丢失概率较小，但是靠谱的很少，而且消息队列丢消息排查起来是非常麻烦的，所以大多数在使用的过程中都会在上层或者下层建立一种消息核对或者应对丢失的策略。...在丢消息这方面，Kafka 算是有着不小的优势，只要去正确使用，Kafka 基本是不会产生丢失的，并且能做到精确一次处理。...Kafka 交付语义、producer中都提到了消息提交给broker中，基本就不会丢消息了，而这个不丢消息主要是依赖于broker 中的ISR机制。...ISR （in-sync replica）也就是这组与leader保持同步的replica集合，我们要保证不丢消息，首先要保证ISR的存活（至少有一个备份存活），并且消息提交成功。...，这样的吞吐量是最好的，但是对消息的也就不能保证丢了，其实常规环境对消息丢失要求没有那么严苛的环境还是可以使用的。
二，ZeroMQ框架介绍 ZeroMZeroMQ，简称"zmq"，是一种高效、开源的消息传递框架，它提供了多种消息传递模式和编程语言支持。...在ZeroMQ中，消息是通过Socket进行发送和接收的，ZeroMQ支持多种Socket类型。...举个例子，某些区块链相关的应用就基于ZeroMQ实现了消息分发机制。 2.服务端开发：ZeroMQ可以用于构建轻量级的服务架构，服务之间通过ZeroMQ通信，可以实现高可用性和可扩展性。...4.消息队列构建：ZeroMQ可以用于构建高性能的消息队列机制，多个生产者可以向一个队列发送消息，多个消费者可以从队列中取出消息进行处理。...5.实时通信：ZeroMQ可以用于构建实时通信系统，例如聊天应用、游戏服务器等，通过ZeroMQ可以进行高效的消息传递和实时状态同步。
以类似的方式使用ZeroMq，Redis切断了慢用户，重要的是要指出，这不是能够可靠地处理这种体积的消息。我们可以将他看成一个特殊点。...直觉可能告诉我们，这仅仅是吞吐量的逆，即如果吞吐量是消息/秒，延迟是秒/消息。然而，仔细看从ZeroMQ白皮书借这个形象，我们可以看到，这不是个案。 ? ...下图中： 蓝色：nanomsg 红色：ZeroMq ? 在一般情况下，我们的假设证明正确的，因为更多的消息被发送到系统中，每个消息的延迟增加。...ZeroMQ and Nanomsg 从技术上讲，nanomsg不是一个消息队列，而是一个执行socket风格的图书馆分布式消息通过各种便捷的方式。...像ZeroMQ一样，它保证消息将被原子性地传递完整和有序，但不保证它们的交付。局部的消息将无法交付，并且部分消息可能无法被交付。
2、哪些环节可能丢消息？ 3、如何确保消息不丢失？...消息生产端发送消息到 MQ 再到消息消费端需要保证消息不丢失。 所以在使用 MQ 消息队列时，需要考虑这 3 个问题： 如何知道有消息丢失？ 哪些环节可能丢消息？ 如何确保消息不丢失？...8950-34e8c321b942 /127.0.0.1 consumer-console-consumer-1152-1 利用工具：Kafka Tools 其他可见化界面工具 2、哪些环节可能丢消息...一条消息从生产到消费完成经历 3 个环节：消息生产者、消息中间件、消息消费者。 哪个环节都有可能出现消息丢失问题。...Kafka 0.11.0.0版本开始默认 unclean.leader.election.enable=false 3）消费端 消费端消息丢失场景有： 消息堆积： 几个分区的消息都没消费，就跟丢消息一样
Broker Producer Consumer Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。...acks=0，producer不等待broker的响应，效率最高，但是消息很可能会丢。 acks=1，leader broker收到消息后，不等待其他follower的响应，即返回ack。...service不直接将消息发送到buffer（内存），而是将消息写到本地的磁盘中（数据库或者文件），由另一个（或少量）生产线程进行消息发送。...commit过程和消费消息的过程是异步的。也就是说，可能存在消费过程未成功（比如抛出异常），commit消息已经提交了。此时消息就丢失了。...也可以采用Low level API的方式，手动控制offset，也可以保证消息不丢，不过会更加复杂。
最近要为公司的消息队列中间件进行选型，市面上相关的开源技术又非常多，如ActiveMQ、RabbitMQ、ZeroMQ、Kafka，还有阿里巴巴的RocketMQ等。 这么多技术，如何进行选型呢？...所以只能在ActiveMQ、RabbitMQ、ZeroMQ、Kafka中间选一款作为消息队列中间件。...2、消息持久化 ZeroMq不支持消息持久化，ActiveMQ和RabbitMQ都支持。...3、核心技术 可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。 RabbitMq / Kafka最好，ActiveMQ次之，ZeroMQ最差。...当然ZeroMQ也可以做到，不过自己必须手动写代码实现，工作量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
通过《基于TimeLine模型的消息同步机制》一文，我们了解到Timeline模型有非常多的优点，也是钉钉采用的消息同步机制。实际工作中，我们也将该模型应用在了C端用户的消息场景中。...图中的例子中，消息发送方是A，消息接收方是B，同时B存在多个接收端，分别是B1、B2和B3。A向B发送消息，消息需要同步到B的多个端，待同步的消息通过一个Timeline来进行交换。...每个接收端同步完毕后，都会在本地记录下最新同步到的消息的msgid，即最新的一个位点，作为下次消息同步的起始位点。 二、丢失消息的原因 理论上讲，Timeline模型能够确保消息不重不漏。...实际实施中，根据系统架构特点以及选用中间件的不同，极端情况下，可能出现丢消息。最主要的原因是某一时刻，Timeline中的数据不连续或不完整。...但是对于群消息，极端情况下还是可能出现时序问题（当然要丢消息还需要客户端正好执行Sync同步，这个概率极低） 2、客户端补偿 服务端为Timeline中的每条消息都进行严格递增编号，叫做sequenceid
如果使用线程池的方式去提升如何保证重启时消息不丢。 这个题其实问了两个点，第一个是如何提升消费能力，第二个是如果选择线程池，我们如何做到消息不丢。...这里先解释一下这两个问题到底是怎么回事，在很多消息队列中都有一个概念叫partion，代表着分区，分区是我们提高消息队列消费的关键，我们的消费者消费的渠道就是从每个分区中来的，一个分区只能被一个消费者持有...有点类似银行排队，队列的个数越多，排队的时间相对来说就会越少，当然也可以通过异步的方式去处理，比如线程池，把所有的消息都扔到线程池中去执行，这就引出了作者说的第二个问题，首先我们来看看同步消费为什么不会丢消息呢...如果这样做的话，这个时候重启，kafka就会认为你已经处理了10，11的消息，这个时候消息就会出现丢失，而发这个帖子的同学就是对于这一块是比较疑惑。...最后 这里只是简单的对消息队列提升消息能力做了一些介绍，如果大家对消息队列有兴趣的，可以看我之前的一些文章： 你必须要知道的kafka 你应该知道的RocketMQ 深入理解RocketMq普通消息和顺序消息使用
目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。...（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性） （2）扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。...ZeroMQ只是一个网络编程的Pattern库，将常见的网络请求形式（分组管理，链接管理，发布订阅等）模式化、组件化，简而言之socket之上、MQ之下。...RabbitMQ/Kafka/ZeroMQ 都能提供消息队列服务，但有很大的区别。...ZeroMQ 和 RabbitMQ/Kafka 不同，它只是一个异步消息库，在套接字的基础上提供了类似于消息代理的机制。使用 ZeroMQ 的话，需要对自己的业务代码进行改造，不利于服务解耦。
前言 上一篇介绍的ISR的不丢消息的种种备份及冗余机制的所有的核心逻辑都是围绕着HW值、LEO值来展开的，如何合理的更新和存储显得尤为重要。...什么意思呢，就是说当按照参数标准成功完成消息备份（成功同步给follower replica后）才会更新HW的值，代表消息理论上已经不会丢失，可以认为“已提交”。...local LEO更新： 本地LEO值，是依赖于实际消息的消息写入来更新的，follower发送FETCH请求并得到leader的数据响应时，每当一条消息写入底层日志成功那么local LEO就+1。...消息成功保存后才完成状态的更新从而保证消息不会丢失。...ISR新老版本的消息同步策略基本都在这里了，大家对于整个消息的保存策略、内部消息同步策略、消息交付语义的保证应该有了一定程度上的认知啦。
很可惜，ZeroMQ 并非严格意义上的 at least once 或者 at most once，以其 Pub/Sub 模式来说，ZeroMQ 构建了消息确认和重传机制，却未对消息进行持久化，那么内存耗尽或者进程崩溃都会造成消息丢失...讲到消息重传，细心的同学可能会疑虑：TCP 内建有重传机制，为何 ZeroMQ 在消息层面还要多此一举？...这是因为 TCP 的重传只保证了网络层面报文的重传，而 ZeroMQ 通过消息层面的重传，保证了一个消息一旦送达，一定是完整送达。...比如说这些场景： 各种网络拓扑下的 heart beat（当然，大部分场合下 heart beat 可以直接用 IP/UDP，不必使用 messaging），偶尔丢几个消息无关痛痒 密集的 status...消息通讯的模式 搞定了一些基础知识后，我们看 ZeroMQ 涉及到的一些消息通讯的模式。 REQ/REP ? REQ/REP 是最基本的模式。客户端发送数据请求服务器的响应。 PUB/SUB ?
Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。...acks=0，producer不等待broker的响应，效率最高，但是消息很可能会丢。 acks=1，leader broker收到消息后，不等待其他follower的响应，即返回ack。...service不直接将消息发送到buffer（内存），而是将消息写到本地的磁盘中（数据库或者文件），由另一个（或少量）生产线程进行消息发送。...commit过程和消费消息的过程是异步的。也就是说，可能存在消费过程未成功（比如抛出异常），commit消息已经提交了。此时消息就丢失了。...也可以采用Low level API的方式，手动控制offset，也可以保证消息不丢，不过会更加复杂。
其中很重要的一点“如何保证用户消息有序、不丢、不重”我们没有做过多的解释。本文我们分析下如何保证协作编辑的场景下，消息 「有序」 「不丢」 「不重」 。 我们用上图中的三个阶段来描述消息广播的过程。...阶段三中，如果消息推送失败会阻碍后面所有的环节。 消息不丢 阶段一 阶段一中，出现任何保存失败的情况（比如：数据库修改失败、偶发的断网等），都实时反馈给当前用户保存失败就可以了。后续流程不再进行。...不过Kafka也支持配置每一条消息都落入磁盘，这种情况下可以做到消息不丢，但是系统的吞吐量和实效性都受到很大影响。...阶段二中Kafka本身可以设置允许消息重复的次数，如果设置成永远不重复，那丢失消息的概率会变大。 根据 「SMC定理」 ，消息不丢、不重是不可能的。...我们为了不丢消息必然会有重复发送的消息，所以客户端在接收推送消息时，要能处理重复消息。处理重复消息的前提每一条消息需要有唯一标识。
里发送消息，但另一个Module没有取到该消息。...测试程序简介 原理：向消息队列（Queue）中发送一定量的消息，看能否全部取到。如可全部取到，则可认为消息队列基本可靠，问题出在我们自己身上。...过程： 首先建立一个消息队列（Queue），程序使用Azure .Net SDK实现向Queue发送和接受消息（接收到消息后会调用方法在Queue中删除此消息，删除成功，则视为接收成功）。 ...线程2负责不断地从Queue中取消息，取到消息到本地后，即删除在Queue中的此消息。取到消息并成功删除视为成功取到消息，计数器+1。 日志模块： 使用Log4net记录日志 二....，发消息时，message id有重复的可能，导致可能会丢信。
领取专属 10元无门槛券
手把手带您无忧上云
