kafka
2019-11-22 本文已影响0人
Hmcf
一、什么是Kafka
1、kafka简介
Kafka是一个分布式的、可分区的、可复制的消息系统。
Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。
2、kafka基本架构
1、话题（Topic）：是特定类型的消息流（字节的有效负载），话题是消息的分类；
kafka中消息订阅和发送都是基于某个topic。
比如有个topic叫做NBA赛事信息，那么producer会把NBA赛事信息的消息发送到此topic下面。
所有订阅此topic的consumer将会拉取到此topic下的消息。
Topic就像一个特定主题的收件箱，producer往里丢，consumer取走。
2、生产者（Producer）：是能够发布消息到话题的任何对象；
3、服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群；
一个Borker就是Kafka集群中的一个实例，或者说是一个服务单元。
连接到同一个zookeeper的多个broker实例组成kafka的集群。
在若干个broker中会有一个broker是leader，其余的broker为follower。
4、消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息；
Kafka和其它消息系统有一个不一样的设计，在consumer之上加了一层group（Consumer Group）；
同一个group的consumer可以并行消费同一个topic的消息，但是同group的consumer，不会重复消费。
如果同一个topic需要被多次消费，可以通过设立多个consumer group来实现。每个group分别消费，互不影响。
image
二、kafka原理
我们将消息的发布（publish）称作 producer，
将消息的订阅（subscribe）表述为 consumer，
将中间的存储阵列称作 broker(代理);
image
多个 broker 协同合作，
producer 和 consumer 部署在各个业务逻辑中被频繁的调用，
三者通过 zookeeper管理协调请求和转发。
这样一个高性能的分布式消息发布订阅系统就完成了。
image
1、producer 到 broker 的过程是 push，也就是有数据就推送到 broker；
2、 consumer 到 broker 的过程是 pull，是通过 consumer 主动去拉数据的，
而不是 broker 把数据主懂发送到 consumer 端的。
三、Zookeeper在kafka的作用
Zookeeper在kafka的作用：
1、无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息
（kafka的配置，集群状态和连接信息等元数据）。
2、Kafka使用zookeeper作为其分布式协调框架，很好的将消息生产、消息存储、消息消费的过程结合在一起。
3、借助zookeeper，kafka能够生产者、消费者和broker在内的所以组件在无状态的情况下，
建立起生产者和消费者的订阅关系，并实现生产者与消费者的负载均衡。
1、Producer 如果生产了数据，会先通过 zookeeper 找到 broker，然后将数据存放到 broker；
2、Consumer 如果要消费数据，会先通过 zookeeper 找对应的 broker，然后消费；
四、kafka特性
1、高吞吐量、低延迟：
kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，
每个topic可以分多个partition, consumer group 对partition进行consume操作；
2、可扩展性：
kafka集群支持热扩展（不停机的情况下扩展kafka）；
3、持久性、可靠性：
消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
4、容错性：
允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）；
5、高并发：
支持数千个客户端同时读写；
6、支持实时在线处理和离线处理：
可以使用Storm这种实时流处理系统对消息进行实时进行处理，
同时还可以使用Hadoop这种批处理系统进行离线处理；
五、kafka使用场景
1、日志收集：
2、消息系统：
解耦和生产者和消费者、缓存消息等；
3、用户活动跟踪：
记录web用户或者app用户的各种活动，
如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，
然后订阅者通过订阅这些topic来做实时的监控分析；
或者装载到Hadoop、数据仓库中做离线分析和数据挖掘；
4、运营指标：
Kafka也经常用来记录运营监控数据。
5、事件源：
六、kafka的分区（针对topic）
1、kafka采用分区（Partition）的方式，使得消费者能够做到并行消费，从而大大提高了自己的吞吐能力。
2、同时为了实现高可用，每个分区又有若干份副本（Replica），这样在某个broker挂掉的情况下，数据不会丢失。
3、无分区时，一个topic只有一个消费者在消费这个消息队列。
采用分区后，如果有两个分区，最多两个消费者同时消费，消费的速度肯定会更快。
image
1、一个分区只能被同组的一个consumer消费；
2、同一个组里面的一个consumer可以消费多个分区；
3、消费率最高的情况是分区数和consumer数量相同；确保每个consumer专职负责一个分区。
4、consumer数量不能大于分区数量；当consumer多余分区时，就会有consumer闲置；
5、consumer group可以认为是一个订阅者集群，其中每个consumer负责自己所消费的分区；
七、副本（Replica-确保数据可恢复）：
1、每个分区的数据都会有多份副本，以此来保证Kafka的高可用。
2、topic下会划分多个partition，每个partition都有自己的replica，
其中只有一个是leader replica，其余的是follower replica。
3、消息进来的时候会先存入leader replica，然后从leader replica复制到follower replica。
只有复制全部完成时，consumer才可以消费此条消息。
image
由上图可见，leader replica做了大量的工作。所以如果不同partition的leader replica在kafka集群的broker上分布不均匀，就会造成负载不均衡。
注：kafka通过轮询算法保证leader replica是均匀分布在多个broker上。如下图。
image
可以看到每个partition的leader replica均匀的分布在三个broker上，follower replica也是均匀分布的。
Replica总结：
1、Replica均匀分配在Broker上，同一个partition的replica不会在同一个borker上；
2、同一个partition的Replica数量不能多于broker数量。
多个replica为了数据安全，一台server存多个replica没有意义。server挂掉，上面的副本都要挂掉。
3、分区的leader replica均衡分布在broker上。此时集群的负载是均衡的。这就叫做分区平衡；
八、Partition的读和写
topic下划分了多个partition，消息的生产和消费最终都是发生在partition之上；
image
1、producer采用round-robin算法，轮询往每个partition写入topic；
2、每个partition都是有序的不可变的。
3、Kafka可以保证partition的消费顺序，但不能保证topic消费顺序。
4、、每个consumer维护的唯一元数据是offset，代表消费的位置，一般线性向后移动。
5、consumer也可以重置offset到之前的位置，可以以任何顺序消费，不一定线性后移。
九、数据持久化
为了提高性能，现代操作系统往往使用内存作为磁盘的缓存；
虽然每个程序都在自己的线程里只缓存了一份数据，但在操作系统的缓存里还有一份，这等于存了两份数据。
与传统的将数据缓存在内存中然后刷到硬盘的设计不同，
Kafka直接将数据写到了文件系统的日志中。
十、消息传输的事务定义
数据传输的事务定义通常有以下三种级别：
1、最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输。
2、最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
3、精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。
kafka存在的问题
如果producer发布消息时发生了网络错误，但又不确定实在提交之前发生的还是提交之后发生的，
这种情况虽然不常见，但是必须考虑进去，现在Kafka版本还没有解决这个问题，
将来的版本正在努力尝试解决。
kafka的可指定消息传输级别
并不是所有的情况都需要“精确的一次”这样高的级别，Kafka允许producer灵活的指定级别。
比如producer可以指定必须等待消息被提交的通知，
或者完全的异步发送消息而不等待任何通知，或者仅仅等待leader声明它拿到了消息。
十一、kafka性能优化
1、消息集：
以消息集为单位处理消息，比以单个的消息为单位处理，会提升不少性能。
Producer把消息集一块发送给服务端，而不是一条条的发送；
服务端把消息集一次性的追加到日志文件中，这样减少了琐碎的I/O操作。
consumer也可以一次性的请求一个消息集。
2、数据压缩
Kafka采用了端到端的压缩：因为有“消息集”的概念，客户端的消息可以一起被压缩后送到服务端，
并以压缩后的格式写入日志文件，以压缩的格式发送到consumer，
消息从producer发出到consumer拿到都是被压缩的，只有在consumer使用的时候才被解压缩，所以叫做“端到端的压缩”。
Kafka支持GZIP和Snappy压缩协议。
十二、Kafka Producer消息发送
客户端控制消息将被分发到哪个分区。
可以通过负载均衡随机的选择，或者使用分区函数。
Kafka允许用户实现分区函数，指定分区的key，将消息hash到不同的分区上;
比如如果你指定的key是user id，那么同一个用户发送的消息都被发送到同一个分区上。
经过分区之后，consumer就可以有目的的消费某个分区的消息。
Producer异步发送消息：
批量发送可以很有效的提高发送效率。
Kafka producer的异步发送模式允许进行批量发送，先将消息缓存在内存中，然后一次请求批量发送出去。
这个策略可以配置的，比如可以指定缓存的消息达到某个量的时候就发出去，
或者缓存了固定的时间后就发送出去（比如100条消息就发送，或者每5秒发送一次）。
这种策略将大大减少服务端的I/O次数。
十三、Kafka Consumer
Kafa consumer消费消息时，向broker发出"fetch"请求去消费特定分区的消息。
consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息。
customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的。
Kafka遵循了一种大部分消息系统共同的传统的设计：
producer将消息推送到broker，consumer从broker拉取消息。
1、push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。
因此最终Kafka还是选取了传统的pull模式。
2、Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。
3、Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到达。
为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量consumer才去拉去消息)。
十四、主从同步
1、创建副本的单位是topic的分区，每个分区都有一个leader和零或多个followers；
所有的读写操作都由leader处理；同一个分区的副本数量不能多于brokers的数量；
2、各分区的leader均匀的分布在brokers中。
所有的followers都复制leader的日志，日志中的消息和顺序都和leader中的一致。
flowers向普通的consumer那样从leader那里拉取消息并保存在自己的日志文件中。
3、Kafka判断一个节点是否活着有两个条件：
（1）节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接。
（2）如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久。
4、leader的选择
Kafka的核心是日志文件，日志文件在集群中的同步是分布式数据系统最基础的要素。
（1）Kafaka动态维护了一个同步状态的副本的集合简称ISR；
集合中的任何一个节点随时都可以被选为leader。ISR在ZooKeeper中维护。
ISR的成员是动态的，如果一个节点被淘汰了，当它重新达到“同步中”的状态时，他可以重新加入ISR。
这种leader的选择方式是非常快速的，适合kafka的应用场景。
（2）所有的副本都down掉时，必须及时作出反应。可以有以下两种选择（kafka选择b）：
a：等待ISR中的任何一个节点恢复并担任leader
（ISR中的节点都起不来，那集群就永远恢复不了）
b：选择所有节点中（不只是ISR）第一个恢复的节点作为leader（如果等待ISR以外的节点恢复，这个节点的数据就会被作为线上数据，
有可能和真实的数据有所出入，因为有些数据它可能还没同步到。）
十五、kafka与rabbitmq的区别
1、架构模型方面
kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，
consumer根据消费的点，从broker上批量pull数据；无消息确认机制。
RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，
其中exchange和binding组成了消息的路由键（消息到哪个队列）；
客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费
（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）
rabbitMQ以broker为中心；有消息的确认机制（消费过后剔除队列）。
2、在吞吐量方面
kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，
数据的存储和获取是本地磁盘顺序批量操作（文件系统），具有O(1)的复杂度，消息处理的效率很高。
rabbitMQ在吞吐量方面稍逊于kafka，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；
3、在可用性方面
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka的broker支持主备模式（副本）。
4、在集群负载均衡方面
kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；
通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；
rabbitMQ的负载均衡需要单独的loadbalancer进行支持。
