fqueue初步分析
这篇讲的是对国产开源消息队列 fqueue 的初步技术分析。作者将其定位为一个轻量级的 MQ，并直接对比了大家熟知的 memcacheq 和 Kestrel，指出它们都支持 memcached 协议。这使得熟悉 Memcache 操作的开发者可以快速上手。 文章的核心关注点在于 fqueue 本身的特性。作为一个“国产”方案，它或许在特定场景或社区支持上具有优势。其“轻量级”的特点，暗示它可能在部署、资源占用或运维复杂度上比一些重型消息队列更简单，适合中小规模或嵌入式应用场景。 作者在文中没有进行冗长的背景铺陈，而是将介绍和特点指向了项目的官方主页，将精力集中于自己的分析上。这种写法为想快速了解 fqueue 核心思想的读者提供了入口，项目主页也是获取最新信息和文档的直接渠道。
高性能EL――Fel探秘，兼谈EL
这篇讲的是对国产开源EL表达式引擎Fel的性能评测与介绍。文章从Fel近期的热度切入，提到其开发者lotusyu公开的性能数据，展示了它作为高性能EL的实力，并将其与此前温少开源的Simple EL进行了对比，认为二者性能“有的一拼”。作者并未止于单纯比较，而是借此引申出一个更令人振奋的观察：以Fel、fqueue（一个类似Kestrel的轻量级MQ）等项目为代表，国内开源项目的质量与开发者的水平正在稳步提升。 除了性能探讨，文章还顺带推荐了fqueue项目，并指向了作者此前的相关分析文章，为关心分布式中间件的读者提供了延伸阅读的线索。整体来看，这不仅是一篇技术工具介绍，更带着一份对国内技术社区蓬勃发展的欣喜与肯定。
MySQL小工具 之 压测Groovy
作者之前一直用Python的MySQLdb给MySQL压测，但在Linux环境下发现了性能瓶颈。为了解决这个问题，他选择用Groovy重新实现了这套工具。Groovy运行在JVM上，能够直接调用JDBC驱动，避免了Python封装层带来的开销，从而在压测时能更高效地给数据库施加压力。 这篇分享的不仅是一个工具的迁移故事，也涉及一些实用的改进。新版的Groovy工具支持简单的分表逻辑，可以更灵活地模拟真实业务中的数据分布。同时，它还能启用`useServerPrepStmts`参数，这意味着压测查询可以走服务端预处理，在更贴近线上高并发准备好的场景下，评估数据库的真实承载能力。 通过这个小工具的迭代，作者在解决自身需求的同时，也展示了在特定场景下语言选型带来的实际影响——当Python库成为瓶颈时，切换到JVM生态下的工具链，往往是直接有效的优化路径。
使用sysbench来测试Row Cache解惑
这篇讲的是很多人对MySQL的Row Cache存在误解，觉得它能显著提升查询性能。作者从实际测试出发，使用sysbench工具对开启与关闭Row Cache的场景进行了对比压测。 结果发现，在sysbench的典型测试模式下（oltp_read_write等），Row Cache几乎没有带来性能提升，甚至在某些情况下还有轻微下降。文章深入分析了原因：sysbench生成的测试数据通常是随机主键查询，这导致缓存的行数据很快被新数据挤出，命中率极低。 作者通过调整sysbench参数，比如使用顺序扫描或固定查询模式，才观察到了Row Cache的预期效果。这揭示了该缓存机制更适合特定工作负载（如频繁重复读取相同行），而对一般的OLTP场景作用有限。文章最后给出建议：在评估缓存收益时，务必让测试负载贴近真实业务特征。
easy_runner一个简单的压测程序
这篇讲的是作者如何从“HTTP压测工具应该足够简单又实用”这个朴素想法出发，亲手实现了一个名为easy_runner的轻量级压测程序。 文章的核心在于展示其实现思路：它没有依赖复杂的框架，而是用Java的线程池构建了一个清晰的模型。主线程负责解析参数、构建任务并分发给工作线程，而每个worker线程则独立地对目标地址发起请求、记录耗时与状态码，并最终汇总统计数据。这种“一主多从”的分工，既利用了多核CPU，又保证了压测逻辑的清晰。 巧妙之处在于作者用不多的代码就实现了并发控制、结果收集和简单的报告输出，让工具既易于理解又具备实际可用性。文章最后附上了运行效果，展示了如何对本地服务发起不同并发数的请求，并输出包括平均耗时、成功率在内的关键指标。 如果你在寻找一个源码清晰、易于上手或二次开发的压测工具，或者想了解一个小型并发程序是如何从设计到实现的，这篇文章提供了一个不错的实践案例。
Row Cache For Innodb
这篇讲的是MySQL InnoDB存储引擎中一个相对少被提及的缓存特性——Row Cache。它主要解决的问题是：当数据库运行在高性能存储（如SSD）上时，即使数据已加载到InnoDB的Buffer Pool中，某些特定模式的随机读操作依然可能因为锁竞争或其他因素，无法完全避免磁盘IO。 作者深入探讨了Row Cache的实现思路。它本质上是在Buffer Pool之上，为一行或多行数据构建的一个更轻量的、独立的缓存。其核心巧妙之处在于缓存生命周期的管理与淘汰策略，能够更灵活地适应只读或读多写少的热数据场景，从而进一步减少物理读。文章对比了它与传统Buffer Pool缓存行数据的异同，并给出了适用场景的判断依据：对于那些读取频繁但修改极少，且对延迟极度敏感的OLTP查询，启用Row Cache可能带来显著的收益。 总的来说，这篇文章为数据库管理员和开发者提供了一个优化高并发读性能的潜在工具，并阐明了其背后精巧的设计权衡。
Innodb 中 rec_get_offsets 的使用注意点
这篇文章深入探讨了MySQL InnoDB存储引擎中一个关键但常被忽视的函数：`rec_get_offsets`。作者从数据库记录的物理存储结构出发，详细解释了该函数的核心作用——根据记录格式计算其各列（字段）在内存中的偏移量，这对于从磁盘或缓冲池读取记录后正确解析其内容至关重要。 文章的精髓在于揭示了一个重要的性能优化细节：当记录已经存在于内存缓冲池中时，`rec_get_offsets` 的内部实现路径会发生变化。它不再需要执行耗时的磁盘I/O和复杂的格式解析，而是能够更高效地从缓冲池中的记录元数据里直接获取所需信息。作者通过分析源码逻辑，点明了这条“快速路径”的存在及其触发条件。 理解这一点，对于深入诊断与InnoDB缓冲池命中率、页面读取效率相关的性能问题具有实际意义。它提醒开发者，即使是在使用看似底层的API时，其背后的实现也充分考虑了缓存友好性，这种设计在高并发查询场景下能带来显著的性能收益。
zookeeper使用和原理探究（一）
这篇讲的是zookeeper的入门介绍与核心原理初探。作者从zookeeper的基本概念切入，阐明它是如何作为分布式应用的一致性服务基石，源于Hadoop生态并基于Google的经典论文设计而成。文章先从实际安装和简单使用操作入手，引导读者快速搭建环境并上手实践，让理论落地。 随后，内容转向zookeeper内部的重要一致性算法，可能对比了ZAB协议与其他共识机制如Paxos的差异：ZAB如何在崩溃恢复和消息广播阶段保障数据强一致，而Paxos更适用于异步网络下的民主决策。这种对比点明了各自适用场景——zookeeper更擅长需要严格顺序的协调任务，如配置管理或选主。 作者通过图示和代码片段，解释了zookeeper通过角色分工（如Leader和Follower）来维护集群状态的巧妙之处，不仅讲清“怎么做”，还剖析了“为什么有效”。作为系列开篇，它为后续深入源码和性能调优铺垫了扎实基础。
ConcurrentHaspLRUHashMap实现初探
这篇讲的是作者如何尝试实现一个线程安全的LRU缓存结构——ConcurrentHaspLRUHashMap。面对高并发场景下，既需要快速存取、又需要自动淘汰最久未使用数据的需求，现有的解决方案可能各有局限。作者的出发点很明确，就是探索一种能兼顾并发性能与LRU淘汰策略的全新实现。 文章的核心在于拆解这个混合结构的设计思路。它不像传统的ConcurrentHashMap那样只考虑并发存取，也不像简单的LRU列表那样忽略线程安全。作者需要在两者间找到平衡，比如如何用锁或CAS机制保证并发修改时链表顺序的正确性，又如何让哈希表与双向链表高效协作。文中可能会展示一些关键的同步控制技巧，或是性能权衡的具体考虑。 这种自定义容器的实现往往在框架或中间件中很关键。作者通过这次初探，不仅分享了具体代码，更传递了一种解决问题的思路：在复杂约束下，如何拆解需求、组合基础数据结构，并处理好并发细节。对于需要设计高性能缓存或理解Java并发容器原理的开发者来说，其中的实现考量具有直接的参考价值。
网络编程中Nagle算法和Delayed ACK的测试
这篇探讨的是网络编程中Nagle算法和Delayed ACK的冲突问题。Nagle算法的初衷是避免网络中充斥小数据包，通过合并小包来提高带宽利用率；而Delayed ACK则旨在减少ACK包的发送频率，通过捎带ACK或延迟发送来降低开销，同时防止糊涂窗口综合症。然而，当这两个机制同时启用时，它们可能相互抵触，导致数据传输延迟显著增加。 作者通过一系列测试，具体展示了这种冲突的表现。例如，在TCP连接中，Nagle算法会等待更多数据到达或收到ACK后再发送小包，而Delayed ACK延迟发送ACK，使得Nagle算法长时间等待，形成“死锁”效应，严重影响响应时间。测试数据揭示了在不同网络条件下的性能差异，指出在实时性要求高的应用中，可能需要禁用Nagle算法或调整Delayed ACK的定时器。 关键差异在于：Nagle算法侧重于发送端优化，Delayed ACK侧重于接收端优化；当它们协同工作时，反而可能破坏TCP的流畅性。这篇文章对比了这两种机制的适用场景，建议开发者根据具体应用需求进行权衡，比如在交互式系统中关闭Nagle算法，而在批量数据传输中保留。 通过这些分析，文章帮助读者理解如何在网络编程中避免这类性能陷阱，提升应用的整体效率。
基于OS信号实现Java异步通知
这篇讲的是如何利用操作系统层面的能力，来给Java应用补上一个“缺失”的功能——异步通知。 作者从一个实际场景出发：在纯Java环境中，实现一个不依赖Spring等特定框架的、轻量级的异步通知机制并非易事。为了解决这个问题，文章另辟蹊径，将目光投向了操作系统的信号（Signal）机制。 核心思路是，在JVM进程中，通过底层方法（如`sun.misc.Signal`）注册一个信号处理器。这样，当进程收到指定的操作系统信号时，JVM就能拦截并调用相应的Java回调方法。这相当于在JVM和操作系统之间架起了一座小巧的桥梁。 文章巧妙之处在于，它绕开了Java生态中常见的事件总线、回调接口等实现，直接借用了操作系统早已成熟、高效的异步事件分发机制。这种跨层次的方案虽然有一定平台局限性，但为需要极低依赖和快速响应的场景（比如进程健康监控、优雅停机触发）提供了一种直接而有效的工具。
java 安全沙箱模型详解
这篇讲的是Java安全体系的基石——安全沙箱模型。文章从一个核心概念切入：作为第一道防线的“双亲委派类加载模型”是如何工作的。它详细解释了类加载器在接到加载请求时，如何优先委派给父加载器，这种层层向上的委托机制，确保了核心类库（如java.lang.*）不会被用户自定义的恶意代码篡改或覆盖，从而守住了系统类加载的安全底线。 但这仅仅是沙箱模型的一部分。文章接着梳理了从类加载阶段的安全检查，到运行时环境对文件、网络、线程等操作的权限控制，共同构成了一个多层次的防御体系。作者将这些机制串联起来，展现了JVM如何像一个谨慎的“隔离舱”，既允许代码在其中运行，又严格限制其能力范围，防止不可信代码对宿主系统造成破坏。 理解这一模型，对于编写安全的Java应用、排查类加载冲突问题，乃至深入理解现代Java应用服务器的隔离机制都至关重要。
Java 6 JVM参数选项大全（中文版）
这篇系统梳理了Java 6 JVM所有非稳态参数选项的实用指南。作者基于SUN官方文档进行翻译，并补充了大量背景资料与原理阐释，旨在帮助开发者深入理解每个参数的含义与适用场景。 文章清晰区分了参数的使用语法（如-XX:+启用、-XX:-关闭），并详细列举了行为选项与性能选项。对于每个选项，不仅说明了默认值与平台限制，更通过关联知识点揭示了其底层逻辑。例如，在解释新生代收集担保（-XX:+HandlePromotionFailure）时，文章剖析了Minor GC的运作机制与担保策略的利弊；在介绍自旋锁优化（-XX:+UseSpinning）时，则联系了CAS与OS互斥锁的原理。 这份文档覆盖了垃圾收集器选择（如CMS、Parallel GC）、内存管理、类加载校验、线程优化及特定平台（如Solaris）设置等多个关键调优维度。对于正在进行JVM性能优化或需要精确控制运行时行为的工程师而言，它将是一份内容扎实的中文参考手册。
HBase性能调优
这篇讲的是 HBase 性能调优中一个非常实际的问题：官方文档虽然全面，但按主题叙述的结构让人在排查性能瓶颈时难以快速定位到具体的配置项。作者由此出发，以“配置项”为索引，对官方文档中零散散布的调优参数进行了系统性的重新梳理和整合。 文章不仅将分散的配置项集中呈现，方便读者按图索骥，还融入了作者在实际生产环境中的理解与补充。例如，它可能会详细解释 `hbase.hregion.memstore.flush.size` 或 `hbase.regionserver.handler.count` 这类关键参数背后的生效机制、默认值以及调整它们可能带来的连锁反应。这种以配置项驱动的重新组织，让原本线性的阅读变成了一个可快速查询的参考手册。 对于 HBase 运维人员或开发工程师来说，这种结构在面对性能问题时尤为实用。你无需通篇翻阅文档，而是能直接根据疑似瓶颈的模块，找到所有相关的旋钮并进行针对性调整。作者在末尾也坦言了自己的整理可能存在的不足，这种开放讨论的态度也让这份整理更具参考价值。
Cassandra和HBase主要设计思路对比
这篇技术解析从CAP理论出发，深入对比了Cassandra和HBase这两款经典NoSQL数据库的核心设计哲学。作者指出，两者分属CAP模型中的不同阵营：Cassandra基于AP理念，采用无主节点的对等架构，牺牲强一致性来换取无单点故障的高可用和线性扩展能力，其“最终一致性”模型对写入非常友好。而HBase则坚守CP阵地，依赖ZooKeeper维护强一致性，采用传统的主从架构，这使其在复杂事务和随机读取场景下更可靠。 在数据模型与底层实现上，文章剖析了差异的根源。HBase借鉴Google Bigtable，采用“表-行键-列族”的结构，底层依赖HDFS并使用LSM-Tree，优化了大范围扫描和顺序写入。Cassandra同样使用宽列模型，但其“分区键-聚集键”的设计更灵活，数据分布基于一致性哈希，配合LSM-Tree实现了高吞吐的写入和跨数据中心的复制。文章还特别提到了Cassandra在写入路径上对WAL（Write-Ahead Log）的取舍，这是其提升性能的关键设计之一。 最终，文章落脚于场景选型：如果你的应用是全球分布的、写多读少、且可容忍短暂的数据不一致（如日志、时序指标），Cassandra的简单与弹性是巨大优势。反之，如果业务需要强一致性、复杂查询或严格的事务保障（如用户画像、交易类中间数据），HBase稳固的架构则是更合适的选择。这种从设计源头到落地场景的贯通式对比，为理解两者差异提供了清晰框架。
Push Or Pull?
这篇文章探讨的是分布式系统设计中的一个经典决策：服务端主动推送（Push）还是客户端拉取（Pull）。作者从消息系统、配置管理中心到存储系统等多个典型场景出发，核心对比了这两种数据传递模型在实时性、资源消耗和一致性方面的关键差异。 图表清晰地揭示了各自的取舍：Push模型能实现数据的实时送达，适用于对延迟敏感的场景（如实时消息、告警通知），但它会给服务端带来持续的连接和计算压力；Pull模型则让客户端按需获取，降低了服务端复杂度且更适合批量或可容忍延迟的数据同步，但可能带来无效的轮询请求。作者并未简单评判优劣，而是引导读者思考架构选型的本质——你需要根据业务对实时性的要求、客户端规模与能力、以及数据一致性级别来做出权衡。 这篇分析最终落脚于一个实际问题：没有“最好”的模型，只有“最适合”的模型。它帮助开发者在具体技术语境中，厘清Push与Pull的设计哲学，从而为自己的系统做出更合理的架构选择。
HBase二级索引与Join
二级索引与Join是RDBMS的标配，但在HBase这类NoSQL存储里却一直是待解的难题。作者从这个核心痛点出发，系统性地探讨了如何在HBase之上构建二级索引并实现索引Join。文章不仅分析了需求背景，更像是一份技术方案的全景扫描。 内容覆盖了从早期探索到成熟实践的多种路径：包括HBase 0.19.3版本中短暂出现的原生二级索引、Facebook在实际业务中验证的复杂方案，以及当前官方主推的基于Coprocessor的实现。作者对每种方案的原理、适用场景和局限性都做了梳理，比如指出早期方案已不再适用，而Coprocessor方案则提供了更灵活、可扩展的编程模型。 对于正在面临相似技术选型的读者，这篇文章的价值在于它清晰地勾勒出了各个技术选项的优劣与演进脉络，帮助你在具体业务场景下，权衡性能、开发成本与维护复杂度，从而做出更合理的选择。
ZooKeeper解惑
这篇讲的是ZooKeeper客户端与集群交互的深层机制，作者从官方文档未明说的细节出发，基于源码拆解了连接建立、Session管理、ACL鉴权与Watcher重新注册的核心流程。 文章详细剖析了一个ZooKeeper对象如何启动线程打乱顺序连接服务器，Session的ID如何通过Leader的Server ID与时间戳保证唯一性，以及password的生成与校验竟巧妙地依赖随机数种子——Server并不保存密码，重连时用相同算法重新计算比对。在ACL部分，清晰解释了`digest`、`ip`、`auth`等内置Scheme的工作原理，并点明`CREATOR_ALL_ACL`在早期版本失效的根因。关于Watcher，还阐述了连接中断时如何通过`setWatches`包将未触发的监听器带到新连接上，保障了事件通知的连续性。 这些源于源码的洞察，对于理解ZooKeeper在分布式环境下的可靠性设计，以及排查连接、权限相关的问题，提供了非常扎实的内部视角。
做基础产品的体会
这篇讲的是在大型组织中负责“基础产品”的深刻体会。作者从一个现实场景切入：当公司规模扩大，总会有一些团队需要去开发那些支撑全局的通用工具或组件。这类产品或许不涉及最前沿的技术，但关键在于它们像水电煤一样，被无数下游业务依赖，用以实现各种功能。 作者的核心观点在于，这类看似“幕后的”工作，其实对技术人的综合能力要求极高。它不仅仅是完成一个功能那么简单。你需要深刻理解不同团队的、甚至有时是相互冲突的使用场景，在“通用性”和“灵活性”之间找到那个微妙的平衡点。你的设计决策，直接影响着整个公司相关功能的开发效率和稳定性。这意味着，除了技术实现，你必须投入大量精力进行沟通、建立规范，并持续维护与各业务线之间的信任关系。 这篇文章的价值，恰恰在于它剥开了基础产品工作的复杂性，分享了那些不常被讨论的“隐形挑战”。对于那些在做内部工具、平台建设或任何需要服务多方的通用模块的技术读者来说，其中的思考，比如如何规划演进路径、如何处理好“平台”与“应用”的关系，有着非常直接的参考意义。
理解Heap Profling名词-Shallow和Retained Sizes
这篇文章讲的是堆内存分析中两个常被混淆但至关重要的概念——Shallow Size和Retained Size。作者从MAT、YourKit等常见分析工具的使用场景出发，清晰剖析了二者的本质区别：Shallow Size衡量的是对象自身直接占用的内存大小，而Retained Size则评估了当这个对象被垃圾回收时，能够连带释放的整个对象树的内存总量。 理解这一差异对性能调优至关重要。仅看Shallow Size可能会误导我们，因为一个本身很小的对象（如一个缓存键），若持有着一个庞大的对象引用，其真正的内存影响需要通过Retained Size才能体现。文章指出，Retained Size才是评估对象真实内存开销、定位内存泄漏根源的关键指标。 在实际排查中，结合两者才能做出准确判断：用Shallow Size快速定位自身占用异常的对象，再用Retained Size分析其影响的范围与链路。这篇文章的价值在于，它把工具界面上这两个并列的名词，还原成了开发者在分析内存时需要建立的两层思考维度。