为什么kafka需要去实现高可用和为什么不支持读写分离

点击上方 "程序架构之家" 关注公众号 设为星标 终身学习 技术干货 及时送达

背景

工作中日日在扮演CRUD boy的角色,少有机会去实践高性能,高并发,高可用之地。所以突发奇想,能否通过解读业内如雷贯耳,但又经常接触到的开源中间件redis,kafka 等,去反推这里面的高性能,高并发,高可用的流程和设计,以及这里面的技术抉择的思想。

kafka为什么需要去做高可用?

大概有两点

硬件故障常态化

当集群规模上升到一定程度后,一台或者多台机器出现宕机或者物理故障,而不能继续提供服务,是一个常态。

在这种故障常态性的情况下;上层软件层面 势必需要一套failover机制,来保证中间件服务的持续和高可用的稳定运行。翻译成人话就是 机器多了,机器出故障的概率就高了,可能这种出故障的概率已经和软件自身的bug一样多了,不得不去解决这种问题了。(让我想到了某IT大神说的,万恶的硬件故障,很多硬件人员不去解决或者兼容硬件的问题,他们只会把问题和矛盾转移到上层,由软件层面来兜底底层的硬件故障

数据丢失风险

在0.8版本之前,kafka是不提供高可用机制的;某个broker所在机器宕机后,如果服务不能恢复,那么在broker上面的消息数据就丢失了。数据丢失的问题,倒逼kafka 必须提供服务高可用。
比如你的订单消费服务正在消费订单数据,突然kafka集群中某台机器的硬盘坏了,导致在这上面的分区订单消息丢失了,此时的你还敢用kafka吗?

kafka 是如何实现高可用的

 分析一般中间件高可用的解决方法可知:实现高可用关键流程

  • 冗余

  • 故障检测

  • 切主

  • 外部通知

高可用里涉及到的设计点和详细流程可参见这位大佬的总结,此处不详讲了:http://www.jasongj.com/2015/04/24/KafkaColumn2/

既然分区提供了冗余,kafka 为什么不提供读写分离?

常用中间件redis,mysql,都可以提供读写分离模式;即主提供写,从提供读,以此来充分的使用机器的资源;并且也是提高系统处理性能的法宝之一。但是为什么kafka也有主从类似的模式,却不提供读写分离了?比如生产者往leader分区写入消息;消费者从其它follower分区读取消息了?**大概有如下几个原因 **

消息的消费并不是单纯的读

消息的消费看起来是一个单纯的读数据的操作,但其实包含了写操作。比如我们消费消息时的代码模式如下:

while(true){ consumer.poll(); #①拉取消息  XXX #②处理消息;consumer.commit();}


在消费完消息时,一般会手动commit;而这个commit动作,其实是告诉broker端,记录该topic分区上已成功消费消息的位置。这是个写入操作。

主从数据同步的简单性

假设kafka支持了读写分离,即生产端写入消息到leader分区,消费端从follower分区读取消息,并提交位移到follower分区;此时会发现本来follower只需要单纯的从leader拉数据进行处理的单向过程,变的非常复杂。

因为follower保存了分区消息的位置,那么这一数据必须要同步给leader分区,或者其它的follower分区。一个分区的数据同步链路变成了n*n;大大增加了leader和follower间数据同步的复杂性,并且这个同步逻辑还更容易出错。而单向的同步逻辑,只需要leader保证写入数据的顺序性;follower单向从leader拉取数据即可。

单向数据同步过程

n*n 数据同步过程

消息消费的及时性

如果kafka提供了读写分离,并且规避了n*n的同步过程,和不单纯的读过程 (生产端写入消息到leader分区,消费端从follower分区读取消息,消息成功消费的位移在保存到leader分区)是不是提供读写分离就没啥问题了?
貌似看起来没啥大问题。
但是我们知道使用读写分离,读到的数据,是有一定的延迟的,这是读写分离方案固有的一个缺陷吧。相比较主节点提供写和读的服务,如果写主读从,读势必会存在一定的延迟,而这种延迟取决于主从同步之间的延迟。

总结

kafka 实现高可用的原因:硬件故障常态化和为了解决数据丢失的风险
kafka 实现高可用的核心思想:冗余,故障检测,切主,外部通知
kafka 为什么不提供读写分离:消息的消费并不是单纯的读,主从同步功能的简单性,消息消费的及时性

-End-

精彩推荐  1、震惊了,原来这才是Kafka的“真面目”?!2、Netty、Kafka中的零拷贝技术到底有多牛?
3、那 Kafka 为什么这么快?如何做到这个高的性能?4、Kafka消费者源码解析,学习总结
程序架构技术群

构建高质量的技术交流社群,欢迎从事编程开发、技术招聘HR进群,也欢迎大家分享自己公司的内推信息,相互帮助,一起进步!

文明发言,以交流技术职位内推行业探讨为主

广告人士勿入,切勿轻信私聊,防止被骗,加我好友,拉你进群 

感谢家人们、兄弟们的关注与支持 🙏分享成长之路,不忘初心,惠泽他人 🌟与时俱进,终身学习,点赞关注不迷路 ✨

相关推荐

  • 腾讯员工爆料:公司内部到底有多少在考公了,最近老看到在会议室有刷题和准备面试的人
  • 整理了2024年最新顶会论文【附PDF】
  • 马斯克打算为特斯拉量身定制一个ChatGPT
  • ​有了LLM,所有程序员都将转变为架构师?
  • ICLR2024|生成式视角下的实体对齐
  • FlashAttention加速升级!又快了200%!
  • LangChain库
  • 【干货】史上最全的AIGC大模型工具集汇总(下)
  • 从B 树、B+ 树、B* 树谈到R 树
  • 如何使用Docker来渐进式提升开发及部署体验
  • 一个现代化轻量级的跨平台 Redis 桌面客户端,支持 Mac、Windows 和 Linux
  • 京东快递小程序分包优化实践
  • 前端最全的5种换肤方案总结
  • 今天面试了一个前端女生,当场想给她offer!
  • 实现 SpringBoot 程序加密,禁止 jadx 反编译
  • SpringBoot+ElasticSearch实现文档内容抽取、高亮分词、全文检索
  • Angular、React等前端框架掌门人的2024预测
  • 阿里核心业务互动频繁,业务上市计划均有变化;英伟达禁止其他硬件平台运行CUDA;微软将不支持Windows安卓子系统 |极客头条
  • 传MiniMax估值超25亿美元;淡马锡考虑投资OpenAI;谷歌搜索将过滤AI生成内容丨AIGC大事日报
  • 最强文生图模型架构曝光!28页论文详解技术细节,与Sora“师出同门”