共 7 篇相关文章
这篇文章从作者封装Hive socket库时遇到的一个具体问题切入：如何处理底层`poll` API产生的事件。直接注入回调函数虽然直接，但容易引发异常、重入等不可控问题，且会加剧C/Lua边界的性能负担。 作者提出的方案是将事件及数据一次性返回给Lua层处理。为优化此方案可能带来的GC压力，他采用了一个预先传入的消息队列（一个空的Lua table）作为接收结构。在C层，通过高效的`rawseti`操作将消息逐条写入这个结构，并巧妙地利用一个缓存池来复用存储每条消息参数的小table，从而在系统稳定后避免了临时构建大型Lua表。 文章最后，作者还附上了一段极简的Lua消息队列实现代码，展示了其优雅的实现思路。整体而言，文章分享了一个从具体问题出发，在性能与可控性间权衡并最终优化实现的技术决策过程。
这篇讲的是一个线上 Erlang 服务器遇到的具体困惑：为什么按预期，客户端发送第 4 字节就该阻塞，实际上却到了第 7 字节才阻塞？作者从这个问题出发，深入剖析了 gen_tcp 的发送缓冲区与水位线（high_watermark/low_watermark）机制。 文章指出，理解的关键在于 ERTS 内部 port 的消息队列模型。发送数据（send）实质是向 port 发消息，当队列数据达到高水位线时，port 进入“忙碌”状态，调用者进程会被挂起，直到数据降至低水位线。文章结合参数设置详细推演了缓冲区与水位线的实际交互过程，并澄清了一个常见误解：高水位线更多是一个“软”限制，用于流程控制，而非精确的阻塞点；最终发送端的阻塞，很大程度上取决于接收端的 recv 行为。 作者通过源码与机制分析，将配置选项、内部数据流与观察到的行为串联起来，为理解 Erlang 网络编程中的流量控制提供了清晰的视角。
这篇讲的是一个名为FFLIB的C++框架，旨在简化分布式或多进程并发场景下的开发工作。 作者从实际工作中的高频痛点出发，比如繁琐的消息定义、异步逻辑处理、多线程管理以及后续的单元测试和性能优化等，这些是每个涉及并发的开发者都可能遇到的挑战。FFLIB的核心思路是提供一套统一的解决方案来应对这些复杂性。文章作为一篇教程，应该会介绍该框架的基本概念和用法，其核心机制可能建立在进程隔离与高效共享内存通信之上，从而在保证稳定性的同时提升性能。 通过封装这些底层细节，FFLIB的目标是让开发者能够更专注于业务逻辑本身，而不是被并发带来的各种技术杂务所困扰。文章最后可能引导读者如何开始搭建和应用这个框架。
这篇文章讲的是lighttpd在流量低峰期出现响应耗时异常长的排查过程。作者从线上监控发现CPU使用率飙升出发，通过top命令定位到lighttpd进程，再用strace深入追踪系统调用，发现大量时间消耗在内核模块操作上。进一步排查内核日志，找到了“task blocked for more than 120 seconds”的关键错误信息。 追查最终指向一个内核级的资源竞争问题，具体涉及进程调度与I/O处理的冲突。文章详细记录了从现象到根因的完整分析链条，包括如何利用常规Linux工具层层剥离问题，以及最终通过调整相关内核参数和lighttpd配置缓解了问题。整个过程体现了在看似“低负载”的表象下，系统瓶颈可能潜藏于意想不到的层面，对于处理类似隐蔽性能问题有直接的参考价值。
这篇讲的是，作者在一次系统排查中遇到了一个颇为棘手的现象：明明是远端客户端主动断开了连接，服务端的日志里却打印了一个查询失败的错误。然而从最终用户的视角看，整个请求的响应是完全正常的，这造成了内部监控与真实用户体验之间的“错觉”。 问题的根源，被锁定在了对epoll事件处理的细节上。文章深入探讨了EPOLLRDHUP这个事件标志位的作用。在默认的处理逻辑中，服务端可能并未精确区分“连接正常关闭”与“连接上发生错误”这两种不同的关闭原因，从而导致在对方正常FIN时，程序也走到了错误处理的分支。 作者不仅指出了这个容易被忽略的“坑”，更分享了如何利用EPOLLRDHUP来完善状态机。通过正确监听和处理这个事件，服务端就能准确识别出“对端已关闭写通道”这一事实，从而做出恰当的资源清理和日志记录，避免误报。文章从一次实际的困惑出发，最终落脚于对epoll底层机制更精细化的掌控，对处理网络编程中的边界情况很有启发。
这篇讲的是Redis高性能背后的核心引擎之一——其事件库的源码实现。 作者从每个高并发服务都离不开的异步事件处理模型切入，深入Redis源码，拆解了其精巧的`ae`事件库设计。分析清晰地展示了Redis如何用统一的抽象层，优雅地管理**文件事件**（网络连接、读写就绪）与**时间事件**（定时任务）。 核心的巧妙之处在于其事件循环（`aeMain`）的运转机制：它基于IO多路复用（如epoll）获取就绪事件，然后通过一个简单的分发器，按顺序调用对应的处理器。更值得玩味的是，Redis在单线程模型下，如何通过事件库将阻塞操作（如持久化）与主事件循环巧妙地协调与调度，保证了其单线程的极致效率。 文章没有停留在API使用层面，而是带着读者沿着代码逻辑走了一遍事件从注册、触发到处理的完整生命线，对于想理解“单线程如何做到高并发”的开发者来说，这份对底层调度的剖析，提供了非常直观的视角。
作者从Nginx在Linux平台高并发服务的基石——epoll模块切入，探讨的不是epoll原理，而是Nginx如何围绕它构建自己的事件驱动模型。这篇分析没有停留在函数调用层面，而是清晰地梳理了Nginx对epoll的封装与使用哲学。 文章的核心，是顺着Nginx的事件循环主轴，剖析其事件结构体如何承载连接信息、每个工作进程如何管理自己的epoll实例，以及一次请求的生命周期如何在epoll的“收”与“发”之间流转。特别值得关注的是，文中详细拆解了Nginx如何通过“惊群”问题的处理机制，确保了多个Worker进程能高效协作而不互相冲突。 这种自顶向下、聚焦于实现细节的剖析方式，让我们看到一个高性能服务器的设计并非魔法，而是将操作系统的异步IO能力，通过清晰的数据结构和精巧的流程控制，发挥到极致的艺术。理解了Nginx对epoll的这种“用法”，也就抓住了其处理海量并发连接的心脏。
