-
kafka：分布式，可扩展，高吞吐率的消息日志系统
-
很多分布式消息系统都是采用push的方式消费数据，kafka采用pull的方式消费数据，可以自适应消费服务器的处理能力，更适合。
-
kafka架构和设计原则
producer producer topic to brokers
consumer pull data from brokers
支持批量发送消息
kafka architecture.PNG
3.1 Efficiency on a Single Partition
简单存储：为了提升性能，当producer产生的数据文件段达到一定数量或者达到一定时间时，才将数据刷入磁盘。只有刷入磁盘的数据才能被消费者读取
消费都是通过offset来消费的
kafka log.PNG
插一句：想起项目中kafka应用，可以选择消费策略：从头开始消费、从最新数据开始消费（指消费组在第一次注册监听某个主题开始算起的数据，第一次监听之后kafka应该会持久化该消费者的相关信息）
无状态的broker：消费者消费到哪是由自己维护的，broker不管；broker删数据策略：默认删除七天前的数据
消费者可以自己指定offset开始消费，这就意味着消费者是可以重复消费数据的，自己控制，一般保证业务处理幂等就没什么问题
3.2 Distributed Coordination
分布式协调：主要将的是kafka是通过zk协调来完成生产者与消费者之间的交互的
- 将一个topic分成多个partition，同一个消费组只能有一个消费者去消费其中的某个partition, 有相应的算法在后面会提到。还有一个点，就是当消费组组某些消费者挂了或者新增消费者时，需要重新分配
- 没有所谓的master节点，而是让消费者们自己协调，通过在zk上创建、删除节点等来完成协调工作。
[1] 消费者可以在监听某个path，当path的值或者子节点发生改变时会得到通知
[2] 在zk上创建的节点是临时的，当机器与zk断开连接时，zk会删除节点
[3] zk会将它的数据复制到多台机器上，保证高可用性
每个消费者组在zk上都对应一个拥有者注册器和一个偏移量注册器；拥有者注册器有一个path对应topic的partitions, 值为partition对应的consumer；偏移量注册器是记录消费到当前partitions的offset
图中是topic:test_2有4个partition, replica=2, test-consumer-group消费组有三个消费者，消费者组对应一个owner registry和一个offsets registry
IMG20180823_152441.png
由上面的策略可以看出，kafka由于partitions的存在，是不保证消息的顺序消费的
partitions与consumer group中的consumers的对应
3.3 Delivery Guarantees
kafka只保证至少消费一次，不保证只消费一次，这就要求系统使用的时候保证消息消费的幂等性。
为什么无法保证只消费一次？比如某个consumer消费某个topic的partition1, 消费的过程中还没来得及将offset写入offset registry中，就因为某种故障强制down机了，等rebalance之后再来消费的时候拿到的该partition的offset还是老的，这样就会存在部分数据重复消费了。
-
Experimental Results
Producer Test:
Producer Performance.JPG
发送之所以比其他mq要快，是因为：
- kafka可以批量发送并且不会等待broker的确认，因此也无法保证100%发送成功
- 第二点，kafka的存储数据结构更加精简，头部占的字节数比较少。
Consumer Test:
Consumer Performance.JPG
消费之所以比其他mq快，是因为：
- 还是消息存储数据结构比较精简，处理快
- 不需要保存消息的状态，不需要开启额外的线程存储消息的状态
- think
5.1 消息发到broker中，是怎么存储的，如何持久化？
5.2 实际动手看一看zk+kafka, consumers-partitions节点是怎么样的
网友评论