阿里大牛带你从Kafka到RabbitMQ 、Hbase 实战核

Kafka 概念

Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由 LinkedIn 公司开发，使用 Scala 语言编写，目前是 Apache 的开源项目。

1. broker：Kafka 服务器，负责消息存储和转发

2. topic：消息类别，Kafka 按照 topic 来分类消息

3. partition：topic 的分区，一个 topic 可以包含多个 partition，topic 消息保存在各个

partition 上

4. offset：消息在日志中的位置，可以理解是消息在 partition 上的偏移量，也是代表该消息的

唯一序号

5. Producer：消息生产者

6. Consumer：消息消费者

7. Consumer Group：消费者分组，每个 Consumer 必须属于一个 group

8. Zookeeper：保存着集群 broker、topic、partition 等 meta 数据；另外，还负责 broker 故障发现，partition leader 选举，负载均衡等功能 

Kafka 数据存储设计

 partition 中的每条 Message 包含了以下三个属性：offset，MessageSize，data，其中 offset 表 示 Message 在这个 partition 中的偏移量，offset 不是该 Message 在 partition 数据文件中的实13/04/2018 Page 176 of 283 际存储位置，而是逻辑上一个值，它唯一确定了 partition 中的一条 Message，可以认为 offset 是 partition 中 Message 的 id；MessageSize 表示消息内容 data 的大小；data 为 Message 的具 体内容。

数据文件分段 segment（顺序读写、分段命令、二分查找）

partition 物理上由多个 segment 文件组成，每个 segment 大小相等，顺序读写。每个 segment 数据文件以该段中最小的 offset 命名，文件扩展名为.log。这样在查找指定 offset 的 Message 的 时候，用二分查找就可以定位到该 Message 在哪个 segment 数据文件中。

数据文件索引（分段索引、稀疏存储） 

Kafka 为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩 展名为.index。index 文件中并没有为数据文件中的每条 Message 建立索引，而是采用了稀疏存 储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以 将索引文件保留在内存中。

生产者设计 

由于消息 topic 由多个 partition 组成，且 partition 会均衡分布到不同 broker 上，因此，为了有 效利用 broker 集群的性能，提高消息的吞吐量，producer 可以通过随机或者 hash 等方式，将消 息平均发送到多个 partition 上，以实现负载均衡。

批量发送

是提高消息吞吐量重要的方式，Producer 端可以在内存中合并多条消息后，以一次请求的方式发 送了批量的消息给 broker，从而大大减少 broker 存储消息的 IO 操作次数。但也一定程度上影响 了消息的实时性，相当于以时延代价，换取更好的吞吐量。

12.1.3.3. 压缩（GZIP 或 Snappy） 

Producer 端可以通过 GZIP 或 Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后，在 Consumer 端需进行解压。压缩的好处就是减少传输的数据量，减轻对网络传输的压力，在对大 数据处理上，瓶颈往往体现在网络上而不是 CPU（压缩和解压会耗掉部分 CPU 资源）。 

消费者设计

Consumer Group 

同一 Consumer Group 中的多个 Consumer 实例，不同时消费同一个 partition，等效于队列模 式。partition 内消息是有序的，Consumer 通过 pull 方式消费消息。Kafka 不删除已消费的消息 对于 partition，顺序读写磁盘数据，以时间复杂度 O(1)方式提供消息持久化能力。

RabbitMQ 

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。

AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为 面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言 等条件的限制。

RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：

1. 可靠性（Reliability）：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

2. 灵活的路由（Flexible Routing）：在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

3. 消息集群（Clustering）：多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。

4. 高可用（Highly Available Queues）：队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

5. 多种协议（Multi-protocol）：RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT

等等。

6. 多语言客户端（Many Clients）：RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、

Ruby 等等。

7. 管理界面（Management UI）:RabbitMQ 提供了一个易用的用户界面，使得用户可以监控

和管理消息 Broker 的许多方面。

8. 跟踪机制（Tracing）:如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生 了什么。

9. 插件机制（Plugin System）:RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。 

RabbitMQ 架构

Message 

消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系

列的可选属性组成，这些属性包括 routing-key（路由键）、priority（相对于其他消息的优

先权）、delivery-mode（指出该消息可能需要持久性存储）等。

13.1.2.2. Publisher

1. 消息的生产者，也是一个向交换器发布消息的客户端应用程序。

13.1.2.3. Exchange（将消息路由给队列 ）

2. 交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。

13.1.2.4. Binding（消息队列和交换器之间的关联）

3. 绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连

接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。

13.1.2.5. Queue

4. 消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息

可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。

13.1.2.6. Connection

5. 网络连接，比如一个 TCP 连接。

13.1.2.7. Channel

6. 信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的 TCP 连接内地虚 拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这 些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所 以引入了信道的概念，以复用一条 TCP 连接。

13.1.2.8. Consumer

7. 消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。

13.1.2.9. Virtual Host

8. 虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密

环境的独立服务器域。13/04/2018 Page 181 of 283

13.1.2.10.Broker

9. 表示消息队列服务器实体。

13.1.3. Exchange 类型

Exchange 分发消息时根据类型的不同分发策略有区别，目前共四种类型：direct、fanout、

topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键，此外 headers 交换器和direct 交换器完全一致，但性能差很多，目前几乎用不到了，所以直接看另外三种类型：

13.1.3.1. Direct 键（routing key）分布：

1. Direct：消息中的路由键（routing key）如果和 Binding 中的 binding key 一致，

交换器就将消息发到对应的队列中。它是完全匹配、单播的模式。 

Fanout（广播分发） 

Fanout：每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。很像子

网广播，每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的。

topic 交换器（模式匹配） 

topic 交换器：topic 交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符：符号“#”和符号 “”。#匹配 0 个或多个单词，匹配不多不少一个单词。

Hbase

base 是分布式、面向列的开源数据库（其实准确的说是面向列族）。HDFS 为 Hbase 提供可靠的 底层数据存储服务，MapReduce 为 Hbase 提供高性能的计算能力，Zookeeper 为 Hbase 提供 稳定服务和 Failover 机制，因此我们说 Hbase 是一个通过大量廉价的机器解决海量数据的高速存 储和读取的分布式数据库解决方案。

14.1.2. 列式存储

列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。 

这里的列式存储其实说的是列族存储，Hbase 是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。为了加深对 Hbase 列族的理解，下面是一个简单的关系型数据库的表和 Hbase 数据库的表：

Hbase 核心概念 

Column Family 又叫列族，Hbase 通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。Hbase 表的创建的时候就必须指定列族。就像关系型数据库创建的时候必须指定具体的列是一样的。Hbase 的列族不是越多越好，官方推荐的是列族最好小于或者等于 3。我们使用的场景一般是 1 个列族。

14.1.3.2. Rowkey（Rowkey 查询，Rowkey 范围扫描，全表扫描）

Rowkey 的概念和 mysql 中的主键是完全一样的，Hbase 使用 Rowkey 来唯一的区分某一行的数据。Hbase 只支持 3 中查询方式：基于 Rowkey 的单行查询，基于 Rowkey 的范围扫描，全表扫描。

14.1.3.3. Region 分区

Region：Region 的概念和关系型数据库的分区或者分片差不多。Hbase 会将一个大表的数

据基于 Rowkey 的不同范围分配到不通的 Region 中，每个 Region 负责一定范围的数据访问

和存储。这样即使是一张巨大的表，由于被切割到不通的 region，访问起来的时延也很低。

14.1.3.4. TimeStamp 多版本

TimeStamp 是实现 Hbase 多版本的关键。在 Hbase 中使用不同的 timestame 来标识相同

rowkey 行对应的不通版本的数据。在写入数据的时候，如果用户没有指定对应的

timestamp，Hbase 会自动添加一个 timestamp，timestamp 和服务器时间保持一致。在

Hbase 中，相同 rowkey 的数据按照 timestamp 倒序排列。默认查询的是最新的版本，用户

可同指定 timestamp 的值来读取旧版本的数据。

14.1.4. Hbase 核心架构

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组建组成。

Client：

Client 包含了访问 Hbase 的接口，另外 Client 还维护了对应的 cache 来加速 Hbase 的

访问，比如 cache 的.META.元数据的信息。

14.1.4.2. Zookeeper：

Hbase 通过 Zookeeper 来做 master 的高可用、RegionServer 的监控、元数据的入口

以及集群配置的维护等工作。具体工作如下：

1. 通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行，如果 master 异

常，会通过竞争机制产生新的 master 提供服务

2. 通过 Zoopkeeper 来监控 RegionServer 的状态，当 RegionSevrer 有异常的

时候，通过回调的形式通知 Master RegionServer 上下限的信息

3. 通过 Zoopkeeper 存储元数据的统一入口地址。

14.1.4.3. Hmaster

master 节点的主要职责如下：

1. 为 RegionServer 分配 Region

2. 维护整个集群的负载均衡

3. 维护集群的元数据信息发现失效的 Region，并将失效的 Region 分配到正常

RegionServer 上当 RegionSever 失效的时候，协调对应 Hlog 的拆分

14.1.4.4. HregionServer

HregionServer 直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下

1. 管理 master 为其分配的 Region

2. 处理来自客户端的读写请求

3. 负责和底层 HDFS 的交互，存储数据到 HDFS

4. 负责 Region 变大以后的拆分

5. 负责 Storefile 的合并工作

14.1.4.5. Region 寻址方式（通过 zookeeper .META）

第 1 步：Client 请求 ZK 获取.META.所在的 RegionServer 的地址。

第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地

址，client 会将.META.的相关信息 cache 下来，以便下一次快速访问。

第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。

HDFS

HDFS 为 Hbase 提供最终的底层数据存储服务，同时为 Hbase 提供高可用（Hlog 存储在

HDFS）的支持。

Hbase 的写逻辑 

Hbase 的写入流程 

从上图可以看出氛围 3 步骤：

获取 RegionServer

第 1 步：Client 获取数据写入的 Region 所在的 RegionServer

请求写 Hlog

第 2 步：请求写 Hlog, Hlog 存储在 HDFS，当 RegionServer 出现异常，需要使用 Hlog 来

恢复数据。

请求写 MemStore

第 3 步：请求写 MemStore,只有当写 Hlog 和写 MemStore 都成功了才算请求写入完成。

MemStore 后续会逐渐刷到 HDFS 中。

14.1.5.2. MemStore 刷盘

为了提高 Hbase 的写入性能，当写请求写入 MemStore 后，不会立即刷盘。而是会等到一

定的时候进行刷盘的操作。具体是哪些场景会触发刷盘的操作呢？总结成如下的几个场景

全局内存控制

1. 这个全局的参数是控制内存整体的使用情况，当所有 memstore 占整个 heap 的最大比

例的时候，会触发刷盘的操作。这个参数是

hbase.regionserver.global.memstore.upperLimit，默认为整个 heap 内存的 40%。

但这并不意味着全局内存触发的刷盘操作会将所有的 MemStore 都进行输盘，而是通过

另外一个参数 hbase.regionserver.global.memstore.lowerLimit 来控制，默认是整个

heap 内存的 35%。当 flush 到所有 memstore 占整个 heap 内存的比率为 35%的时

候，就停止刷盘。这么做主要是为了减少刷盘对业务带来的影响，实现平滑系统负载的

目的。

MemStore 达到上限

2. 当 MemStore 的大小达到 hbase.hregion.memstore.flush.size 大小的时候会触发刷

盘，默认 128M 大小

RegionServer 的 Hlog 数量达到上限

3. 前面说到 Hlog 为了保证 Hbase 数据的一致性，那么如果 Hlog 太多的话，会导致故障

恢复的时间太长，因此 Hbase 会对 Hlog 的最大个数做限制。当达到 Hlog 的最大个数

的时候，会强制刷盘。这个参数是 hase.regionserver.max.logs，默认是 32 个。

手工触发

4. 可以通过 hbase shell 或者 java api 手工触发 flush 的操作。

关闭 RegionServer 触发

5. 在正常关闭 RegionServer 会触发刷盘的操作，全部数据刷盘后就不需要再使用 Hlog 恢

复数据。

Region 使用 HLOG 恢复完数据后触发

6. ：当 RegionServer 出现故障的时候，其上面的 Region 会迁移到其他正常的

RegionServer 上，在恢复完 Region 的数据后，会触发刷盘，当刷盘完成后才会提供给

业务访问。

14.1.6. HBase vs Cassandra

以上是Kafka、RabbitMQ 、Hbase 实战核心讲解知识，