适合小公司的 kafka日常管理脚本（上） 在小小的公司里，既缺巨牛，又缺物料，还缺必要的可视化管理工具。但这些不是工作路上的拦路虎；条条大路通罗马，但只选适合当下的路。面对小公司无统一的技术栈，也没有统一的管理工具，先选择最快的命令行工
适合程序员的DB性能测试工具 JMeter 天天写CRUD接口，到底写的这些接口性能咋样了？敢拿出来遛遛吗？JMeter可以让我们用数据来说话；我写的接口性能非常好，延迟小，吞吐量大。每个程序员都值得试试
中间件多版本冲突的4种解决方案和我们的选择 在小小的公司里面，挖呀挖呀挖。最近又挖到坑里去了。一个稳定运行多年的应用，需要在里面支持多个版本的中间件客户端；而多个版本的客户端在一个应用里运行时会有同名类冲突的矛盾。在经过询问chatGPT，百度
可以写进简历的kafka优化-----吞吐量提升一倍的方法 曾经解读过kafka生产端内存模型的设计；始终感觉有点偏向理论，这篇算出对之前理论性的设计论证，实际实践后的数据证据吧。如果要用一句话来总结这次的感悟和行动，想借用陆游的一句大家都很熟悉的绝句来描述：纸上得来终觉浅,绝知此事要躬行。
java内存管理 美好的期望与现实的残酷 在java和C++程序员之间有一堵内存的墙；墙外的人想进去；墙内的人想出来。我想我对java内存管理，经历了4个阶段；看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水；看出了另外一片天空
读kafka生产端源码，窥kafka设计之道（下） 如果要编写一款网络应用程序，或者网络框架的工具，我希望能向kafka一样，能考虑到内存的复用；并且减少对上层应用的影响。假设一个应用通过kafka发送50个G的网络数据；那么kafka的缓存池，就节约了10个G内存的申请和回收；由此减少了多少次GC和GC暂停时间了。那么假设有个50个这样的应用了？总的收益又是多少了？不是所有的工具都能号称是为应对大数据场景而产生的；kafka做为一款中间件，能比较好的融入大数据生态，kafka的研发人员有自己的独特设计和考虑在支撑这它。
适合小公司的自动化部署脚本 在小小的公司里面，快挖不动了，一件事重复个5次，还在人肉手工，身体和心理就开始不舒服了，并且违背了个人的座右铭：“偷懒”是人类进步的第一推动力。 每次想要去测试环境验证个新功
读kafka生产端源码，窥kafka设计之道（上） 如果要设计一款sdk去连接某个中间件，我希望能做到向kafka客户端一样的优秀；这些优秀的设计包括高性能线程模型的思考，能够提升吞吐量并且符合自身业务场景的异步批量提交；内存的重复使用避免频繁的GC；良好的封装性降低使用者心智负担；优雅的扩展性让用户能深度定制关键节点。不知道你在使用kafka客户端，或者了解的第三方客户端时，有哪些优秀的设计；欢迎评论区留言，共同学习和交流原创不易，欢迎大家点赞，收藏，转发 三暴击 ^^
生产环境 kafka 平滑迁移之旅 本次kafka broker停服机器维修的本质，从应用技术的角度看，是对生产环境kafka集群 高可用的一次检阅。而这次检阅是被动的一次检阅，并不是由研发主动发起的。被动检阅，有点类似搞突击检测，但我们比突击检测好的是，还可以有足够的时间为了kafka集群具备高可用，做必要的自检工作，准备工作，验证工作；也把这么多年欠的kafka高可用的技术债给还了。
浅析HTTPS中间人攻击与证书校验 0x00 引言随着安全的普及，https通信应用越发广泛，但是由于对https不熟悉导致开发人员频繁错误的使用https，例如最常见的是未校验https证书从而导致“中间人攻击”，并且由于修复方案也一直是个坑，导致修复这个问题时踩各种坑，故谨以此文简单的介绍相关问题。本文第一节主要讲述https的握手过程，第二节主要讲述常见的“https中间人攻击”场景，第三节主要介绍证书校验修复
[置顶] 读《http 权威指南后》，写的一个只有18K 大小的httpClient 前端时间，读了《http 权威指南》后，对自己掌握的技能和理论去实现一个简单的http client，心里有点摇摇欲试。大概用了几个小时，就用java写了个简单的http client实现。 目前对http get方法，post方法测试了，没啥问题（也支持http 其它方法）。对http response 报文的解析支持两种，一种是conten-length固定长度 body实
关注
