Kafka—性能逆天的存在.docxVIP

Kafka—功能逆天的存在 Kafka是LinkedIn开源出来的一款消息服务器，用Scala言语实现；这货的功能是百万级的QPS(估量是挂载了多块磁盘)，我任凭写个测试程序就是十万级。 1、Kafka基本概念 在Kafka中消息是依据Topic进行分类的；每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，规律上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关怀数据存于何处）。 每个Topic包含一个或多个Parition;Parition是物理存储上的概念，创建Topic时可指定Parition数量。每个Parition对应一个存储文件夹，文件夹下存储该Parition所持有的消息数据和索引文件。Topic进行分区划分的次要目的是出于功能方面的考虑，Kafka尽量的使全部分区均匀的分布到集群全部的节点上而不是集中在某些节点上，另外主从关系也尽量均衡，这样每个节点都会担当肯定比例的分区的Leader。每个Parition是一个有序的队列，每条消息在Parition中拥有一个offset。 消息的发布者可将消息发布到指定的Topic中,同时Producer也能打算将此消息发送到哪个Parition(也可以实行随机、哈希、轮训等策略)。 ? 消息的消费者自动从Kafka中拉取消息进行消费(pull模式)，在Kafka中一个Parition中的消息可以被无限多个消费者进行消费，每个消费者之间是完全独立，每个Consumer消费后的消息Kafka并不进行删除操作，Kafka中的消息删除是定期进行的，可以指定保留多长时间消息不被删除。通过指定offset就可以消费任意位置的消息，当然前提是指定的offset是存在的。从这点上看Kafka更像是一个只能追加、不能修改、支持随机读取的小文件管理系统。 上面提到每个Consumer是完全独立，假如多个Consume想轮番消费同一个Topic的同一个Parition就做不到；后来Kafka创造了一个Consumer-group的概念，每个Consumer客户端被创建时,会向Zookeeper注册本人的信息;一个group中的多个Consumer可以交叉的消费一个Topic的全部Paritions;简而言之,保证此Topic的全部Paritions都能被此group所消费,且消费时为了功能考虑,让Parition相对均衡的分散到每个Consumer上，Consume-group之间是完全独立。仆人的相反是挺好的，但是悲剧的是客户端基本都不支持，貌似只要Java的客户端支持比较好。 2、消息挨次性与牢靠性设计 发布到Kafka的消息在一个Parition中是挨次存储的，发布者可以通过随机、哈希、轮训等方式发布到多个分区中，消费者通过指定offset进行消费；所以Kafka当中消息的挨次性更多的取决于使用方如何使用。 Kafka系统中消息支持容灾备份存储，每个Parition有主分区、备用分区的概念，一个Topic中的多个Parition的主分区可能落在不同的物理机器上面，Kafka也是尽量让其分布在不同的机器上以提高系统功能。消息的读写都是通过主分区直接完成，客户端要直连主分区所在的物理机进行读写操作。备用分区就像一个Consumer消费主分区的消息并保存在本地日志中进行备份;主分区担任跟踪全部的备用分区的形态,假如备用分区落后太多或者失效，主分区将会把它从同步列表中删除；主备分区的管理是通过zookeeper进行的。 发布时的牢靠性取决于两点：发送端的确认机制、以及Kafka系统落地的策略。发送端支持无确认、主分区确认(主分区收到消息后发送确认回执)、以及主备分区确认(备用分区消息同步后主分区才发送确认回执)三种机制；Kafka系统落地的策略有两种刷盘方式：通过配置消息数、以及配置刷盘时间间隔。 消费时的牢靠性取决于消费者的读取规律，Kafka是不保存消息的任何形态的。At most once、At least once?、Exactly once?三种模式需要本人依据业务实现，最简约实现就是At least once，两外两种在分布式系统中都不行能做到完全的确定实现，只能无限靠近，降低错误率。 3、消息存储方式 Parition是以文件的方式存储在文件系统中，比如创建了一个名为tipocTest的Topic，其有4个Parition，在Kafka的数据名目下面会有四个文件夹，依据Topic-partnum命名。 ? 每个文件夹的内容 ? Parition中的每条Message由offset来表示它在这个Parition中的偏移量，这个offset不是该Message在Parit