Kafka消息系统基础知识索引

摘要：一些观念的修正从版本开始，的标语已经从一个高吞吐量，分布式的消息系统改为一个分布式流平台。不仅用在吞吐量高的大数据场景，也可以用在有事务要求的业务系统上，但性能较低。消息系统的作用削峰用于承接超出业务系统处理能力的请求，使业务平稳运行。

我们在《360度测试：KAFKA会丢数据么？其高可用是否满足需求？》这篇文章中，详细说明了KAFKA是否适合用在业务系统中。但有些朋友，还不知道KAFKA为何物，以及它为何存在。这在工作和面试中是比较吃亏的，因为不知道什么时候起，KAFKA似乎成了一种工程师的必备技能。

从 0.9 版本开始，Kafka 的标语已经从“一个高吞吐量，分布式的消息系统”改为"一个分布式流平台"。

Kafka不仅仅是一个队列，而且是一个存储，有超强的堆积能力。

Kafka不仅用在吞吐量高的大数据场景，也可以用在有事务要求的业务系统上，但性能较低。

Kafka不是Topic越多越好，由于其设计原理，在数量达到阈值后，其性能和Topic数量成反比。

引入了消息队列，就等于引入了异步，不管你是出于什么目的。这通常意味着业务流程的改变，甚至产品体验的变更。

上图是一些小系统的典型架构。考虑订单的业务场景，有大量的请求指向我们的业务系统，如果直接经过复杂的业务逻辑进入业务表，将会有大量请求超时失败。所以我们加入了一张中间缓冲表（或者Redis），用来承接用户的请求。然后，有一个定时任务，不断的从缓冲表中获取数据，进行真正的业务逻辑处理。

这种设计有以下几个问题：

定时任务的轮询间隔不好控制。业务处理容易延迟。

无法横向扩容处理能力，且会引入分布式锁、顺序性保证等问题。

当其他业务也需要这些订单数据的时候，业务逻辑就必须要加入到定时任务里。

当访问量增加、业务逻辑复杂化的时候，消息队列就呼之欲出了。

请求会暂存在消息队列，然后实时通过推（或者拉）的方式进行处理。
在此场景下，消息队列充当了削峰和冗余的组件。

削峰 用于承接超出业务系统处理能力的请求，使业务平稳运行。这能够大量节约成本，比如某些秒杀活动，并不是针对峰值设计容量。

缓冲 在服务层和缓慢的落地层作为缓冲层存在，作用与削峰类似，但主要用于服务内数据流转。比如批量短信发送。

解耦 项目尹始，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。

冗余 消息数据能够采用一对多的方式，供多个毫无关联的业务使用。

健壮性 消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

消息系统即然这么重要，那么除了能够保证高可用，对它本身的特性也有较高需求。大体有下面几点：

性能要高 包含消息投递和消息消费，都要快。一般通过增加分片数获取并行处理能力。

消息要可靠 在某些场景，不能丢消息。生产、消费、MQ端都不能丢消息。一般通过增加副本，强制刷盘来解决。

扩展性要好 能够陪你把项目做大，陪你到天荒地老。增加节点集群增大后，不能降低性能。

生态成熟 监控、运维、多语言支持、社区的活跃。

Kafka是一个分布式消息(存储）系统。分布式系统通过分片增加并行度；通过副本增加可靠性，kafka也不例外。我们来看一下它的结构，顺便解释一下其中的术语。

你在一台机器上安装了Kafka，那么这台机器就叫Broker，KAFKA集群包含了一个或者多个这样的实例。

负责往KAFKA写入数据的组件就叫做Producer，消息的生产者一般写在业务系统里。

发送到KAFKA的消息可能有多种，如何区别其分类？就是Topic的概念。一个主题分布式化后，可能会存在多个Broker上。

将Topic拆成多个段，增加并行度后，拆成的每个部分叫做Partition，分区一般平均分布在所有机器上。

那些消费Kafka中数据的应用程序，就叫做Consumer，我们给某个主题的某个消费业务起一个名字，这么名字就叫做Consumer Group

Connector 连接器Task，包含Source和Sink两种接口，给用户提供了自定义数据流转的可能。比如从JDBC导入到Kafka，或者将Kafka数据直接落地到DB。

Stream 类似于Spark Stream，能够进行流数据处理。但它本身没有集群，只是在KAFKA集群上的抽象。如果你想要实时的流处理，且不需要Hadoop生态的某些东西，那么这个比较适合你。

我们的消息就是写在主题里。有了多个Topic，就可以对消息进行归类与隔离。比如登录信息写在user_activity_topic，日志消息写在log_topic中。

每一个topic都可以调整其分区数量。假设我们的集群有三个Broker，那么当分区数量为1的时候，消息就仅写在其中一个节点上；当我们的分区为3，消息会根据hash写到三个节点上；当我们的分区为6，那每个节点将会有2个分区信息。增加分区可以增加并行度，但不是越多越好。一般，6-12最佳，最好能够被节点数整除，避免数据倾斜。

每个分区都由一系列有序的、不可变的消息组成，这些消息被顺序的追加。分区中的每个消息都有一个连续的序列号叫做offset。Kafka将保留配置时间内的所有消息，所以它也是一个临时存储。在这段时间内，所有的消息都可被消费，并且可以通过改变offset的值进行重复、多次消费。

Offset一般由消费者管理，当然也可以通过程序按需要设置。Offset只有commit以后，才会改变，否则，你将一直获取重复的数据。新的kafka已经将这些Offset的放到了一个专有的主题：__consumer_offsets，就是上图的紫色区域。

值得一提的是，消费者的个数，不要超过分区的个数。否则，多出来的消费者，将接收不到任何数据。

分布式系统保证数据可靠性的一个常用手段就是增加副本个数，ISR就是建立在这个手段上。

ISR全称"In-Sync Replicas"，是保证HA和一致性的重要机制。副本数对Kafka的吞吐率是有一定的影响，但极大的增强了可用性。一般2-3个为宜。

副本有两个要素，一个是数量要够多，一个是不要落在同一个实例上。ISR是针对与Partition的，每个分区都有一个同步列表。N个replicas中，其中一个replica为leader，其他都为follower, leader处理partition的所有读写请求，其他的都是备份。与此同时，follower会被动定期地去复制leader上的数据。

如果一个flower比一个leader落后太多，或者超过一定时间未发起数据复制请求，则leader将其重ISR中移除。

当ISR中所有Replica都向Leader发送ACK时，leader才commit。

Kafka的ISR的管理最终都会反馈到Zookeeper节点上。具体位置为：/brokers/topics/[topic]/partitions/[partition]/state。当Leader节点失效，也会依赖Zk进行新的Leader选举。Offset转移到Kafka内部的Topic以后，KAFKA对ZK的依赖就越来越小了。

At least once
可能会丢消息，但不不会重复

At most once
不不丢消息，但可能重复，所以消费端要做幂等

Exactly once
消息不不会丢，且保证只投递⼀一次

整体的消息投递语义需要Producer端和Consumer端两者来保证。KAFKA默认是At most once，也可以通过配置事务达到Exactly once，但效率很低，不推荐。

当生产者向leader发送数据时，可以通过request.required.acks参数来设置数据可靠性的级别：

1（默认） 数据发送到Kafka后，经过leader成功接收消息的的确认，就算是发送成功了。在这种情况下，如果leader宕机了，则会丢失数据。

0 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最低的。

-1 producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。

Cache Filesystem Cache PageCache缓存

顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

Zero-copy 零拷⻉，少了一次内存交换。

Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

传递业务消息

用户活动日志 • 监控项等

日志

流处理，比如某些聚合

Commit Log，作为某些重要业务的冗余

下面是一个日志方面的典型使用场景。

KAFKA自带压测工具，如下。

./kafka-producer-perf-test.sh --topic test001 --num- records 1000000 --record-size 1024 --throughput -1 --producer.config ../config/producer.properties

应⽤用场景 不同的应用场景有不一样的配置策略和不一样的SLA服务水准。需要搞清楚自己的消息是否允许丢失或者重复，然后设定相应的副本数量和ACK模式。

Lag 要时刻注意消息的积压。Lag太高意味着处理能力有问题。如果在低峰时候你的消息有积压，那么当大流量到来，必然会出问题。

扩容 扩容后会涉及到partition的重新分布，你的网络带宽可能会是瓶颈。

磁盘满了 建议设置过期天数，或者设置磁盘最大使用量。

log.retention.bytes

过期删除 磁盘空间是有限的，建议保留最近的记录，其余自动删除。

log.retention.hours    
log.retention.minutes    
log.retention.ms    

KafkaManager 雅虎出品，可管理多个Kafka集群，是目前功能最全的管理工具。但是注意，当你的Topic太多，监控数据会占用你大量的带宽，造成你的机器负载增高。其监控功能偏弱，不满足需求。

KafkaOffsetMonitor 程序一个jar包的形式运行，部署较为方便。只有监控功能，使用起来也较为安全。

Kafka Web Console 监控功能较为全面，可以预览消息，监控Offset、Lag等信息，不建议在生产环境中使用。

Burrow 是LinkedIn开源的一款专门监控consumer lag的框架。支持报警，只提供HTTP接口，没有webui。

Availability Monitor for Kafka 微软开源的Kafka可用性、延迟性的监控框架,提供JMX接口，用的很少。

消费端的上线下线会造成分区与消费者的关系重新分配，造成Rebalance。业务会发生超时、抖动等。

服务器扩容、缩容，节点启动、关闭，会造成数据的倾斜，需要对partition进行reassign。在kafka manager后台可以手动触发这个过程，使得分区的分布更加平均。

这个过程会造成集群间大量的数据拷贝，当你的集群数据量大，这个过程会持续数个小时或者几天，谨慎操作。

linkedin开源了其自动化管理工具cruise-control，有自动化运维需求的不妨一看。

本文是KAFKA相关的最基础的知识，基本涵盖了大部分简单的面试题。

为了达到Exactly once这个语义，KAFKA做了很多努力，努力的结果就是几乎不可用，吞吐量实在是太低了。如果你真要将“高可靠”挂在嘴上，不如做好“补偿策略”。性能不成，最终的结果可能是整体不可用；而数据丢失，仅是极端情况下的一部分小数据而已。你会如何权衡呢？

大流量下的KAFKA是非常吓人的，数据经常将网卡打满。而一旦Broker当机，如果单节点有上T的数据，光启动就需要半个小时，它还要作为Follower去追赶其他Master分区的数据。所以，不要让你的KAFKA集群太大，故障恢复会是一场灾难。启动以后，如果执行reassign，又会是另一番折腾了。