来源：大数据与机器学习文摘本文约4000字，建议阅读10+分钟本文介绍了大数据分析Pulsar的好用之处。 本文内容节选自InfoQ： https://www.infoq.cn/article/1UaxFKWUhUKTY1t_5gPq 在用户选择一个消息系统时，消息模型是用户首先考虑的事情。消息模型应涵盖以下 3 个方面： 消息消费——如何发送和消费消息； 消息确认（ack）——如何确认消息； 消息保存——消息保留多长时间，触发消息删除的原因以及怎样删除； 消息消费模型 在实时流式架构中，消息传递可以分为
大致的意思就是，这是一个实时数据处理系统，可以横向扩展、高可靠，而且还变态快，已经被很多公司使用。
Kafka 是对分区进行读写的，对于每一个分区的消费，都有一个 offset 代表消息的写入分区时的位置，consumer 消费了数据之后，每隔一段时间，会把自己消费过的消息的 offset 提交一下。表示已记录当当前的消费位置，从这里开始消费。
今天我们通过一篇文章来认识一下常见消息队列RabbitMQ、RocketMQ、Kafka。
**文末尾有思维导图**，文字就是思维导图的内容，如果不想看着，**可以直接拉到末尾，查看思维导图！**
文末尾有思维导图，文字就是思维导图的内容，如果不想看着，可以直接拉到末尾，查看思维导图！
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为这问题通常不是 MQ 自己保证的，是由我们开发来保证的。挑一个 Kafka 来举个例子，说说怎么重复消费吧。
Kafka 由一个或多个节点组成的工作集群，这些节点可以位于不同的数据中心，我们可以在 Kafka 集群的不同节点之间分布数据/负载，并且它天生具有可扩展性、可用性和容错性。
其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题。
消息队列和事件流是事件驱动架构的关键组成部分，但它们究竟有何异同？在什么情况下应选择它们的哪一个？
一，流式平台介绍 1，一般来说一个通用的流平台必须具备以下三个重要的能力： 1),能够允许你订阅和发布流式消息。在这方面，它类似于消息队列或企业消息系统。 2),它允许您以容错方式存储流式消息。 3),他可以允许你实时处理流式消息。 2，Kafka常被用于两大类应用程序： 1),构建可在系统或应用程序之间可靠获取数据的实时流数据流水线 2),构建对数据流进行变换处理的实时流应用程序 3，首先介绍一些基本概念： 1),kafka是以集群的方式运行，可以有一个或者多个Broker server。 2),kafk
MQ全称为Message Queue-消息队列，是一种应用程序对应用程序的消息通信，一端只管往队列不断发布信息，另一端只管往队列中读取消息，发布者不需要关心读取消息的谁，读取消息者不需要关心发布消息的是谁，各干各的互不干扰。
在这一部分中，我们将探讨RabbitMQ和Apache Kafka以及它们的消息传递方法。每种技术在设计的每个方面都做出了截然不同的决定，每种方面都有优点和缺点。我们不会在这一部分得出任何有力的结论，而是将其视为技术的入门，以便我们可以深入探讨该系列的后续部分。
导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀，与广泛开发者互启迪共成长。本文作者是腾讯后端开发工程师刘国强。 使用kafka可以对系统解耦、流量削峰、缓冲，可以实现系统间的异步通信等。在活动追踪、消息传递、度量指标、日志记录和流式处理等场景中非常适合使用kafka。这篇文章主要介绍下kafka中的基本概念。 kafka的整体结构 下图展示了很多关于kafka的细节，暂时
引入消息中间件也会带来很多问题，先说说消息丢失，生产者往消息队列发送消息，消息队列往消费者发送消息，会有丢消息的可能，消息队列也有可能丢消息，通常MQ存盘时都会先写入操作系统的缓存页中，然后再由操作系统异步的将消息写入硬盘，这个中间有个时间差，就可能会造成消息丢失，如果服务挂了，缓存中还没有来得及写入硬盘的消息就会发生消息丢失。不同的消息中间件对于消息丢失也有不同的解决方案，先说说最容易丢失消息的kafka吧。生产者发消息给Kafka Broker：消息写入Leader后，Follower是主动与Leader进行同步，然后发ack告诉生产者收到消息了，这个过程kafka提供了一个参数，request.required.acks属性来确认消息的生产，0表示不进行消息接收是否成功的确认，发生网络抖动消息丢了，生产者不校验ACK自然就不知道丢了。1表示当Leader接收成功时确认，只要Leader存活就可以保证不丢失，保证了吞吐量，但是如果leader挂了，恰好选了一个没有ACK的follower，那也丢了。-1或者all表示Leader和Follower都接收成功时确认，可以最大限度保证消息不丢失，但是吞吐量低，降低了kafka的性能。一般在不涉及金额的情况下，均衡考虑可以使用1，保证消息的发送和性能的一个平衡。Kafka Broker 消息同步和持久化：Kafka通过多分区多副本机制，可以最大限度保证数据不会丢失，如果数据已经写入系统缓存中，但是还没来得及刷入磁盘，这个时候机器宕机，或者没电了，那就丢消息了，当然这种情况很极端。Kafka Broker 将消息传递给消费者：如果消费这边配置的是自动提交，万一消费到数据还没处理完，就自动提交offset了，但是此时消费者直接宕机了，未处理完的数据丢失了，下次也消费不到了。所以为了避免这种情况，需要将配置改为，先消费处理数据，然后手动提交，这样消息处理失败，也不会提交成功，没有丢消息。
在Apache Kafka简介的前半部分，您使用Kafka开发了几个小规模的生产者/消费者应用程序。从这些练习中，您应该熟悉Apache Kafka消息传递系统的基础知识。在下半部分，您将学习如何使用分区来分布负载并横向扩展应用程序，每天处理多达数百万条消息。您还将了解Kafka如何使用消息偏移来跟踪和管理复杂的消息处理，以及如何在消费者失败时保护您的Apache Kafka消息传递系统免于失败。我们将从第1部分开发用于发布 - 订阅和点对点用例的示例应用程序。
对于这个学派的新手来说，我会尝试用非常简单的方式去解释。基于海量写入的扇出架构尝试在写入时使用所有业务逻辑。初衷是为了给每个用户及用例准备好视图；当有人想要读取数据时，他们不必应用复杂的逻辑。于是读取就会变得轻松简单且通常可以保证恒定的读取时间。Twitter就基于海量写入的扇出架构。
应用场景，消息可靠投递，消息丢失，消息重复消费，消息的幂等性，消息的顺序性，消息队列积压，延迟队列，消息过期失效，消息队列的高可用
我们在使用消息队列的过程中经常有业务场景需要严格保证消息的消费顺序，比如我们同时发了 2 个消息，这 2 个消息对应的操作分别对应的数据库操作是：
Apache kafka is a distributed streaming platform，官方定义 kafka 是一个分布式流式计算平台 。而在大部分企业开发人员中，都是把 kafka 当成消息系统使用，它是一个分布式消息队列，但是很少会使用 kafka 的流式计算。它有四个关键概念：
发布/ 订阅系统 是 Web 系统中比较常用的一个功能。简单点说就是 发布者发布消息，订阅者接受消息，这有点类似于我们的报纸/ 杂志社之类的： (借用前边的一张图)
便于大家对本章内容的理解，我重新整理了一下Kafka中的部分重要概念，以表格的方式呈现出来，请见下表所示：
CAP 定理是分布式架构设计的基本理论，本身并不复杂。 是由三个单词组成，分别是：
这个错误的意思是，消费者在处理完一批poll的消息后，在同步提交偏移量给broker时报的错。初步分析日志是由于当前消费者线程消费的分区已经被broker给回收了，因为kafka认为这个消费者死了，那么为什么呢？
我大学的时候英语6级没过,因此但凡懂点英语的同学,如果你进到此页面,尽量去阅读原文,链接在下方原文地址.最次也要对照着原文阅读,以免我出了什么差错(这是不可避免的),坑了别的小伙伴.
本文翻译自国外论坛 medium，原文地址：https://betterprogramming.pub/rabbitmq-vs-kafka-1779b5b70c41
重平衡跟消费组紧密相关，它保证了消费组成员分配分区可以做到公平分配，也是消费组模型的实现，消费组模型如下：
今天我们来聊聊 Kafka ，主要是带你重新认识一下 Kafka，聊一下 Kafka 中比较重要的概念和问题。在后面的文章中我会介绍：
日常开发中，相信大家都对 Kafka 有所耳闻，Kafka 作为一个分布式的流处理平台，一般用来存储和传输大量的消息数据。在 Kafka 中有三个重要概念，分别是 topic、partition 和 offset。
最近mq越来越火，很多公司在用，很多人在用，其重要性不言而喻。但是如果我让你回答下面的这些问题：
什么是Kafka Apache Kafka是一个基于分布式日志提交机制设计的发布订阅系统。数据在kafka中持久化，用户可以随时按需读取。另外数据以分布式的方式存储，提高容错性，易于扩展。 Message和Batches Kafka中最基本的数据单元是消息message，如果使用过数据库，那么可以把Kafka中的消息理解成数据库里的一条行或者一条记录。消息是由字符数组组成的，kafka并不关系它内部是什么，索引消息的具体格式与Kafka无关。消息可以有一个可选的key，这个key也是个字符数组，与消息
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。
Client和Server之间的通讯，是通过一条简单、高性能并且和开发语言无关的TCP协议。并且该协议保持与老版本的兼容。Kafka提供了Java Client（客户端）。除了Java客户端外，还有非常多的其它编程语言的客户端。
Client和Server之间的通讯，是通过一条简单、高性能并且和开发语言无关的TCP协议。并且该协议保持与老版本的兼容。Kafka提供了Java Client（客户端）。除了Java Client外，还有非常多的其它编程语言的Client。
在过去的一年里，我一直是负责Wix的事件驱动消息基础设施（基于Kafka之上）的数据流团队的一员。该基础设施被 1400 多个微服务使用。 在此期间，我已经实现或目睹了事件驱动消息传递设计的几个关键模式的实现，这些模式有助于创建一个健壮的分布式系统，可以轻松处理不断增长的流量和存储需求。
Kafka发布订阅的对象是主题（Topic），可为每个业务、每个应用甚至是每类数据都创建专属的主题。
之前已经出过MQ系列相关的对线面试官，为方便小伙伴们能够通篇阅读更加方便，此篇文章均出自对线面试官系列。往期文章参考：
消息重复和幂等问题是很常见的问题，这俩问题基本可以放在一起。 既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题即实际生产上的系统设计问题。
Java面试总结汇总，整理了包括Java基础知识，集合容器，并发编程，JVM，常用开源框架Spring，MyBatis，数据库，中间件等，包含了作为一个Java工程师在面试中需要用到或者可能用到的绝大部分知识。欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，在此表示感激不尽。文章持续更新中…
在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。
解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
Kafka （该论文发表于 2011 年 6 月 [1]）是日志处理和消息队列系统的集大成者。较低的延迟、极高的容量和吞吐，使其可以应用于在线服务和离线业务。为了兼顾性能和可扩展性，Kafka 做了一些看起来反直觉但是却很实用的设计。例行总结一下其设计特点：
大家好，我是武哥。这是《吃透 MQ 系列》的第三篇，有关 Kafka 的架构设计。
领取专属 10元无门槛券
手把手带您无忧上云
