2019/2/22星期五
<强>在卡夫卡中为什么高吞吐量是他的优点见下4点优点
1,创建一个主题时,同时可以指定分区数目,分区数越多,其吞吐量也越大,但是需要的资源也越多,同时也会导致更高的不可用性,卡夫卡在接收到生产者发送的消息之后,会根据均衡策略将消息存储到不同的分区中。因为每条消息都被附加到该分区中,属于顺序写磁盘,因此效率非常高(经验证,顺序写磁盘效率比随机写内存还要高,这是卡夫卡高吞吐率的一个很重要的保证)。
2,我们知道在kafaf中的数据不会一直保存着,一般默认是存储2周时间,2周时间之后会删除数据,当然这些可以通关参数去调整,
因此卡夫卡提供两种策略删除旧数据。一是基于时间,二是基于分区文件大小,例如可以通过配置KAFKA_HOME美元/config/server.properties,让卡夫卡删除一周前的数据,也可在分区文件超过1 gb时删除旧数据,
log.segment.bytes log.retention.hours=168=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
那既然删除数据和卡夫卡的性能无关,怎么删除数据就磁盘策略以及具体的需求有关。
抵消由消费者控制,因为offet由消费者控制,所以卡夫卡代理是无状态的,它不需要标记哪些消息被哪些消费过,也不需要通过代理去保证同一个消费者团体只有一个消费者能消费某一条消息,因此也就不需要锁机制,这也为卡夫卡的高吞吐率提供了有力保障。
3,有了分区后,不同的消息可以并行写入不同代理的不同分区里,极大的提高了吞吐率。
4,使消费者高级api时,用同一个主题的一条消息只能被同一个消费者团体内的一个消费者消费,但多个消费者组织可以同时消费这一个消息。
<人力资源/>如何保证消息的可靠性传输吗?//卡夫卡丢数据的可能性
https://blog.csdn.net/qq_36236890/article/details/81174504/此链接非常的重要
卡夫卡有几种故障的转移//参考链接为https://www.cnblogs.com/qingyunzong/p/9004593.html
有这么几种可能的交货保证:
最多一次消息可能会丢,但绝不会重复传输
至少一个消息绝不会丢,但可能会重复传输
完全一次每条消息肯定会被传输一次且仅传输一次,很多时候这是用户所想要的。
<强>丢数据可能性1
当制片人向代理发送消息时,一旦这条消息被提交,因数复制的存在,它就不会丢。但是如果生产商发送数据给代理后,遇到网络问题而造成通信中断,那企业就无法判断该条消息是否已经提交。虽然卡夫卡无法确定网络故障期间发生了什么,但是生产商可以生成一种类似于主键的东西,发生故障时幂等性的重试多次,这样就做到了一次。
//这一步是制片人生产者到卡夫卡代理过程会出现的消息丢失的可能性和解决方法
<强>丢数据可能性2
接下来讨论的是消息从代理到消费者的交货保证语义。(仅针对卡夫卡消费高级API) .Consumer在从代理读取消息后,可以选择提交,该操作会在动物园管理员中保存该消费者在该分区中读取的消息的偏移量。该消费者下一次再读该分区时会从下一条开始读取。
如未提交,下一次读取的开始位置会跟上一次提交之后的开始位置相同。当然可以将消费者设置为自动提交//自动提交,即消费者一旦读到数据立即自动提交。如果只讨论这一读取消息的过程,那卡夫卡是确保了完全一次。
但实际使用中应用程序并非在消费者读取完数据就结束了,而是要进行进一步处理,而数据处理与提交的顺序在很大程度上决定了消息从经纪人和消费者的交货保证语义(交付保证语义)。
//这一步是消费者消费者到卡夫卡代理过程会出现的消息丢失的可能性和解决方法
卡夫卡默认保证至少一次//消息绝不会丢,但可能会重复传输,并且允许通过设置生产商异步提交来实现最多一次。而正是一旦要求与外部存储系统协作,幸运的是卡夫卡提供的偏移量可以非常直接非常容易得使用这种方式。
生产者传递消息到代理过程
1,生产商在发布消息到某个分区时,先通过饲养员找到该分区的领袖,然后无论该主题的复制因子为多少,生产商只将该消息发送到该分区的领袖。
2,领导者会将该消息写入其本地日志。
3,每个追随者都从领袖拉数据。这种方式上,追随者存储的数据顺序与领袖保持一致。
4,追随者在收到该消息并写入其日志后,向领导人发送ACK。
