kafka基础概念

kafka介绍

　　kafka is a distributed, partitiononed,replicated commited logservice. kafka是一个分布式的、易扩展的、安全性高的消息服务系统。kafka提供了相似于JMS的特性，但在设计实现上又彻底不一样，它并非基于JMS规范实现的（kafka的实现不包含事务特性性）。kafka对消息的保存时以Topic进行归类的，向Topic发送消息的称谓Producer,从Topic接受消息的称谓Consumer。kafka集群由多个service组成，每一个service在kafka集群中被称做broker。kafka集群的做用就是存储从Producer发过来的消息，而后按照必定的规则将消息发送给Consumer。不管是kafka集群自己，仍是Producer 或者Consumer，均依赖于zookeeper来管理集群中的信息同步。下图为kafka基本结构组成图：

 

kafka系统名词解释

• Topics

　　一个topic能够认为是一类消息，每一个topic能够被划分红多个partition(区),每一个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量)，offset为一个Long型数字，他是log中一条消息的惟一标识。kafka并无提供其余额外的索引机制来存储offset,由于kafka的消息读写机制是顺序读写，保证kafka的吞吐率，几乎不容许（能够）对消息进行随机读取。

 

　　kafka和JMS的实现（activeMQ）不一样的是：即便消息被消费了，消息仍然不会被当即删除。日志文件将会根据broker中的配置要求，将message保留一段时间后再删除。好比将log文件保留2天，那么两天后，该文件将会被删除，不管其中的消息是否被消费。kafka经过这种简单的方式来释放磁盘空间。

　　对于consumer而言，他须要保存消费消息的offset，对于offset的保存和使用，由consumer来控制；当consumer正常消费消息时，offset将会“线性的”向前驱动，即，消息将依照顺序被消费。实际上，consumer也能够经过指定offset来消费特定的消息（offset将会保存在zookeeper中，参见下文）。

　　kafka集群几乎不须要维护任何producer和consumer的状态消息，这些消息由zookeeper来维护保存，所以，producer和consumer的客户端很是轻量级，他们能够随意的加入或者离开，不会对集群形成额外的影响。

　　partition的设计目的有多个，最根本的缘由是kafka基于文件存储，经过分区，能够将日志内容分布到多个broker上，避免文件尺寸达到单机的存储上线。能够将一个topic划分红多个partitions，这样既能够下降对单机磁盘容量的要求，又能够提升系统消息的读写速率。此外，越多的partition意味着能够容纳更多的consumer，更有效的提高并发性能。

• Distination

　　一个topic的多个partition被分配在kafka集群的多个broker上，每一个broker负责partitions中消息的读写操做；此外，kafka还能够配置partition须要的备份个数（replicas），每一个partition将会被备份到多个broker中，这样就加强了系统的可靠性。

　　基于replicated方案，那么就意味着须要对多个备份进行调度，每一个partition都有一个broker为“leader”，其他都为“follower”。leader负责全部的读写操做，若是leader失效，那么将会有其余的follower被选举为新的leader;follower只是单纯的和leader进行消息同步便可。因而可知，部署leader的broker承载了partition所有的请求压力，所以，从集群的总体角度考虑，有多少个partition，就有多少个leader，kafka将会将这些leader均衡的分配在broker上，来确保集群总体的吞吐量和稳定性。

• Producer

　　Producer将消息发布到指定的topic中，同时，producer还须要指定该消息属于哪一个partition

• Consumer

　　本质上kafka只支持topic，每个consumer属于一个consumer group，每一个consumer group能够包含多个consumer。发送到topic的消息只会被订阅该topic的每一个group中的一个consumer消费。

　　若是全部的consumer都具备相同的group，这种状况和queue很类似，消息将会在consumer之间均衡分配；

　　若是全部的consumer都在不一样的group中，这种状况就是广播模式，消息会被发送到全部订阅该topic的group中，那么全部的consumer都会消费到该消息。

　　kafka的设计原理决定，对于同一个topic，同一个group中consumer的数量不能多于partition的数量，不然就会有consumer没法获取到消息。

• Guarantees

1. 发送到partition中的消息将会按照它的接受顺序追加到日志中；
2. 对于消费者而言，它的消息消费顺序是和日志中的顺序一致的；
3. 若是partition的replicationfactor为N，那么就容许N-1个broker失效。

kafka使用场景

• Messaging

　　对于一些常规的消息系统，kafka是个不错的选择，partition/replication和容错，使得kafka具备良好的扩展性和安全性。不过到目前为止，kafka并无提供JMS中的“事务性”“消息传输担保机制（消息确认机制）”“消息分组”等企业级特性；kafka只能做为常规的消息系统，在必定程度上，还没有肯定消息发送与接收的绝对可靠。

• websit activity tracking

　　kafka能够做为“网站活性追踪”的最佳工具；能够将网页/用户操做等信息发送到kafka，进行实时监控或者离线分析等。

• Log Aggregation

　　kafka的特性决定了他很是适合作“日志手机中心”；application能够将操做日志批量“异步”发送到kafka集群中，而不是保存在本地或者DB中；kafka能够对消息进行批量的上传和压缩等，这对producer而言，几乎感受不到性能的开销。此时，consumer端可使用hadoop等其余系统化的存储和分析系统。

kafka设计原理

　　kafka设计初衷是但愿做为一个统一的信息收集平台，可以事实的收集和反馈信息，而且可以支撑较大的数据量，且具有良好的容错能力。

• 持久性

　　kafka使用文件存储消息，这就直接决定了kafka在性能上严重依赖于文件系统自己的性能。并且，不管在任何OS下，对文件系统自己的优化几乎没有了改进的可能。文件缓存/直接内存映射是经常使用的提升文件系统性能的手段。由于kafka是对日志文件进行append操做，所以磁盘检索的开销仍是比较少的，同时，为了减小磁盘写入的次数，broker会暂时将消息buffer起来，当消息数量达到了一个阈值，在写入到磁盘，这样就能够减小磁盘IO的次数。

• 性能

　　除了磁盘IO性能意外，咱们还须要考虑网络IO，这直接关系到kafka的吞吐量问题。kafka并无提供太多高超的技巧。对于producer端而言，能够将消息buffer起来，当消息数量达到必定的阈值时，批量发送给broker；对于consumer端而言，也能够批量的fatch消息，不过消息量的大小是能够经过配置文件进行配置的。对于kafka broker端，sendfile系统调用能够潜在的提升网络IO性能：将文件数据映射到系统内存中，socket直接读取相应的内存区域便可，而不须要进程再次进行copy和交换。对于producer、consumer、broker而言，CPU的开支都不大，所以启用消息压缩机制是一个很好的策略；压缩须要消耗少许的CPU资源，不过对于kafka而言，网络IO应该更为重要。能够经过将任何在网路上传输的消息进行压缩来提升网络IO性能。kafka支持多种压缩方式（gzip/snappy）。

• 生产者

　　负载均衡：producer将会和topic下的全部partition leader保持socket链接；消息由producer直接经过socket发送个broker，中间不会通过任何“消息路由”，实际上，消息被发送给哪一个broker由producer端决定。若是一个消息有多个partitions，那么在producer端实现消息“均衡分发”是颇有必要的。

　　其中partition leader位置（host:port）保存在zookeeper中，producer做为zookeeper client，已经注册了watch用来监听partition leader的变动事件。

　　异步发送：将多条消息暂且保存在producer的buffer中，当达到必定的数量阈值时，将他们一块儿批量发送给broker，延迟批量发送其实是提升了网络效率。不过也存在一些隐患，好比当producer失效时，那些还没有发送出去的消息将会丢失。

• 消费者

　　consumer端向broker发送fatch请求，并告诉其获取消息的offset，此后，consumer会得到必定数量的消息，consumer端也能够经过重置offset来从新获取想要的消息。

　　在JMS中，topic模型是基于push方式的，即broker将消息推送给consumer端。不过在kafka中，采用的是pull模型，即consumer在和broker创建链接后，主动去pull(也就是fatch)消息；这种模式有本身的优势，首先，consumer能够根据本身的消费需求去fatch合适的消息并进行处理，此外，消费者能够良好的控制消费消息的数量。

　　在kafka中，partition中的消息只有一个consumer在消费，切不存在消息状态的控制，也没有复杂的消息确认机制，可见，kafka broker是至关轻量级的。当消息被consumer接收后，consumer在本地保存最后消费消息的offset，并间歇性的向zookeeper注册offset。因而可知，consumer也是轻量级的。

 

　　kafka在zookeeper中的存储结构图以下所示：

kafka安全机制：partition复制备份

　　kafka将每一个partition数据复制到多个broker上，任何一个partition都有一个leader和多个follower(能够没有)。备份的个数能够经过broker的配置文件进行配置。leader处理全部的read-write请求，follower只须要和leader保持信息同步便可，leader负责跟踪全部的follower状态信息，若是follower落后太多或者失效，leader将会把它从replicas同步列表中删除。当全部的follower将一条消息保存成功，该消息才被认为是发送成功（committed），此时，consumer才能消费它。即便只有一个replicas存活，仍然能够保证消息的正常发送和接受，只要zookeeper集群存活便可。（不一样于其余分布式存储，须要多数派存活）

　　当leader失效时，须要在follower中选择一个新的leader（此选举并不是经过zookeeper进行选举的），可能此时的follower落后于leader，所以须要一个“up-to-date”的follower。选择新的leader时也须要同时兼顾一个问题，那就是broker上leader的数量，若是一个server上有多个leader，意味着此service将承受更多的IO压力，因此在选举时，须要考虑leader的“负载平衡”。

参考文献

• kafka入门：简介、使用场景、设计原理、主要配置及集群搭建（转）
• kafka学习笔记：知识点整理