了解 Kafka
一、Kafka简介
Apache Kafka发源于LinkedIn，于2012年成为Apache的主要项目之一。由Scala和Java编写。Apache Kafka是一个具有高吞吐量、内置分区、支持数据副本和可容错性的分布式-发布订阅消息系统，适合在大规模消息处理场景中使用。
二、消息系统：两种消息模式
1.目前有两种类型的消息模式可用，一种是点对点，另一种是发布-订阅消息系统
1.1点对点消息系统（1对1）
在点对点系统中，消息持久化到一个队列中。 一个或多个消费者可以消费队列中的消息，但是一条消息只能被消费一次。 当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该系统的典型示例是订单处理系统，其中每个订单将由一个订单处理器处理，但多个订单处理器也可以同时工作。
1.2发布- 订阅消息系统（1对多）
在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。（kafka可以设置消息的保存策略为N天，在消息发布的N天内都是可以被消费的,N天后它将被丢弃以释放资源）在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。一个现实生活的例子是电视，它发布不同的渠道，如运动，电影，音乐等，任何人都可以订阅自己的频道集，并获得他们订阅的频道时可用。
三、kafka概述
1.Kafka的特性:
高性能：Kafka在数据发布和订阅过程中都能保证数据的高吞吐量。即便在TB级数据存储的情况下，仍然能保证稳定的性能
可扩展性：Kafka消息系统支持集群规模的热扩展（热扩展：在运行状态下扩展集群）
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败
高并发：支持数千个客户端同时读写
2.kafka的使用场景
1、消息系统
对于一些常规的消息系统,kafka是个不错的选择;partitions/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS(JMS是Java提供的一套技术规范和关于消息中间件的协议)中的"事务性""消息传输担保(消息确认机制)""消息分组"等企业级特性;kafka只能使用作为"常规"的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)
注：消息丢失情况：客户端默认情况下是自动提交offset，这样可能存在消息丢失的可能性，比如客户端接收到一批消息并进行处理，在处理过程中达到了客户端offset定时提交的时间点，这批数据的offset被提交，但是可能这批数据的处理还没有结束，甚至这些数据可能还存在一些数据处理不了或者处理出错，甚至出现宕机的可能性，这时未处理的消息将会丢失，因为offset已经提交，下次读取会从新的offset处读取。
2、用户活动跟踪
kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等
3、日志收集
kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.(hadoop:分布式文件系统，用来告诉运算和存储，它提供了高吞吐量来访问应用程序数据，适合有着超大数据集的应用程序)
四、Kafka基本概念及一些术语
1、Producer即：消息生产者，是消息的产生的源头，负责生成消息并发送到Kafka服务器上。
2、Consumer即：消息消费者，是消息的使用方，负责消费Kafka服务器上的消息。
3、Topic即：主题，Kafka将消息以topic为单位进行归纳,一个topic是对一组消息的归纳，用于建立生产者和消息者之间的订阅关系：生产者发送消息到指定的Topic下，消息者从这个Topic下消费消息。
4、Partition即: 消息分区，一个 topic可以分为多个 partition，每个 partition 是一个有序的队列。每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，分区中的每个消息都有一个连续的序列号叫做offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。分区是kafka独有的东西,也是kafka实现横向扩展和高并发的一个重要设计。将日志分区可以达到以下目的：首先这使得每个日志的数量不会太大，可以在单个服务上保存。另外每个分区可以单独发布和消费，为并发操作topic提供了一种可能。
5、Broker：即Kafka的服务器，Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务节点叫做broker.
6、ConsumerGroup即：消费者分组，用于归组同类消费者，在Kafka中，多个消费者可以共同消费一个Topic下的消息，每个消费者消费其中的部分消息，这些消费者就组成了一个分组，拥有同一个分组名称，通常也被称为消费者集群。
注：一个Consumer在某个时刻只会消费一个partition,不存在多个Consumer共同消费一个partition中的消息。(一个consumer对应一个partition)
7、Replicas of partition:即：副本，副本是一个分区的备份。副本不会被消费者消费，副本只用于防止数据丢失，即消费者不从为follower的partition中消费数据，而是从为leader的partition中读取数据。
8、Leader: 每个partition有多个副本分布到各个broker上（副本数小于等于broker数），其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
9、Follower:Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower.如果领导失败，一个追随者将自动成为新的领导者。
10、Zookeeper：是一个分布式应用程序协调服务，负责维护和协调broker。当Kafka系统中新增了broker或者某个broker发生故障失效时，由ZooKeeper通知生产者和消费者。生产者和消费者依据Zookeeper的broker状态信息与broker协调数据的发布和订阅任务。broker使用Zookeeper维护集群的状态。Leader的选举也由Zookeeper负责。实现动态的集群扩展，不需要更改客户端的配置（producer和consumer），zookeeper上保存元数据（topic,partiotions信息等，不包括发送给topic本身的数据）
11、 ISR(In-Sync Replica)：是Replicas的一个子集，是一个列表，表示目前Alive且与Leader能够“Catch-up”的Replicas集合(就是一个含符合要求的follower的集合)。由于读写都是首先落到Leader上，所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每Partition都有它自己独立的ISR。Leader会从ISR中选取。
下面举个例子，帮助我们更好的了解他们之间的关系
例：场景一: topic1 下有partition1和partition2 ，topic2下有partition3,Consumer group下有consumer1和consumer2和consumer3 ，所有consumer只有一个线程。
消费情况: consumer1只消费partition1的数据
consumer2只消费partition2的数据
consumer3只消费partition3的数据
consumer4不会消费到任何数据
原因: Consumer只能接受一个partition(分区)的数据
场景二: topic1 下有partition1和partition2，group下有consumer1
consumer只有一个线程,且消费topic1的消息.
消费情况: consumer1先消费partition1的数据
consumer1消费完partition1数据后开始消费partition2的数据
注: consumer在消费消息时必须指定topic,可以不指定partition,场景二的情况就是发生在不指定partition的情况下,如果consumer1指定了partition1,那么consumer1消费完partition1后哪怕处于空闲状态了也是不会消费partition2的消息的.
五、Kafka的设计思想、可容错性
1.leader的选举
kafka将每个partition数据备份到多个broker上,kafka会为partition选出一个leader，之后所有该partition的请求，实际操作的都是leader，然后再同步到其他的follower。当一个broker宕机后，所有leader在该broker上的partition都会重新选举，选出一个leader。关于partition的分配，还有leader的选举，总得有个执行者。在kafka中，这个执行者就叫controller。kafka使用zookeeper在broker中选出一个controller，用于partition分配和leader选举.
2.controller的选举
Controller的选举与leader的选举类似：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，
六、Kafka如何做到高吞吐量的？
1.顺序读写
硬盘是机械结构，需要指针寻址找到存储数据的位置，如果是随机IO，磁盘会进行频繁的寻址，导致写入速度下降。kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能，顺序读写不需要硬盘磁头的寻址时间，只需很少的扇区旋转时间，所以速度远快于随机读写，Kafka使用了顺序IO提高了磁盘的写入速度。关于磁盘I/O的性能。
引用一组Kafka官方给出的测试数据(Raid-5，7200rpm)：Sequence I/O: 600MB/s，Random I/O: 100KB/s
2.零拷贝
传统网络IO：1. 操作系统将数据从磁盘文件中读取到内核空间的页面缓存；
2. 应用程序将数据从内核空间读入用户空间缓冲区；
3. 应用程序将读到数据写回内核空间并放入socket缓冲区；
4. 操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。
备注：内核空间：操作系统； 用户空间：应用程序
通常情况下，Kafka的消息会有多个订阅者，生产者发布的消息会被不同的消费者多次消费，为了优化这个流程，Kafka使用了“零拷贝技术”，
“零拷贝技术”只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），减少了两次数据的拷贝，避免了重复的复制操作。
如果有10个消费者，传统方式下，数据复制次数为4*10=40次，而使用“零拷贝技术”只需要1+10=11次，一次为从磁盘复制到页面缓存，10次表示10个消费者各自读取一次页面缓存。
3.分区
kafka中的topic中的内容可以被分为多分partition存在,所以每次操作都是针对一小部分做操作，很轻便，并且增加并行操作的能力。（一个partition相当于一个并发）
4.数据压缩
Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩，压缩的好处就是减少传输的数据量，减轻对网络传输的压力
5.生产者客户端缓存消息批量发送，消费者批量从broker获取消息，减少网络io次数，充分利用磁盘顺序读写的性能。（producer中配置batch.size）
七、Kafka和rabbitMQ的区别
1.在吞吐量方面
Kafka是严格保证了消息队列的顺序，就是一个topic下面的一个分区内只能给一个消费者消费，对于一个分区来说，kafka是不支持并发，但是可以通过扩大分区实现并发，追求吞吐量，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
Rabbitmq 不承诺消息的顺序性，因此可以并发多线程处理。在队列中不必排队。如果对处理的顺序没有要求，就可以用Rabbitmq较容易的实现并发。更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
2.在实际生产应用中
通常会使用kafka作为消息传输的数据管道，rabbitmq作为交易数据作为数据传输管道，主要的取舍因素则是是否存在丢数据的可能；rabbitmq在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同时具备更高的实时性；而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；而且由于kafka保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况；
