Kafka消息系统基础知识索引消息

咱们在上篇文章中，详细说明了KAFKA是否适合用在业务系统中，但有些朋友，还不知道KAFKA为什么物，以及它为什么存在。这在工做和面试中是比较吃亏的，由于不知道何时起，KAFKA彷佛成了一种工程师的必备技能。

消息系统是什么

典型场景

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

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

1.定时任务的轮询间隔很差控制，业务处理容易延迟。

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

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

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

请求会暂存在消息队列，而后实时经过推（或者拉）的方式进行处理。

在此场景下，消息队列充当了削峰和冗余的组件。

消息系统的做用

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

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

解耦：项目尹始，并不能肯定具体需求，消息队列能够做为一个接口层，解耦重要的业务流程，只须要遵照约定，针对数据编程便可获取扩展能力。

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

健壮性：消息队列能够堆积请求，因此消费端业务即便短期死掉，也不会影响主要业务的正常进行。

消息系统要求

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

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

消息要可靠：在某些场景，不能丢消息。生产、消费、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生态的某些东西，那么这个比较适合你。Java架构交流学习圈：87481116八、面向1-3年经验、Java开发人员、帮助突破瓶颈 提高思惟能力

咱们的消息就是写在主题里。有了多个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就是创建在这个手段上。

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，但效率很低，不推荐。

ACK

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

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

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

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

KAFKA为何快

Cache：Filesystem Cache PageCache缓存

顺序写：因为现代的操做系统提供了预读和写技术，磁盘的顺序写大多数状况下比随机写内存还要快。

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

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

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

使用场景

1.传递业务消息

2.用户活动日志 • 监控项等

3.日志

4.流处理，好比某些聚合

5.Commit Log，做为某些重要业务的冗余

6.针对当前互联网公司的技术需求以及结合主流技术，我整理了一份系统的架构技术体系，但愿对在提高进阶的程序员们有所帮助。你们能够进群Java资源分享群：（854601507）下载资料，群里有阿里大牛，也有一线互联网的资深HR，或是关注微信公众号：Java资讯库，免费领取架构资料。

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

压测

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

消费端Rebalance

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

服务端reassign

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

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

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

结尾

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

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

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

原文出处：https://www.jianshu.com/p/abc10b7275d7