关于大区间过滤优化内存设计
这篇讲的是在检索场景下，如何优化“大区间过滤”时的内存结构设计。作者指出，传统做法中以 docId 为下标存储域值的方式存在内存浪费，尤其在域值（如日期类型）重复率很高的场景下。 核心方案是引入两个互补的数组：第一个数组以域 Term 的遍历位置（Position）为下标，直接存储对应的域值，这利用了域值在遍历过程中天然有序的特点；第二个数组则以 docId 为下标，存储该文档在第一个数组中的对应位置。这样一来，大量重复的域值（例如“20101202”）在第一个数组中只存储一次，通过第二个数组的间接映射，就能为每个 docId 快速定位到其域值。 作者通过示意图和实际业务分析说明，对于时间这类重复率极高的域，该设计能显著压缩内存占用。整个方案的精髓在于通过空间换时间的思想，巧妙地将高重复的域值“去重”存储，并用一次额外的间接查找换取整体内存效率的提升。
关于两种限流模式
这篇讲的是高并发系统中两种主流的限流模式：滑窗模式与响应模式。滑窗模式是“事后统计”，通过检查过去多个单位时间窗口内的请求总量是否超标来决定是否放行。它的实现像一个环形计数器数组，逻辑直观，但阈值设定依赖经验或压测，且可能因单位时间请求分布不均导致“先松后紧”。文章指出，它更适合作为对单一资源（如数据库、特定API）的刚性保护承诺。 而响应模式则是一种“实时反馈”策略，它只关心当前正在处理的请求数。文章巧妙地指出了限流的根本目的——是保护系统资源不被拖垮。由于系统容量会受GC、依赖抖动等动态因素影响，响应模式通过公式（QPS/1000*RT）动态计算最大并发数，让限流阈值能随系统实际承载能力自动调整，展现了更强的适应性。 文章最后对比了二者的实现思路：滑窗模式基于数组和环形队列记录历史计数；响应模式则仅需一个原子计数器跟踪活跃请求数。这为在确定性资源保护和自适应系统保护两种场景下的选型提供了清晰的技术参考。
Linux/Unix的精巧约定两例及其简析：目录权限和文本行数
这篇技术文章深入浅出地拆解了Linux/Unix系统中两个看似复杂但设计精巧的约定，首先是关于目录权限的“执行”位。 作者指出，许多初学者对目录的执行权限感到困惑。实际上，它的核心含义是“穿越”：要操作目录下的任何文件（读、写、执行），或者对目录本身进行写操作（如增删文件），前提必须是拥有该目录的执行权限。这与普通文件的“执行”意义截然不同。 文章进一步揭示了其中的递归逻辑：要访问一个深层路径，需要从根目录开始，路径上每一个目录都拥有执行权限。作者用访问 `/home/foo/readme.txt` 的例子做了清晰推导，强调了根目录（/）的执行权限是访问起点的关键，这体现了Unix哲学中层层递进、权责明确的设计美感。 此外，文章还分析了另一个关于统计文本行数的约定。作者旨在说明，这些约定初看可能反直觉，但其内部逻辑统一且简洁，理解后能让人体会到系统设计的严谨性。对于想真正弄懂Linux文件权限底层逻辑的读者，这篇文章提供了非常清晰的视角。
MinHash原理与应用
这篇讲的是MinHash算法，一种基于Jaccard相似度的高效降维技术，专门用于处理大数据集的相似度计算问题。作者从Jaccard Index的定义出发，解释了直接计算集合交集和并集在海量数据下计算资源消耗过大，几乎不可行。MinHash的核心原理是通过随机哈希函数将集合元素映射为哈希值，并取最小哈希值作为签名，因为两个集合的最小哈希值相等的概率正好等于它们的Jaccard相似度，从而将高维数据降维为固定长度的签名向量。 文章进一步展示了MinHash的实际应用，比如在Mahout中用于聚类，以及在一个推荐系统案例中：针对几十万优质用户推荐给几千万普通用户，先用MinHash按相同哈希值个数排序筛选出备选集，再计算余弦相似度取TOPN。这种方法虽然在计算量上仍非最优，但在可接受时间范围内，效果接近两两计算余弦相似度的最优解，尤其适合集合量级差异较大的场景，如大规模用户推荐。
Java正则引发的思考
这篇讲的是一个由正则表达式引发的线上故障排查与深度分析。 作者从预发环境CPU不定时飙升至100%的问题出发，通过jstack分析，发现业务线程全部卡在正则匹配的代码上。排查发现，问题根源在于一段看似无害的用户输入，经过代码规范化后，形成类似“`.*.*.*.*.*.*.*Deliver`”的正则模式，与特定长字符串匹配时导致了“假死”。 文章深入剖析了Java正则引擎在“贪婪模式（greedy）”下的工作机制。作者用一个简化的正则“`.*.*.*.*D`”和36个字符的字符串为例，图解了引擎在遇到多个通配符“`.*`”时，会如何进行大量回溯尝试，最终指出其匹配步数会呈现指数级增长（公式为 `S(m, n) = n + Σ S(m-1, n-i)` for `i=1 to n-1`）。为了验证这一理论推导，作者还巧妙地运用ASM字节码注入技术，在JDK正则匹配的核心方法上埋点，实测了匹配步数，结果与理论计算完全吻合。 这篇文章的价值在于，它清晰地揭示了Java正则引擎在处理特定贪婪模式通配符时可能存在的性能陷阱。对于开发者而言，这是一个重要的警示：在处理外部输入构造正则时，必须避免此类多重通配符的模式，否则可能引发难以预料和排查的严重性能问题。
稳定性思考-强弱依赖2
这篇文章从一个实际问题切入：在微服务架构中，如何为弱依赖（如Cache）设置合理的“并发请求数阈值”？作者的分析思路很清晰，核心目标是实现高QPS下的资源消耗最小化，即“高QPS，少线程”。 作者通过一个Cache访问案例，结合公式 QPS=1000/RT * threadNum，做了生动的故障推演。正常时1个线程就能支撑400QPS；一旦Cache故障、RT飙升至3000ms，理论上就需要1200个线程，这会导致调用方线程池耗尽、频繁FullGC，陷入恶性循环。 为此，文章提出的核心方案是：限制访问弱依赖的线程数。例如，将阈值设为10。这样在上述故障中，调用方只会阻塞10个线程，整体服务保持正常，实现优雅降级。结合超时设置，能形成更有效的流控策略。 那么阈值设多少？文章给出了计算方法：根据可接受的RT（如100ms）和目标QPS（400）反推，得到 threadNum = 400 * 100 / 1000 = 40。作者也分享了经验数据：平均50ms的APP，阈值一般不超过60。文章最后点明，响应时间变长往往源于排队，而系统的最高QPS由瓶颈资源决定，盲目增加线程未必有用。
稳定性思考-强弱依赖
这篇讲的是系统稳定性中一个核心却容易被忽视的点：如何正确处理系统间的依赖关系。作者从淘宝复杂的系统依赖场景出发，将依赖清晰地划分为“强依赖”与“弱依赖”，并剖析了二者对系统稳定性的迥异影响。 对于强依赖，文章指出其风险在于“一荣俱荣，一损俱损”。除了主张通过扩展通道来解耦，作者更通过一个生动的分流压测案例揭示了关键发现：一个单机容量为4的系统，在被过载压垮后，其容量会急剧下降至约2.5，且自身难以快速恢复。这源于资源耗尽导致的线程堆积与频繁Full GC，深刻说明了对下游依赖系统进行“流量保护”的必要性。 文章接着探讨了更优的“弱依赖”模式。它细分为两种场景：一是主流程无需等待结果的异步化调用；二是需要等待结果但通过设置超时与最大并发阀值来熔断保护。这两种方式都能在B系统故障时，确保核心链路A的稳定运行。 整体而言，作者用从理论到压测实证，再到具体技术方案的递进逻辑，为如何设计高可用系统提供了极具操作性的指导。
ZooKeeper管理员指南——部署与管理ZooKeeper
这篇讲的是如何系统地管理ZooKeeper集群，而不仅仅是搭建起来。作者从ZooKeeper 3.4.3版本的官方管理员指南出发，但没有停留在照本宣科，而是融入了自身在生产环境中的运维实践经验。 文章清晰地划分了部署与管理两个核心部分。在部署方面，它深入讲解了关键配置项（如tickTime、initLimit等）的实际含义与调优原则；在管理部分，则涵盖了日常运维中最需要关注的健康监控、日志维护、数据备份与恢复等实战要点。作者特别指出，这不是一篇教你“如何快速搭建”的入门教程，而是面向已经或即将负责ZK集群运维的管理员，提供从配置细节到管理流程的深入参考。 通过结合官方文档的权威框架与一线踩坑后的经验提炼，这篇文章能帮助管理员少走弯路，更从容地保障ZooKeeper这一核心分布式协调服务的稳定性。
垂直搜索新问题
这篇讲的是垂直搜索场景中一个容易被忽视但日益凸显的矛盾：当大家还在痴迷于提升搜索速度时，数据服务质量本身，正悄然成为实时或垂直搜索中的新瓶颈。 作者从一个常见误区切入，明确区分了实时搜索与垂直搜索的本质不同。他特别指出，在垂直领域，实时性往往是一个更复杂、更待解决的问题，甚至打趣道“垂直搜索都不实时，其他的实时先排队吧”。文章没有纠缠于具体的代码或方案，而是聚焦于描述这一抽象但普遍的现象，强调解决问题的第一步是先建立起清晰的“问题意识”。 文章坦言，这类问题往往与具体场景深度绑定，不存在放之四海而皆准的最佳方案。但它给出了一个重要的视角：承认问题的特殊性与复杂性，比急于套用通用解法更为关键。在技术问题泛滥的当下，这种先精准定义问题、再寻求路径的务实思路，或许能为我们打开一扇不同的窗户。
Tomcat 5源码分析
这篇分析聚焦于Tomcat 5的内部世界，作者从启动入口`Bootstrap`类开始，一路追查到请求处理的核心链条。文章没有停留在泛泛的流程介绍，而是将分析重点落在了几个关键设计上：比如`Server`、`Service`、`Connector`这几个组件是如何被组装并启动的，它们之间清晰的职责划分；又如请求是如何从`Acceptor`线程进入，最终由`Worker`线程池分配给具体的`Container`进行处理的。 更深入的部分在于对`Valve`责任链的剖析。文章展示了像`AccessLogValve`和`RemoteAddrValve`这样的组件，是如何像套娃一样被依次嵌套调用，从而在请求到达实际应用前，完成日志记录、地址过滤等横切关注点。这种基于责任链的过滤器模式，在今天看来依然是架构设计的经典范例。 尽管分析的是一个较早的版本，但其中所阐述的**模块化拆分、线程模型设计以及基于链式处理的扩展思想**，对于理解现代Web容器乃至许多网络服务器的内核，依然具有很高的参考价值。作者通过追踪源码，将这些抽象的设计模式与具体的Java类对应起来，让阅读者能清晰地看到理论是如何落地的。
我感受到的排序机制参考
这是一篇关于搜索引擎排序机制的实战经验分享，作者从“打破神秘感”这一角度切入，澄清了外界对搜索排序技术门槛过高的误解。文章强调，理解排序机制的基本原理和整体流程是建立正确心态的第一步，能帮助开发者“心中不慌”，避免在入门阶段就被复杂细节困扰。 作者没有深入某个具体的排序模型，而是结合自身经验，给出了对排序机制的粗略认知框架。他指出，真正的难点在于如何将这些基本原理应用到具体场景中进行优化和调试。这种“先见森林，再见树木”的思路，旨在帮助读者建立清晰的认知地图，从而更有信心地面对后续深入学习和实际工程挑战。 对于希望进入搜索技术领域的读者而言，这篇文章的价值在于它提供了一种平实且有效的学习起点：先把握核心机制脉络，再聚焦具体问题。
关于二部图的再次思考
这篇讲的是二部图这个经典数学结构，在实际技术场景中的应用价值与认知差距。 作者的感触始于2010年在百度的一堂信息检索课。他第一次真切体会到，二部图并非离散数学中的抽象概念，而是支撑推荐系统、网络关系建模等核心场景的关键工具。然而，此后十多年里，当他向许多技术讲师询问相关实践时，对方的反应多是“吃惊”或“不清楚”。这让他深刻意识到，这个看似基础的概念，其实构成了从业知识结构中一个微妙的断层——有人早已在应用中得心应手，更多人却未曾深究其工程价值。 文章没有深入展开技术细节，而是通过这个个人观察，揭示了一个有趣的现象：我们对基础理论的认知深度，往往取决于是否有人将其与真实问题连接起来。对于希望拓宽技术视野、关注“理论如何落地”的读者而言，这个发现或许能带来一点启发。
Java Worker 设计模式
这篇讲的是Java Worker设计模式，作者从如何高效处理并发任务的问题出发，拆解了Worker模式的实现逻辑。核心是通过一个中心化的调度器管理一组工作线程，每个线程像“工人”一样从共享队列中拉取任务执行，避免了频繁创建和销毁线程的开销。 文章深入了实现细节，比如如何用`BlockingQueue`实现任务队列、线程池参数的动态调整策略，以及优雅关闭的机制。一个巧妙之处在于，Worker线程本身具备自愈能力——当某个线程因异常退出时，调度器能自动补充新线程，保持整体处理能力稳定。 作者还结合了实际案例，展示了在日志处理、图片转码等场景中，这种模式相比直接使用线程池能更好地控制任务优先级和资源隔离。实测数据显示，在突发流量下，基于Worker模式的任务处理延迟比无队列方案降低了约30%。
SolrQuery挖掘–单维度聚合分析
这篇讲的是作者如何挖掘 Solr 的查询能力，重点展开“单维度聚合分析”这个实用技巧。 作者从一个具体的业务需求出发：当需要快速统计某个字段（比如商品类目、用户地区）下的值分布情况时，传统的多次查询效率太低。Solr 的聚合功能，特别是 Facet，恰好能优雅地解决这个问题。 文章没有停留在概念介绍，而是直接演示了如何通过构建带 facet 参数的查询请求，在单次交互中就拿到该维度下的 Top N 分布、计数和百分比。作者还剖析了其背后的原理——这本质上是利用 Solr 的索引结构，在查询阶段并行完成了分组和计数工作，性能远高于数据库的 `GROUP BY` 操作。 这种单维度分析是构建多维报表和实时数据看板的基础。理解了这一步，很多复杂的实时统计场景就打开了思路。
深入理解Linux内存管理机制（一）
这篇讲的是Linux内存管理机制的演进与核心设计，作者从操作系统诞生初期的简单内存分配讲起，逐步深入到现代虚拟内存的复杂世界。 文章重点对比了分段、分页以及两者结合等不同内存管理方案。它分析了分段方案如何导致内存碎片问题，而纯分页又面临页表占用过多空间的挑战。核心在于剖析了Linux最终采用的“分页为主、分段辅助”的混合模型，以及其中关键的数据结构如页表、内存描述符（mm_struct）是如何协同工作的。作者还解释了MMU、TLB这些硬件加速单元在地址转换中扮演的角色，让虚拟地址到物理地址的映射过程变得清晰。 通过对这些底层机制的拆解，文章不仅展示了Linux内存管理的巧妙权衡——在灵活性、性能与开销之间寻找平衡，也为后续理解按需分页、内存交换等高级主题打下了坚实基础。读完会对操作系统如何高效利用物理内存有一个框架性的认识。
树与存储
这篇讲的是数据结构中最基础也最重要的“二叉树”概念。作者开篇就抓住了核心：二叉树的精髓在于“二分”，即每个节点最多拥有两个子节点的规则，由此衍生出满二叉树、完全二叉树等多种形态，是理解更复杂树结构的基础。 文章接着深入到计算机如何实际存储这棵树。关键对比在于两种经典方案：顺序存储和链式存储。顺序存储利用数组，逻辑上相邻的节点在物理内存中也连续，通过特定索引关系（如左孩子为2i+1，右孩子为2i+2）快速定位，适合完全二叉树这类结构紧凑的场景。而链式存储则更灵活，通过指针将分散在内存中的节点连接起来，能高效处理非完全二叉树或动态变化的树结构，是实际编程中最常用的方式。 这种存储方式的选择直接决定了后续遍历、查找等操作的效率和实现复杂度。文章通过对两种方式的剖析，清晰地揭示了抽象数据结构与具体计算机存储之间的映射关系，为读者后续学习二叉搜索树、堆等高级结构打下了扎实的基础。
(H2与HBase)面向行or面向列的存储模型?
这篇文章聚焦于一个数据库领域的核心议题：行存储与列存储的区别。作者以两个具有代表性的系统——内存数据库 H2 和大数据框架 HBase 作为切入点，来解析这两种模型。 文章清晰地指出了它们的本质差异：H2 采用经典的面向行存储，数据按行连续存放，非常适合事务性操作（OLTP），例如需要快速读写完整记录的场景。而 HBase 则是面向列族存储，数据按列族组织，同一列族的数据物理上存储在一起。这种设计带来了极高的压缩率和对海量数据的分析查询（OLAP）性能优势。 文章的价值在于，它没有停留在概念区分，而是具体分析了背后的工程权衡。例如，列存储在写入时因为数据分散会带来开销，但换来的查询性能和压缩收益在分析场景下是决定性的。通过 H2 与 HBase 的对比，文章生动地展示了没有“最好”的存储模型，只有“最合适”的模型，关键要看应用是侧重于高频事务处理，还是海量数据分析。
Solr\Lucene优劣势分析
这篇讲的是Solr和Lucene这对“父子”技术在实际选型中的关键差异。作者从两者的历史渊源出发，没有停留在简单的功能列表对比，而是深入剖析了各自的核心定位。 文章指出，Lucene是一个强大的底层库，提供了极致的灵活性和性能，适合需要深度定制、对资源控制要求高的场景，但它的使用门槛较高，需要开发者自行构建索引和查询逻辑。而Solr作为基于Lucene构建的企业级搜索引擎，开箱即用，提供了管理后台、分布式支持、缓存机制等丰富功能，极大降低了使用和运维成本，更适合需要快速上线、强调高可用和易于管理的业务。 核心结论在于：选择Lucene，意味着选择“引擎”和无限的定制可能；选择Solr，则是选择一台配置齐全的“整车”。文章帮助开发者理清了何时该驾驭核心组件，何时该利用成熟方案。
与Linux OOM-killer的第一次亲密接触
这篇讲的是作者如何在生产环境中第一次遭遇Linux OOM-killer，并从中梳理出完整的问题排查与应对思路。 故事从一台内存资源紧张的服务器讲起——某天核心服务进程意外被系统终止，日志里留下了“Out of memory: Killed process”的记录。原来，是系统的OOM-killer（内核在内存耗尽时用来释放内存的机制）“盯上”了这个进程。作者从这次被动的“遭遇”出发，详细剖析了OOM-killer的工作原理：它如何根据内存占用、进程优先级等参数计算出一个评分，从而选出“最该被杀掉”的进程。文中还原了当时内存不足的完整链路：从应用程序潜在的内存使用不合理，到系统overcommit设置可能带来的乐观假定，最终触发了OOM机制。 在解决问题部分，文章不仅演示了如何通过调整vm.overcommit_ratio等内核参数来“安抚”OOM-killer，还深入讲解了如何利用oom_score_adj为关键服务进程设置“免死金牌”，以及通过cgroups进行更精细的内存限制。作者最后总结，这次“亲密接触”让他认识到，理解Linux内存管理机制不能只停留在理论，更要结合监控数据与实际参数调优，才能主动规避而非被动应对OOM-killer的“误杀”。
Spark随谈——开发指南（译）
这篇指南针对的是Spark 0.5.0版本，它翻译自官方的Spark Programming Guide，并结合了一些作者的补充说明。它不是泛泛的概念介绍，而是从实际编程出发，详细讲解了如何在Spark中编写应用程序。 文章清晰地梳理了从初始化SparkContext、操作弹性分布式数据集（RDD），到进行转换（Transformation）和动作（Action）的完整流程。特别提到了RDD的两种创建方式、关键操作如`map`、`reduce`、`filter`以及持久化策略。这些细节对于刚接触Spark、希望快速上手编写的开发者来说，是很好的起点。 虽然版本较早，但其阐述的核心编程模型——基于RDD的函数式操作和惰性求值原理——构成了后续Spark SQL、Streaming等模块的基础。对于想了解Spark底层设计哲学或处理历史代码的开发者，这份指南依然具有不错的参考价值。