kafka

无论什么技术方案，都有好的一面，也有坏的一面。而且，每当引入一个新的方案解决一个已有的技术问题时，这个新的方案会带来更多的问题，问题就像一个生命体一样，它们会不断的繁殖和进化

工作中日日在扮演CRUD boy的角色，少有机会去实践高性能，高并发，高可用之地。所以突发奇想，能否通过解读业内如雷贯耳，但又经常接触到的开源中间件redis，kafka 等，去反推

在min.insync.replicas=1 + kafka只根据HW截断日志的情况下；主从分区，会存在已提交消息，在leader切换时；会丢失数据的情况；或者数据不一致的情况；

现如今公司内部岗位竞争激烈，靠被动涨薪，已经比前几年难了不止几个数量级。怎么办？趁年底到外部去主动出击，“运气好”，成功了，也能主动涨薪。可是最近出去面试都被揉捏的像一个麻花了

kafka 数据的高可靠和不丢失，是靠复制集来保证的。它高可靠和数据不丢失的前提是：只要还有ISR的复制集，就能保证数据不会丢失，并且是可靠的

在读完kafka官方文档，kafka设计里的消息交付语义一章后，给我的第一印象是内容很抽象，于是草拟和总结了给个副标题，并把相关内容进行了归类；有些生涩的句子，尽量用大白话和举例进行说明，并加入了总结

kafka 消息中间件 防重，防丢，防乱序的8股文，我都回答的很丝滑，最终却倒在了kafka为什么这么快的路上

伤心，kafka 消息中间件 防重，防丢，防乱序的8股文，我都回答的很丝滑，却倒在了kafka为什么这么快的路上

在读完 kafka官方文档，kafka设计里的持久化一章后，给我的第一印象是内容很抽象，于是草拟和总结了给个副标题，并把相关内容进行了归类；有些生涩的句子，尽量用大白话和举例进行说明。

由于简历的技术栈里，夸大似的写了精通kafka消息中间件，然后就被面试官蹂躏了kafka问题画像里的给种问题，佩琪快被揉捏成一个比春天开放的花儿还花的麻花了

生产端的应用层或者网络层有问题时，仅仅依靠生产端的回调机制和retries机制，并不能100%确保消息不丢失；如果要解决此问题，可以试试 记录消息发送状态+定时任务扫描+重试的机制

如果kafka被攻击了，或者被人白嫖了；想在分钟级别内，让kafka具备安全能力；那么本文能解决你的问题；

网络上不缺 零拷贝 这个技术话题的讲解；但能讲透这里面的一个知识点的，怕是很少。有些大而不全，有些专而不精。一篇国外2008年 讲零拷贝的文章；虽历经十多年 但作者对零拷贝里面transferTo 这

在小小的公司里面，挖呀挖呀挖。最近又挖到坑里去了。一个稳定运行多年的应用，需要在里面支持多个版本的中间件客户端；而多个版本的客户端在一个应用里运行时会有同名类冲突的矛盾。在经过询问chatGPT，百度

曾经解读过kafka生产端内存模型的设计；始终感觉有点偏向理论，这篇算出对之前理论性的设计论证，实践后的数据证据吧。如果要用一句话来总结这次的感悟和行动，想借用陆游的一句大家都很熟悉的绝句来描述：

在java和C++程序员之间有一堵内存的墙；墙外的人想进去；墙内的人想出来。我想我对java内存管理，经历了4个阶段； 看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水；看出了另外一

不是所有的工具都能号称是为应对大数据场景而产生的；kafka做为一款中间件，能比较好的融入大数据生态，kafka的研发人员有自己的独特设计和考虑在支撑这它。如果要编写一款网络应用程序，或者网络框架的工

如果要设计一款sdk去连接某个中间件，我希望能做到向kafka客户端一样的优秀；这些优秀的设计包括高性能线程模型的思考，能够提升吞吐量并且符合自身业务场景的异步批量提交；内存的重复使用避免频繁的GC；

本次kafka broker停服机器维修的本质，从应用技术的角度看，是对生产环境kafka集群 高可用的一次检阅。而这次检阅是被动的一次检阅，并不是由研发主动发起的。被动检阅，有点类似搞突击检测，但我