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.点对点模型

点对点模用于 消息生产者 和 消息消费者 之间 点到点 的通信，包含三个角色：

• 消息队列（Queue）
• 发送者(Sender)
• 接收者(Receiver)

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在 内存 中也可以 持久化，直到他们被消费或超时。

特点

• 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
• 发送者和接收者之间在时间上没有依赖性
• 接收者在成功接收消息之后需向队列应答成功

2.发布订阅消息模型Topic

发布订阅模型包含三个角色：

• 主题（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消息队列有哪些

那么目前在业界有哪些比较知名的消息引擎呢？如下图所示：

这里面几乎完全列举了当下比较知名的消息引擎，包括：

1. ZeroMQ
2. 推特的Distributedlog
3. ActiveMQ：Apache旗下的老牌消息引擎
4. RabbitMQ、Kafka：AMQP的默认实现。
5. RocketMQ
6. Artemis：Apache的ActiveMQ下的子项目
7. Apollo：同样为Apache的ActiveMQ的子项目的号称下一代消息引擎
8. 商业化的消息引擎IronMQ
9. 以及实现了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功能，在大数据领域的实时计算以及日志采集被大规模使用

缺点：

1. Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
2. 使用短轮询方式，实时性取决于轮询间隔时间；
3. 消费失败不支持重试；
4. 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
5. 社区更新较慢；

3.RabbitMQ

RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

 

RabbitMQ优点：

1. 由于erlang语言的特性，mq 性能较好，高并发；
2. 吞吐量到万级，MQ功能比较完备
3. 健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
4. 开源提供的管理界面非常棒，用起来很好用
5. 社区活跃度高；

RabbitMQ缺点：

1. erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护。
2. RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
3. 需要学习比较复杂的接口和协议，学习和维护成本较高。

4.RocketMQ

RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。

RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

 

RocketMQ优点：

1. 单机吞吐量：十万级
2. 可用性：非常高，分布式架构
3. 消息可靠性：经过参数优化配置，消息可以做到0丢失
4. 功能支持：MQ功能较为完善，还是分布式的，扩展性好
5. 支持10亿级别的消息堆积，不会因为堆积导致性能下降
6. 源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控

RocketMQ缺点：

1. 支持的客户端语言不多，目前是java及c++，其中c++不成熟；
2. 社区活跃度一般
3. 没有在 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做。