Kafka、RabbitMQ、RocketMQ等消息中间件的对比
消息队列MQ概述
消息队列(Message Queue,简称MQ),指保存消息的一个容器,本质是个队列。
消息(Message)是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。
下图便是消息队列的基本模型,向消息队列中存放数据的叫做生产者,从消息队列中获取数据的叫做消费者。
消息队列MQ应用场景
1.异步处理
消息队列的主要特点是异步处理,主要目的是减少请求响应时间,实现非核心流程异步化,提高系统响应性能。
举一个用户注册的例子,用户注册成功后,系统需要发送注短信注册成功通知,以及赠送注册成功的积分。
1)同步
同步的总耗时:10ms+100ms+100ms=210ms
由于短信通知与增加积分为非核心流程,为了提升系统响应性能,从而我把它改造为异步。
2)异步
改造后就变成上图,之前需要等用户注册10ms+短信通知100ms+增加积分100ms才能返回,现在把短信通知和增加积分改为异步的形式,用户注册后写入消息10ms左右立即返回成功给客户端,无需等待耗时较久的同步(短信+积分)就可以返回,从而极大的提升了系统的吞吐量。
所以异步的典型场景就是将比较耗时而且不需要即时(同步)返回结果的操作,通过消息队列来实现异步化。
2.应用解耦
使用了消息队列后,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦。
每个成员不必受其他成员影响,可以更独立自主,只通过消息队列MQ来联系,典型的上下游解耦如下图所示:
3.流量削锋
流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛。
这种场景中系统的峰值流量往往集中于一小段时间内,所以为了防止系统在短时间内的峰值流量冲垮,往往采用消息队列来削弱峰值流量,相当于消息队列做了一次缓冲。
4日志处理
日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。
消息队列MQ设计
1. 整体架构
上图为整体架构,会涉及三类角色:
1)Producer 消息生产者:负责产生和发送消息到 Broker;
2)Broker 消息处理中心:负责消息存储、确认、重试等,一般其中会包含多个 queue;
3)Consumer 消息消费者:负责从 Broker 中获取消息,并进行相应处理;
2.详细设计
详细的流程如上图,producer发送给broker,broker发送给consumer,consumer回复消费确认,broker删除/备份消息等。
1)RPC 通信
图上的第一个步骤:Producer生产消息向Broker发送会涉及到通信的问题,同样Consumer 消费消息也会涉及到通信的问题。
上图中的Producer,Broker,Consumer最后就通过RPC将数据流串起来了,所以需要解决通信的问题。
你可以基于Netty 来做底层通信,用 Zookeeper、Euraka 等来做注册中心,然后自定义一套新的通信协议。
也可以直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 实现即可,这样不需要考虑服务注册与发现、负载均衡、通信协议、序列化方式等一系列问题了。
2)Broker存储
图上第二个步骤,消息到达服务端后需要存储到Broker。
大家关注的流量削峰、最终一致性等需求都是需要Broker先存储下来,然后选择时机投递,这才达到流量削峰、泄洪的目的,所以Broker一个非常重要的功能就是存储。
存储可以做成很多方式,比如存储在内存里,存储在分布式KV里,存储在磁盘里,存储在数据库里等等,存储的选型需要综合考虑性能/高可用和开发维护成本等诸多因素。
目前主流的方案:追加写日志文件(数据部分) + 索引文件的方式,索引设计上可以考虑稠密索引或者稀疏索引,查找消息可以利用跳转表、二份查找等,还可以通过操作系统的页缓存、零拷贝等技术来提升磁盘文件的读写性能。
3)消费模型
图上第三个步骤,消息到达Broker后,最终还是需要Consumer去消费消息,这里就会涉及到到消费模型。
这里的消费模型,目前主要就两种:单播和广播。所谓单播,就是点到点;而广播,是一点对多点。
详细的单播和广播消费模型,下面我会图文详解。
4)高级特性
图上第四个步骤,如果Consumer端把消息消费了,除了需要消息确认,还会涉及到比如:重复消息、顺序消息、消息延迟、事务消息等需要考虑的高级特性。
消息队列MQ模型
消息队列MQ主要包含两种模型:点对点与发布订阅两种模型。
1.点对点模型
![史上最强消息队列MQ万字图文总结!-mikechen的互联网架构 史上最强消息队列MQ万字图文总结!-mikechen的互联网架构](https://static.mikechen.cc/wp-content/uploads/2021/11/5287.png)
点对点模用于 消息生产者 和 消息消费者 之间 点到点 的通信,包含三个角色:
- 消息队列(Queue)
- 发送者(Sender)
- 接收者(Receiver)
每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,可以放在 内存 中也可以 持久化,直到他们被消费或超时。
特点
- 每个消息只有一个消费者(Consumer)(即一旦被消费,消息就不再在消息队列中)
- 发送者和接收者之间在时间上没有依赖性
- 接收者在成功接收消息之后需向队列应答成功
2.发布订阅消息模型Topic
![史上最强消息队列MQ万字图文总结!-mikechen的互联网架构 史上最强消息队列MQ万字图文总结!-mikechen的互联网架构](https://static.mikechen.cc/wp-content/uploads/2021/11/5288.png)
发布订阅模型包含三个角色:
- 主题(Topic)
- 发布者(Publisher)
- 订阅者(Subscriber)
多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
特点
- 每个消息可以有多个消费者:和点对点方式不同,发布消息可以被所有订阅者消费
- 发布者和订阅者之间有时间上的依赖性。
- 针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
- 为了消费消息,订阅者必须保持运行的状态。
消息队列MQ产品选型
1.ActiveMQ
ActiveMQ官网地址:activemq.apache.org
Apache出品,最早使用的消息队列产品,时间比较长了,最近版本更新比较缓慢,性能在万级/秒。
2.RabbitMQ
RabbitMQ官网地址:www.rabbitmq.com
RabbitMQ是erlang语言开发,结合erlang语言本身的并发优势,支持很多的协议:AMQP,XMPP, SMTP, STOMP,性能在万级/秒,其整体架构图如下所示:
3.Kafka
Kafka官网地址:kafka.apache.org
Kafka是由Apache软件基金会开发的一个开源消息系统项目,由Scala写成。Kafka最初是由LinkedIn开发,并于2011年初开源。Kafka是一个分布式的、分区的、多复本的日志提交服务,性能在百万级/秒,其整体架构图如下所示:
4.RocketMQ
RocketMQ官网地址:rocketmq.apache.org
阿里开源的消息中间件,纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点,参考Kafka而设计的,性能在十万级/秒,其整体架构图如下所示:
5.Pulsar
Pulsar官网地址:pulsar.apache.org
Apache Pulsar是Apache软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性,被看作是云原生时代实时消息流传输、存储和计算最佳解决方案,其整体架构图如下所示:
6.消息队列选型
广泛来说,电商、金融等对事务性要求很高的,可以考虑RocketMQ,技术挑战不是特别高,用 RabbitMQ 是不错的选择,如果是大数据领域的实时计算、日志采集等场景可以考虑 Kafka。
一、最全MQ消息队列有哪些
那么目前在业界有哪些比较知名的消息引擎呢?如下图所示:
这里面几乎完全列举了当下比较知名的消息引擎,包括:
- ZeroMQ
- 推特的Distributedlog
- ActiveMQ:Apache旗下的老牌消息引擎
- RabbitMQ、Kafka:AMQP的默认实现。
- RocketMQ
- Artemis:Apache的ActiveMQ下的子项目
- Apollo:同样为Apache的ActiveMQ的子项目的号称下一代消息引擎
- 商业化的消息引擎IronMQ
- 以及实现了JMS(Java Message Service)标准的OpenMQ。
二的应用
1.解耦
解耦是消息队列要解决的最本质问题。
2.最终一致性
最终一致性指的是两个系统的状态保持一致,要么都成功,要么都失败。
最终一致性不是消息队列的必备特性,但确实可以依靠消息队列来做最终一致性的事情。
2.广播
消息队列的基本功能之一是进行广播。
有了消息队列,我们只需要关心消息是否送达了队列,至于谁希望订阅,是下游的事情,无疑极大地减少了开发和联调的工作量。
3.错峰与流控
典型的使用场景就是秒杀业务用于流量削峰场景。
由于篇幅的关系,本文重点介绍消息队列比较,详细应用场景可参考我的往期文章《什么是流量消峰?如何解决秒杀业务的削峰场景》。
三、Kafka、RocketMQ、RabbitMQ比较
1.ActiveMQ
优点
- 单机吞吐量:万级
- topic数量都吞吐量的影响:
- 时效性:ms级
- 可用性:高,基于主从架构实现高可用性
- 消息可靠性:有较低的概率丢失数据
- 功能支持:MQ领域的功能极其完备
缺点:
官方社区现在对ActiveMQ 5.x维护越来越少,较少在大规模吞吐的场景中使用。
2.Kafka
号称大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。
Apache Kafka它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log),之后成为Apache项目的一部分。
目前已经被LinkedIn,Uber, Twitter, Netflix等大公司所采纳。
优点
- 性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。
- 时效性:ms级
- 可用性:非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
- 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
- 有优秀的第三方Kafka Web管理界面Kafka-Manager;
- 在日志领域比较成熟,被多家公司和多个开源项目使用;
- 功能支持:功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用
缺点:
- Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长
- 使用短轮询方式,实时性取决于轮询间隔时间;
- 消费失败不支持重试;
- 支持消息顺序,但是一台代理宕机后,就会产生消息乱序;
- 社区更新较慢;
3.RabbitMQ
RabbitMQ 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
RabbitMQ优点:
- 由于erlang语言的特性,mq 性能较好,高并发;
- 吞吐量到万级,MQ功能比较完备
- 健壮、稳定、易用、跨平台、支持多种语言、文档齐全;
- 开源提供的管理界面非常棒,用起来很好用
- 社区活跃度高;
RabbitMQ缺点:
- erlang开发,很难去看懂源码,基本职能依赖于开源社区的快速维护和修复bug,不利于做二次开发和维护。
- RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。
- 需要学习比较复杂的接口和协议,学习和维护成本较高。
4.RocketMQ
RocketMQ出自 阿里公司的开源产品,用 Java 语言实现,在设计时参考了 Kafka,并做出了自己的一些改进。
RocketMQ在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。
RocketMQ优点:
- 单机吞吐量:十万级
- 可用性:非常高,分布式架构
- 消息可靠性:经过参数优化配置,消息可以做到0丢失
- 功能支持:MQ功能较为完善,还是分布式的,扩展性好
- 支持10亿级别的消息堆积,不会因为堆积导致性能下降
- 源码是java,我们可以自己阅读源码,定制自己公司的MQ,可以掌控
RocketMQ缺点:
- 支持的客户端语言不多,目前是java及c++,其中c++不成熟;
- 社区活跃度一般
- 没有在 mq 核心中去实现JMS等接口,有些系统要迁移需要修改大量代码
四、消息队列选择建议
1.Kafka
Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。
大型公司建议可以选用,如果有日志采集功能,肯定是首选kafka了。
2.RocketMQ
天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理的情况。
RoketMQ在稳定性上可能更值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择RocketMQ。
3.RabbitMQ
RabbitMQ :结合erlang语言本身的并发优势,性能较好,社区活跃度也比较高,但是不利于做二次开发和维护。不过,RabbitMQ的社区十分活跃,可以解决开发过程中遇到的bug。
如果你的数据量没有那么大,小公司优先选择功能比较完备的RabbitMQ。
以上,是Kafka、RocketMQ、RabbitMQ的优劣势比较。
Kafka、RabbitMQ、RocketMQ等消息中间件的对比
RocketMQ
淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件,使用Mysql作为消息存储媒介,可完全水平扩容,为了进一步降低成本,我们认为存储部分可以进一步优化,2011年初,Linkin开源了Kafka这个优秀的消息中间件,淘宝中间件团队在对Kafka做过充分Review之后,Kafka无限消息堆积,高效的持久化速度吸引了我们,但是同时发现这个消息系统主要定位于日志传输,对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足,为此我们重新用Java语言编写了RocketMQ,定位于非日志的可靠消息传输(日志场景也OK),目前RocketMQ在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。
Kafka
Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ
RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。
有关测试结论
Kafka的吞吐量高达17.3w/s,不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。
RocketMQ也表现不俗,吞吐量在11.6w/s,磁盘IO %util已接近100%。RocketMQ的消息写入内存后即返回ack,由单独的线程专门做刷盘的操作,所有的消息均是顺序写文件。
RabbitMQ的吞吐量5.95w/s,CPU资源消耗较高。它支持AMQP协议,实现非常重量级,为了保证消息的可靠性在吞吐量上做了取舍。我们还做了RabbitMQ在消息持久化场景下的性能测试,吞吐量在2.6w/s左右。
在服务端处理同步发送的性能上,Kafka>RocketMQ>RabbitMQ。
对比了最简单的小消息发送场景,Kafka暂时胜出。但是,作为经受过历次双十一洗礼的RocketMQ,在互联网应用场景中更有它优越的一面。
RabbitMQ
是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了一个经纪人(Broker)构架,这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)或者数据持久化都有很好的支持。
Redis
是一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。
ZeroMQ
号称最快的消息队列系统,尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库,可以使用NuGet安装,然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列,也就是说如果down机,数据将会丢失。其中,Twitter的Storm中使用ZeroMQ作为数据流的传输。
ActiveMQ
是Apache下的一个子项目。 类似于ZeroMQ,它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ,它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
Jafka/Kafka
Kafka是Apache下的一个子项目,是一个高性能跨语言分布式Publish/Subscribe消息队列系统,而Jafka是在Kafka之上孵化而来的,即Kafka的一个升级版。具有以下特性:快速持久化,可以在O(1)的系统开销下进行消息持久化;高吞吐,在一台普通的服务器上既可以达到10W/s的吞吐速率;完全的分布式系统,Broker、Producer、Consumer都原生自动支持分布式,自动实现复杂均衡;支持Hadoop数据并行加载,对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理,这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统,除了性能非常好之外,还是一个工作良好的分布式系统。
rabbitmq比kafka可靠,kafka更适合IO高吞吐的处理,比如ELK日志收集**
Kafka和RabbitMq一样是通用意图消息代理,他们都是以分布式部署为目的。但是他们对消息语义模型的定义的假设是非常不同的。我对”AMQP 更成熟”这个论点是持怀疑态度的。让我们用事实说话来看看用什么解决方案来解决你的问题。
a) 以下场景你比较适合使用Kafka。你有大量的事件(10万以上/秒)、你需要以分区的,顺序的,至少传递成功一次到混杂了在线和打包消费的消费者、你希望能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意通过论坛/IRC工具得到还在幼儿阶段的软件的支持。
b) 以下场景你比较适合使用RabbitMQ。你有较少的事件(2万以上/秒)并且需要通过复杂的路由逻辑去找到消费者、你希望消息传递是可靠的、你并不关心消息传递的顺序、你需要现在就支持集群-节点级别的高可用或则说你需要7*24小时的付费支持(当然也可以通过论坛/IRC工具)。
redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠。
redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠。其他的mq和kafka保证可靠但有一些延迟(非实时系统没有保证延迟)。redis-pub/sub断电就清空,而使用redis-list作为消息推送虽然有持久化,但是又太弱智,也并非完全可靠不会丢。另外一点,redis 发布订阅除了表示不同的 topic 外,并不支持分组,比如kafka中发布一个东西,多个订阅者可以分组,同一个组里只有一个订阅者会收到该消息,这样可以用作负载均衡。比如,kafka 中发布:topic = “发布帖子” data=”文章1” 这个消息,后面有一百台服务器每台服务器都是一个订阅者,都订阅了这个 topic,但是他们可能分为三组,A组50台,用来真的做发布文章,A组50台里所有 subscriber 都订阅了这个topic。由于在同一组,这条消息 (topic=”发布帖子”, data=”文章1”)只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计,C组25台服务器用于存档备份,每组只有一台会收到。用不同的组来决定每条消息要抄送出多少分去,用同组内哪些订阅者忙,哪些订阅者空闲来决定消息会被分到哪台服务器去处理,生产者消费者模型嘛。redis完全没有这类机制,这两点是最大的区别。
redis是内存数据库!redis他爹做了disque,你要不要试试。mq一般都采用订阅~发布模型,如果你考虑性能,主要关注点就放在消费模型是pull还是push。影响最大的,应该是存储结构。kafka的性能要在topic数量小于64的时候,才能发挥威力。partition决定的。极限情况下丢消息,例如:主写入消息后,主机器宕机,并硬盘损坏。review代码的时候发现的。rabbit不知道,但是rocket的性能是(万条每秒),并且能够横向无限扩展,单机topic数量在256时,性能损失较小。rocket可以说是kafka的变种,是阿里在充分reviewkafka代码后,开发的metaQ。在不断更新,修补以后,阿里把metaQ3.0更名为rocket,并且rocket是java写的易于维护。另外就是rocket和kafka有类似无限堆积的能力。想想,断电不丢消息,积压两亿条消息毫无压力,niubilitykafka和rocket性能根本不是你需要考虑的问题。
在应用场景方面,
RabbitMQ,遵循AMQP协议,由内在高并发的erlanng语言开发,用在实时的对可靠性要求比较高的消息传递上。
kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。
在架构模型方面,
RabbitMQ遵循AMQP协议,RabbitMQ的broker由Exchange,Binding,queue组成,其中exchange和binding组成了消息的路由键;客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费(长连接,queue有消息会推送到consumer端,consumer循环从输入流读取数据)。rabbitMQ以broker为中心;有消息的确认机制。
kafka遵从一般的MQ结构,producer,broker,consumer,以consumer为中心,消息的消费信息保存的客户端consumer上,consumer根据消费的点,从broker上批量pull数据;无消息确认机制。
在吞吐量,
kafka具有高的吞吐量,内部采用消息的批量处理,zero-copy机制,数据的存储和获取是本地磁盘顺序批量操作,具有O(1)的复杂度,消息处理的效率很高。
rabbitMQ在吞吐量方面稍逊于kafka,他们的出发点不一样,rabbitMQ支持对消息的可靠的传递,支持事务,不支持批量的操作;基于存储的可靠性的要求存储可以采用内存或者硬盘。
在可用性方面,
rabbitMQ支持miror的queue,主queue失效,miror queue接管。
kafka的broker支持主备模式。
在集群负载均衡方面,
kafka采用zookeeper对集群中的broker、consumer进行管理,可以注册topic到zookeeper上;通过zookeeper的协调机制,producer保存对应topic的broker信息,可以随机或者轮询发送到broker上;并且producer可以基于语义指定分片,消息发送到broker的某分片上。
rabbitMQ的负载均衡需要单独的loadbalancer进行支持。
Kafka是可靠的分布式日志存储服务。用简单的话来说,你可以把Kafka当作可顺序写入的一大卷磁带, 可以随时倒带,快进到某个时间点重放。先说下日志的定义:日志是数据库的核心,是对数据库的所有变更的严格有序记录,“表”是变更的结果。日志的其他名字有: Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特征如下:高写入速度:Kafka能以超过1Gbps NIC的速度写这盘磁带(实际可以到SATA 3速度,参考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines)),充分利用了磁盘的物理特性,即,随机写入慢(磁头冲停),顺序写入快(磁头悬浮)。高可靠性: 通过zookeeper做分布式一致性,同步到任意多块磁盘上,故障自动切换选主,自愈。高容量:通过横向扩展,LinkedIn每日通过Kafka存储的新增数据高达175TB,8000亿条消息,可无限扩容,类似把两条磁带粘到一起。传统业务数据库的根本缺陷在于:1. 太慢,读写太昂贵,无法避免的随机寻址。(磁盘最快5ms寻址,固态又太昂贵。)2. 根本无法适应持续产生的数据流,越用越慢。(索引效率问题)3. 无法水平scale。(多半是读写分离,一主多备。另: NewSQL通过一致性算法,有多主。)针对这些问题,Kafka提出了一种方法: “log-centric approach(以日志为中心的方法)。”将传统数据库分为两个独立的系统,即日志系统和索引系统。“持久化和索引分开,日志尽可能快的落地,索引按照自己的速度追赶。”在数据可靠性在得到Kafka这种快速的,类似磁带顺序记录方式保障的大前提下。数据的呈现,使用方式变得非常灵活,可以根据需要将数据流同时送入搜索系统,RDBMS系统,数据仓库系统, 图数据库系统,日志分析等这些各种不同的数据库系统。 这些不同的系统只不过是一种对Kafka磁带数据的一种诠释,一个侧面,一个索引,一个快照。数据丢了,没关系,重放一遍磁带即可,更多的时候,对这些各式数据库系统的维护只是需要定期做一个快照,并拷贝到一个安全的对象存储(如S3) 而已。 一句话:“日志都是相同的日志,索引各有各的不同。”关于流计算:在以流为基本抽象的存储模型下,数据流和数据流之间,可以多流混合处理,或者流和状态,状态和状态的JOIN处理,这就是Kafka Stream提供的功能。 一个简单的例子是,在用户触发了某个事件后,和用户表混合处理,产生数据增补(Augment),再进入数据仓库进行相关性分析,一些简单的窗口统计和实时分析也很容易就能满足,比如 在收到用户登录消息的时候,在线人数+1, 离线的时候-1,反应出当前系统的在线用户总数。这方面可以参考PipelineDB https://www.pipelinedb.com/Kafka会让你重新思考系统的构建方式,使以前不可能的事变为可能,是一个系统中最重要的最核心的部分,不夸张的说,系统设计都需要围绕Kafka做。