我们在上篇文章中，详细说明了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架构交流学习圈：874811168、面向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，又会是另一番折腾了。
网友评论