第一个特性很好理解，我们可以用kafka去发消息和接受消息，做一个广播，这个很多工具都可以做到，redis也支持，自己实现也可以，但是kafka强大在他的高可用高性能和可靠性。 第二点，kafka他自己有个参数，log.retention.hours，日志删除的时间阈值（小时为单位），默认是168小时，也就是七天，这七天内的消息，你都可以重新消费到，也可以确定从何处开始消费。 第三点，kafka利用Kafka Streams，我们可以对kafka消息流进行处理，比如有一些要对消息进行特殊格式化或者过滤的场景，利用kafka的库类可以轻松实现。go也有goka这个包支持流式操作。 而分布式，Kafka作为一个集群，运行在一台或者多台服务器上.
Producer、Consumer、Consumer Group、Topic、Partition
传统的消息传递模式有2种：队列( queue) 和（publish-subscribe）
Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件，类似于LinkedIn的Kafka，具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用 于大吞吐量、顺序消息、广播和日志数据传输等场景，在淘宝和支付宝有着广泛的应用，现已开源。
1.Producer ：消息生产者，就是向kafka broker发消息的客户端。
在大数据和实时流处理的领域，Apache Kafka凭借其高性能、高吞吐量和可扩展性，成为了业界广泛使用的分布式消息队列系统。然而，在诸多应用场景中，消息的顺序性往往是一个至关重要的需求。无论是金融交易、日志记录还是其他需要精确时间线的业务场景，消息的顺序消费都显得尤为关键。
支付宝是属于第三方支付平台，是蚂蚁集团 旗下的支付平台系统，支付宝也是中国支付行业的一个标兵，无论是业务能力还是产品创都引领者中国支付行业的前沿，作为支付业务的基础系统的复杂性和稳定性是支付业务是否能够及时快速安全处理的根本。
Hyperledger Fabric推荐Kafa用于生产环境。Kafa是一个分布式、具有水平伸缩能力、崩溃容错能力 的日志系统。在Hyperledger Fabric区块链中可以有多个Kafka节点，使用zookeeper进行同步管理。 本文将介绍Kfaka的基本工作原理，以及在Hyperledger Fabric中使用Kafka和zookeeper实现共识的原理，并通过一个实例剖析Hyperledger Farbic中Kafka共识的达成过程。
（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。 （2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。
Kafka是当前分布式系统中最流行的消息中间件之一，凭借着其高吞吐量的设计，在日志收集系统和消息系统的应用场景中深得开发者喜爱。本篇就聊聊Kafka相关的一些知识点。主要包括以下内容：
Apache kafka is a distributed streaming platform，官方定义 kafka 是一个分布式流式计算平台 。而在大部分企业开发人员中，都是把 kafka 当成消息系统使用，它是一个分布式消息队列，但是很少会使用 kafka 的流式计算。它有四个关键概念：
一，流式平台介绍 1，一般来说一个通用的流平台必须具备以下三个重要的能力： 1),能够允许你订阅和发布流式消息。在这方面，它类似于消息队列或企业消息系统。 2),它允许您以容错方式存储流式消息。 3),他可以允许你实时处理流式消息。 2，Kafka常被用于两大类应用程序： 1),构建可在系统或应用程序之间可靠获取数据的实时流数据流水线 2),构建对数据流进行变换处理的实时流应用程序 3，首先介绍一些基本概念： 1),kafka是以集群的方式运行，可以有一个或者多个Broker server。 2),kafk
每个分区日志记录是顺序的, 不可变的串行offset, 追加到结构化的commit log, 每个offset 在分区中唯一标识一条记录
Client和Server之间的通讯，是通过一条简单、高性能并且和开发语言无关的TCP协议。并且该协议保持与老版本的兼容。Kafka提供了Java Client（客户端）。除了Java客户端外，还有非常多的其它编程语言的客户端。
流式应用特性就是流处理，通过kafka stream topic和topic之间内部转换。简单理解就是：
Client和Server之间的通讯，是通过一条简单、高性能并且和开发语言无关的TCP协议。并且该协议保持与老版本的兼容。Kafka提供了Java Client（客户端）。除了Java Client外，还有非常多的其它编程语言的Client。
消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上, 队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。常用的消息队列技术是 Message Queue。
提到Kafka很多人的第一印象就是它是一个消息系统，但Kafka发展至今，它的定位已远不止于此，而是一个分布式流处理平台。对于一个流处理平台通常具有三个关键能力：
比如，有100条有序数据，生产者发送到kafka集群，kafka的分片有4个，可能的情况就是一个分片保存0-25，一个保存25-50......这样消息在kafka中存储是局部有序了。严格说，kafka是无法保证全局消息有序的，没有这个机制，只能局部有序。
在Kafka中，每一个客户端和服务器的连接都以一种简单的，高性能的，语言无关的TCP协议完成。这个协议的版本能够向后维护来兼容旧版本。我们提供了一个Java客户端，但是客户端其实在很多语言中都可用。
为了理解Kafka是如何做到以上所说的功能，从下面开始，我们将深入探索Kafka的特性。
这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！
这是[码哥]Kafka 系列文章的第二篇，码哥将从原理、实践和源码角度为大家深入剖析并实践 Kafka。此系列包括[原理篇]、[实践篇]和[源码篇]。这篇是[原理篇]的第二篇，主要讲解 Kafka 的架构和实现原理。
Apache Kafka 是一款开源的消息系统。可以在系统中起到“肖峰填谷”的作用，也可以用于异构、分布式系统中海量数据的异步化处理。 系统包括四个主要API:
在Kafka中，客户端和服务器之间的通信是通过一种简单的，高性能的，语言不可知的TCP协议完成的。
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题，具有高扩展性、可恢复性、送达保证、顺序保证等特点，可以实现高性能、高可用、可伸缩和最终一致性架构。目前在生产环境，使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ、Redis等。
对于这个学派的新手来说，我会尝试用非常简单的方式去解释。基于海量写入的扇出架构尝试在写入时使用所有业务逻辑。初衷是为了给每个用户及用例准备好视图；当有人想要读取数据时，他们不必应用复杂的逻辑。于是读取就会变得轻松简单且通常可以保证恒定的读取时间。Twitter就基于海量写入的扇出架构。
今天我们来深入讲解 Kafka 的架构和实现原理。将从架构和细节入手，以生动的图深入讲解 Kafka 的实现原理。
kafka学习之路（一）——入门 Kafka学习之路... 一、入门.. 1、 简介 2、 主题（Topics）、日志（Logs） 3、 分布式（Distribution） 4、 生产者（Producers） 5、 消费者（Consumers） 一、入门 1、简介 Kafka 是linkedin 公司用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka 集群有多个kafka 实
生产消费者模式，指的是由生产者将数据源源不断推送到消息中心，由不同的消费者从消息中心取出数据做自己的处理，在同一类别下，所有消费者拿到的都是同样的数据；订阅发布模式，本质上也是一种生产消费者模式，不同的是，由订阅者首先向消息中心指定自己对哪些数据感兴趣，发布者推送的数据经过消息中心后，每个订阅者拿到的仅仅是自己感兴趣的一组数据。这两种模式是使用消息中间件时最常用的，用于功能解耦和分布式系统间的消息通信。
这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。
MQ是一组规范。 利用这组规范可以在不同系统间传递语义准确的消息，实现松耦合的异步式数据传递。
Kafka是一个分布式的、分区的、冗余的日志提交服务。它使用了独特的设计，提供了所有消息传递系统所具有的功能。
在微服务架构中，使用REST和RPC的方式最大的问题就是请求/响应模式的通信模式可能导致服务之间调用的可用性降低，客户端与服务端需要同时在线，双方都需要知道对方的URL地址，或者服务消费者需要通过某种发现机制来定位服务实例的地址。
大家好，我是武哥。这是《吃透 MQ 系列》的第二弹，有些珊珊来迟，后台被好几个读者催更了，实属抱歉！
自Flume快速入门系列结束后，博主决定后面几篇博客为大家带来关于Kafka的知识分享作为快速入门Kafka系列的第一篇博客，本篇为大家带来的是Kafka的简单介绍。
本文将从，Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 18 个方面综合对比作为消息队列使用时的差异。
本文将从，Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 个方面综合对比作为消息队列使用时的差异。
原文链接：http://t.cn/RVDWcfe
本文将对Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ从17 个方面综合对比作为消息队列使用时的差异。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
之前有发过一篇文章聊聊如何利用redis实现多级缓存同步。有个读者就给我留言说，因为他项目的redis版本不是6.0+版本，因此他使用我文章介绍通过MQ来实现本地缓存同步，他的同步流程大概如下图
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
