kafka学习

kafka概念介绍：

          kafka是一个分布式发布-订阅消息系统，最初由LinkedIn公司开发，目前成为Apache的项目之一。能够提供普通的消息系统功能。是一个分布式的，可划分的，冗余备份的持久性日志服务，他提供了普通消息系统功能外还有以下特点。

特点：

1：分布式的、可复制的、可发布、订阅的消息系统。

2：灵活性、拓展性、可恢复性、降低进程间的耦合度。

3：数据按顺序写入磁盘，而不是内存。

4：消息可持久化、高吞吐量。

5：主要用于处理活跃的流式数据。

6：稀疏索引和并发来提高效率。

kafka的设计思想就是结合Storm实时处理系统对消息进行实时在线处理，也可以使用Hadoop这种批处理系统对消息进行离线处理。

kafka相关术语：

      Topic（主题）：kafka按照分类对信息进行维护，即一般情况下一个业务线对应一个Topic。比如你关注了某个公众号就会收到相关消息。

       Partition（分区）：一个topic有一个或多个partition，每个partition里面都包含消息，里面的消息是有序排列的。

       Sequence（序列）：一个partition里面有一个或者多个sequence。

      Producers（生产者）：向kafka发布消息的程序叫做生产者，生产者生产的数据由消费者来消费。并负责发布消息到kafka broker。他决定将消息发往哪个主题（topic）的哪个分区（partition）。

      Consumers（消费者）：向kafka消息队列中请求消息的客户端叫做消费者。即向kafka broker读取消息的客户端。

      Broker（服务器）：kafka集群中的一台或者多台服务器就是Broker，主要用做持久化消息数据。

      Message（消息）：kafka通信基本单位，每个sequence里包含多个message。

kafka工作机制：

kafka存储：

一个topic可以认为是一类消息，即同一个业务。每个topic将被分成多个partition，在每个partition的存储层面是append log文件，任何发布到partition的消息都会被直接追加到log文件尾部，每条消息在文件中的位置称为offset（偏移量），offset为long型数字，partition里面的消息被offset有序的唯一标记。

kafka中的消息即使被消费，消息是不会被立即删除的，日志文件将会根据broker中的配置要求，保留一定的时间之后删除。比如log文件保留2天，那么两天后文件就会被清除，无论消息是否被消费，kafka用这种简单的方法来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO的开支。

对于consumer而言，他需要保存消费消息的offset，对于offset的保存和使用由consumer来控制。当consumer正常消费消息时，消息将依次顺序被消费，当然只要将offset置为任意值，consumer就可以使用任意顺序消费消息。

kafka集群的consumer和producer状态信息保存在zookeeper中。

partition的设计有很多个，最根本的原因是kafka基于文件存储，通过分区可以将日志内容分散到多个server上，来达到文件尺寸单机磁盘的上限。每个partition都会被当前server保存，可以将一个topic切分任意多个partition来消息保存。此外越多的partition意味着可以容纳更多的consumer，可以有效提升并发消费能力。

一个topic的多个partitions ，被分布在kafka集群中的多个server上，每个server负责partition中消息的读写操作，此外kafka还可以配置partition需要备份的个数，每个partition将会被备份到多台机器上，以提高可用性。

持久性：

kafka使用文件存储消息，这直接决定kafka在性能上严重依赖文件系统的本身特性，且无论任何OS下，对文件系统本身的优化几乎没有可能。文件缓存/直接内存映射等是常用的手段，因为kafka是对日志文件进行append操作，因此磁盘检索的开支是较小的，同时为了减少磁盘的写入次数，broker会将消息暂时buffer起来，当消息，当消息的个数达到一定阈值的时候，再flush到磁盘，这样减少了磁盘IO的使用次数。

性能：

需要考虑的影响性能的因素很多，除磁盘IO之外，我们还需要考虑网络IO，这直接关系kafka的吞吐量问题，kafka没有提供太多高朝的技巧，对于producer端，可以将消息buffer起来，当消息达到一定的阈值时，批量发送给broker，对于consumer端也是一样，批量fetch多条消息，不过消息的大小可以通过配置文件来指定。对于broker端，似乎有个sendfile系统调用可以潜在的提升网络IO的性能，将文件的数据映射到系统内存中，socket直接读取相应的内存区域即可，而无需进程再次copy和交换，其实对于producer/consumer/broker三者而言，CPU的开支应该都不是很大，因此启用消息压缩机制是一个良好的策略，压缩需要消耗少量的CPU资源，不过对于kafka而言，网络IO更应该考虑。可以将任何在网络上传输的消息都经过压缩。