共 3 篇相关文章
这篇文章从Redis最核心的单线程模型出发，深入源码剖析了其“单线程如何处理高并发请求”的经典设计。作者没有停留在概念层面，而是直接带读者走进事件驱动模型（event-driven）的内部，拆解了aeEventLoop这个关键结构体是如何通过epoll/kqueue等系统调用，将网络I/O、命令执行、定时事件等任务高效串联起来的。 最巧妙的部分在于对“为什么单线程还能这么快”的源码级解释：所有操作都在内存中完成，避免了线程切换和锁竞争；同时，通过IO多路复用，单线程便能同时监听成千上万个连接。文章还结合了键过期（expires）和持久化（RDB/AOF）的触发逻辑，展示了这些后台任务是如何被精心安排在事件循环的间隙中执行，从而不影响主线程的响应速度。 对于想真正理解Redis“快”的本质，而不仅仅是听说其“单线程”标签的开发者来说，这篇源码分析提供了一个从实现细节反推设计哲学的清晰视角。它把一个复杂的系统，拆解成了一系列环环相扣的、优雅的代码决策。
这篇讲的是MySQL如何一步步建立起与客户端的连接，并完成身份验证的。作者没有停留在概念讲解，而是直接从源码层面切入，把从TCP三次握手后开始的MySQL协议握手、到客户端发送用户名密码、再到服务端验证的全过程，像拆解机器一样展现了出来。 文章的核心思路是把整个过程分为两个清晰的阶段：首先是基于协议的连接建立与协商，这部分涉及协议版本、字符集等基础信息的交换；其次是更为关键的身份验证阶段。作者着重分析了MySQL的验证插件架构，尤其是经典的`mysql_native_password`插件如何工作——它不是简单传输明文密码，而是采用了一套“挑战-响应”机制，客户端用密码和服务器发来的随机数运算出一个结果再发回去，服务器用同样的算法验算，从而避免了密码在网络上的直接暴露。 最巧妙的一点在于其插件化设计。认证并非写死在服务器核心代码里，而是通过插件动态加载。这意味着你可以轻松替换或增强验证方式（比如实现更复杂的策略），而无需修改服务器主体。作者通过源码细节，让我们看到这种设计带来的灵活性与可扩展性。理解这套机制，是深入掌握MySQL安全管理与扩展开发的重要一步。
这篇讲的是作者在一次网络抓包时，意外发现他的PHP程序在访问Memcache时，总会多发出一个“version”命令，返回服务端版本号。这让他非常困惑，因为他明确记得自己并未编写相关代码。 为了解开这个谜团，作者决定深入Memcache客户端的源码一探究竟。通过阅读源码，他发现了真相：原来在客户端建立连接后，会自动发送一个版本查询命令。这很可能是客户端为了进行版本兼容性检查或内部管理而设计的隐式操作，开发者在使用时通常并不直接感知。 这个发现展示了一个有趣的技术细节：即使我们认为自己没有调用的API，底层客户端库也可能在默默执行一些辅助性工作。了解这些“隐藏”的行为，有助于我们更透彻地理解工具的实际工作机制，避免在排查问题时陷入类似的疑惑。
