上两篇文章都在讨论顺序消息的一些知识,看到有个读者的留言如下:
这个问题问得非常棒,由于在之前的文章中并没有提及到,因此我在这篇文章中单独讲解,本文将从消费顺序性这个问题出发,深度剖析 Kafka/RocketMQ 多线程消费的线程模型。
上一篇文章「保证严格的消息顺序消费究竟有多难?」简单描述了对消息顺序消费的一些理解,上一篇文章中的第二个故障问题,感觉没描述清楚,现在我以 Kafka 为例子,继续分析一波。
我不记得有多少人问过以下这个问题了:
我觉得这个问题问得很频繁,而且非常经典,在这里我就以 Kafka 为例子,说说我对 Kafka 顺序消息的一些理解吧,如有理解不对的地方麻烦留言指点一下。
丁老师在他的知识星球邀请我回答以下一个问题:
我觉得这个问题非常有意思,姑且把它贴到公众号这里,与大家分享一下我对这个问题的一些感悟。
感谢丁老师的邀请问答:
在这里我就简单说下,我这段时间参与 Seata 开源项目的一些感悟:
1、如何参与到开源项目中并贡献自己的一份力量?
我一直都有上 GitHub 搜索一些主流开源项目的习惯,我是从去年 5 月份从 GitHub 开始关注 Seata 项目的,经过入门上手之后,我就觉得它的设计理念非常棒,尽管当时还有很多地方没有完善,但并不阻碍我对它的赞美,我对它产生了浓厚的兴趣,我那个时候就萌发了我要成为这个项目的贡献者。
很多人说,我又不是大佬,我现在还不够优秀,我没有太多的业余时间和精力,我也不知道这个项目是否合适我,等等,也有人以为需要成为某个领域大牛,才可以参与其中,其实这是对开源最大的误解,开源当然有大牛,不但有,而且非常多,这些大牛很多都是值得你学习的榜样,但是为开源项目做贡献需要成为某个领域大牛并不是必要的,但需要你花费大量时间和精力去贡献,在这个过程中,你同样能够学到很多。
我接下来继续讲讲我是如何参与 Seata 的贡献:
我是先从官方文档开始了解 Seata 项目的,并根据自己的了解,写了一篇文章,同时这篇文章还被阿里巴巴中间件转载过,正如丁老师所说,为开源项目做贡献并不只是贡献代码,为项目写文章同样是一种贡献。
在了解 Seata 的原理之后,我就着手看 Seata 源码,继续深入研究,在这个过程中,我是发现 Seata 源码是有很多地方需要完善的,因此我得到了代码贡献的机会,在看源码的过程中,我参与了某些 bug 的修复,一些功能的开发,同时还对部分代码进行了优化,代码优化这点我特别有感触,因为 Seata 的 RPC 重构主要是由我完成的,由于我之前研究过一些 RocketMQ 的源码,其中就包括 remoting 模块,感觉它的设计思想非常好,于是我就将这个设计思想从 RocketMQ 带到 Seata 中。
我这里在补充一点,很多人看源码的时候,看到某些代码写得不是很优雅,瞬间不想研究下去了,我觉得这点非常不可取,我们在看源码的同时,需要秉承一种 “不拘小节,观其大意” 的精神,因为每个人都有自己的编码风格,如果你觉得写的不好,那么这时候你的机会就来了,这时候提个 PR 优化一波会不会更加爽?而且一个开源项目都有其本身的设计理念,不要为了拘一时小节,而忽略了其整体的架构设计。
在参与开发的过程中,相当于在玩游戏打怪升级,如果你对某个开源项目贡献了自己的代码,那么恭喜你,你成功成为了该项目的贡献者(Contributor),这时候在开源项目的贡献者名单中,就有你的大名啦,你的代码将会随着项目 run everywhere,是不是心中充满了成就感?如果你一直对项目有持续的贡献,那么成为该项目的核心开发(Committer)指日可待。但需要记住一点的是,持续贡献不仅仅只是提交代码,参与 PR Code Review、输出文章、解答用户问题同样是一种贡献。
总之,参与到开源项目中并贡献自己的一份力量并没有想象中的难,难的是你有没有一颗坚持的心,难的是你有没有花心思并付诸行动。
做开源,需要持之以恒。
2、从开源项目中能够学到什么?
从以上的描述中,我花费了那么多时间和精力,我能够从中得到什么?仅仅只是让我的代码 run everywhere?那不免太过于浮躁了。
在这个过程中,你将会和一群优秀的程序员沟通交流,能够将本职工作做好,同时还能把业余时间贡献给开源的人,本身就说明了这个人能力不赖,而且富有激情,至少对编程这件事来说,是充满兴趣的,跟者这些优秀的人在一起做一个有趣的开源项目,你也会慢慢地变得优秀起来。
参与开源项目会形成给予你一种学习驱动力,比方说我在重构 Seata RPC 模块时,驱动我去学习 Netty 相关知识,在写配置同步脚本时,驱动我去学习写脚本(我真的是边学边写 Seata 配置同步脚本的),在研究 Seata 配置中心实现原理时,驱动我去研究 Seata SPI 机制,并且要了解各个配置中心框架的特性等等,人性往往是懒惰的,如果你为了学而去学,很多时候你会半途而废,很多时候你做着某件事半途而废,往往就是因为没有外界驱动力,去驱动你去坚持。学过物理的都知道,世上没有永动机,外界驱动力就是你坚持下去的动力源泉。
同时,你在研究源码或者进行 PR CodeReview 时,可以看到很多大牛的编程思想,这也是你最宝贵的经验源泉,比如 Seata RPC 模块的 Processor 处理器设计思想就是我从 RocketMQ 源码中参透而来。如果你想摆脱日常 CRUD,想增进自己的编码水平,来开源做点贡献吧!
开源项目中的大牛很多,参与开源会使自己变得更加谦卑,还会让自己的思维变得更开阔,不会局限于自我。
以上就是我暂时想到的从开源项目中能够学到的一些东西以及感悟。
PS:Seata 社区欢迎你,和一群优秀的人做一件有趣的事!
相关阅读:
最近都在看小马哥的 Spring 视频教程,通过这个视频去系统梳理一下 Spring 的相关知识点,就在一个晚上,躺床上看着视频快睡着的时候,突然想到当我们在使用 SpringMVC 时,Spring 容器是如何与 Servlet 容器进行交互的?虽然在我的博客上还有几年前写的一些 SpringMVC 相关源码分析,但都是点到为止,没有好好再深入了解其中的机制,Spring 容器是如何与 Servlet 容器进行交互并没有交代清楚,于是趁着这个机会,再撸一次 SpringMVC 源码。
经过上次 Kafka 日志集群某节点重启失败导致某个主题分区不可用的事故之后,这篇文章专门对分区不可用进行故障重现,并给出我的一些骚操作来尽量减少数据的丢失。
上次的 Kafka 重启失败事件,对为什么重启失败的原因似乎并没有解释清楚,那么我就在这里按照我对 Kafka 的认识,从源码和日志文件结构去尝试寻找原因。
在 2 月10 号下午大概 1 点半左右,收到用户方反馈,发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader,导致某些消息发送到该分区时,会报如下 no leader 的错误信息:
In the middle of a leadership election, there is currently no leader for this partition and hence it is unavailable for writes.
接下来运维在 kafka-manager 查不到 broker0 节点了处于假死状态,但是进程依然还在,重启了好久没见反应,然后通过 kill -9 命令杀死节点进程后,接着重启失败了,导致了如下问题:
由于 A 主题 34 分区的 leader 副本在 broker0,另外一个副本由于速度跟不上 leader,已被踢出 ISR,0.11 版本的 kafka 的 unclean.leader.election.enable 参数默认为 false,表示分区不可在 ISR 以外的副本选举 leader,导致了 A 主题发送消息持续报 34 分区 leader 不存在的错误,且该分区还未消费的消息不能继续消费了。
此时的我已经在公司了,终于回来了,这一个多月我是怎么过来的么?我来跟你们唠嗑一下。
我是从 2 月 3 日到 2 月 24 日这段时间一直在家办公的,总的来说体验还是挺好,每天开早会,明确今天的任务,周一开周会确定本周工作要点,需要讨论的直接语音联系,除了见不到面,工作中跟平时没多少差别,其实国内已经有很多针对远程办公的软件了,相信经历过这次远程办公之后,国内不少公司都会对远程办公模式有了更深刻的认知。