收费下载网站cms,网站开发报告书,茶叶网站策划,建设通破解版不可靠的KAFKA这里的不可靠是指代KAFKA其设计之初就为高性能而设计#xff0c;其是允许消息丢失的#xff0c;但经过多个版本的升级之后#xff0c;通过KAFKA的相关配置#xff0c;我们可以将其作为可靠的队列(不丢消息的队列)。在本文里#xff0c;不会具体列出要改哪个参…不可靠的KAFKA这里的不可靠是指代KAFKA其设计之初就为高性能而设计其是允许消息丢失的但经过多个版本的升级之后通过KAFKA的相关配置我们可以将其作为可靠的队列(不丢消息的队列)。在本文里不会具体列出要改哪个参数需要改的参数请大家自行翻文档找出来这样理解会更为深刻。发送消息到KAFKA时产生的消息丢失在一些比较旧的版本KAFKA客户端发送消息到KAFKA服务器时由于客户端不等待服务器回应直接返回等待发送异步进行。因此其在发送环节就可能存在消息丢失。为了避免消息丢失我们需要用新版客户端并配置客户端发送消息时同步等待返回结果KAFKA服务器宕机导致的消息丢失(磁盘缓存丢失)KAFKA自身不管理LOG写入磁盘的缓存将其交由操作系统处理。因此在默认配置下如果KAFKA宕机则会因为数据没有FLUSH到磁盘而丢失数据。为了保证数据不丢失KAFKA提供的现成方法有两个每条消息都Flush一次 每条都Flush一遍必然不可行因为其速度会变得很慢。官方也不建议这么做。(如果其有类似Group Commit的优化机制的话我觉得可以使用但是貌似曾经有人提过这个PR没有被采纳其认为用集群就可解决这个可靠性问题)构建集群以提高可用性。 官方推荐的方法。只要挂的机器不要超过强制写入的机器那么就可以保证数据不丢失。但需要注意的是KAFKA组成的集群必须在不同机房。不然机房一断电集群内的KAFKA就会出现消息丢失。KAFKA复制模式导致的丢失KAFKA的副本模式为主备复制模式这个模式下有两种形式 同步复制模式 以及 异步复制模式。异步复制模式 客户端将信息发送到主副本主副本收到信息写到本地缓存后即返回ACK给客户端。然后异步地将数据发送给备份。本配置为默认配置其高效但主挂掉则消息丢失。 同步复制模式 客户端将信息发送到主副本主副本收到信息写到本地缓存并发送给所有从机从机都写到缓存后给主机反馈主机都收到反馈后再反馈给客户端需要修改复制模式为同步复制KAFKA选举导致的消息丢失KAFKA有一个配置是否允许在不得已的情况下允许在非同步状态下的副本成为主副本。其默认是打开的结果就导致存在丢失消息的可能性。需要将其关闭未被确认的消息不会被消费KAFKA使用主从同步复制的时候没有被完全复制(完全复制的消息会在HW(High water Mark之下))的信息不会被消费。 一个Broker若需要从非ISR状态进入到ISR状态前会将其在HW之前的消息记录给truncate掉并尝试跟上Master里的记录。跟上后将会恢复ISR状态。KAFKA的主节点选举通过ZK中登记的序号决定更细节可查看KAFKA同步复制模式选举过程以上为默认实现不需修改也无法修改已确认的消息如果存在ISR状态的副本的话就不会丢失记录原Master挂掉后新选出的Master不会丢弃HW之后的消息新Master会将这些HW之后的副本再次发送给其余的副本。因此即使高水位信息没有传递给新的Master副本也没有问题。ISR分区过少导致失去容灾特性默认配置下ISR分区个数可以为1时依然可以写数据。但当出现这种情况的时候就失去了容灾性。只要主分区挂掉那么数据就丢失。KAFKA有配置可以指定写入时最少的ISR数量少于特定值就不再ACK。如一共三台BROKER我们可以指定ISR最少数量为2,那么只有1台处于ISR状态的话COMMIT将无法执行。是否设置该值视具体情况而定若无法容忍丢失则设置该值为2NAME 。追求可用性则不设置。个人建议设置为2无论副本数量有多少KAFKA如何处理网络分区情况如果MASTER与其他的副本与ZK是联通的但是MASTER与其他副本之间出现了网络分区那么ISR就只能为1。消息保存的策略的设置建议保留消息的策略基于时间。如保留21天客户端宕机导致的消费位置丢失KAFKA在分区中的消费位置由客户端管控其有可能没有及时保存到KAFKA中导致消费位置丢失。 若消费位置丢失则消费可能从上一个保存的消费位置重新进行消费。所以在不能接受重复消息的系统需要自行定制对于消息的幂等处理(死信是否会丢失)At Least Once实际上我们对可靠消息系统的要求通常是At least Once,经过上述配置已经基本达到了At Least Once的要求消息消费失败的重试设置需要设计一个死信队列消费失败的消息需放入里面以免影响后续其他消息消费参考
