libeio源码分析 – 主流程
这篇源码分析文章聚焦于 libeio 这个高性能异步 I/O 库的主流程，带我们深入其内核。作者没有泛泛而谈，而是直接拆解了从初始化、到请求提交、事件循环处理，再到回调执行的完整路径，清晰地勾勒出一个异步任务从诞生到完成的生命周期。 文章的核心亮点在于对 libeio 如何实现“异步”的剖析。它并非通过复杂的多线程，而是巧妙地利用事件循环和 epoll/kqueue 等系统调用，将 I/O 操作与回调解耦。作者具体分析了 eio_submit、eio_poll 等关键函数，揭示了请求队列的管理、工作线程的调度以及如何最小化系统调用开销等实现细节。这些内容让读者能直观感受到，一个优秀的异步库是如何在底层将复杂的并发问题，转化为一个高效、有序的事件驱动流程。 读完这篇文章，你不仅能理解 libeio 的内部工作机制，更能领会事件驱动模型在 I/O 密集型场景中的精妙设计思想，对编写高性能网络应用大有裨益。
linux后端服务程序之信号处理
这篇讲的是Linux后端开发中一个看似基础但至关重要的知识点：信号处理。作者从“信号是什么”切入，指出它本质上是进程间的软件中断，其核心特征在于异步性——事件何时发生，进程无从预知。 文章的重点，落在了如何为需要7x24小时不间断服务的后台守护进程（daemon）正确处理信号上。因为一旦处理不当，进程可能意外退出或陷入无法响应的状态，直接影响服务稳定性。 作者没有停留在概念科普，而是直接关联到实际开发场景，解释了为什么守护程序必须对信号建立一套严谨的响应机制。对于编写健壮的Linux服务程序而言，理解并妥善处理这些异步事件，是避免线上隐形故障、保障服务长稳运行的关键一步。
正则表达式的零宽断言
这篇讲的是正则表达式里一个容易被忽略、但极其强大的部分——零宽断言。文章从“如何匹配单词但不包括引号里的内容”这类实际问题出发，引出了正向与负向零宽断言的核心概念。作者没有停留在概念层面，而是用大量实例详细拆解了`(?=...)`、`(?!...)`、`(?<=...)`、`(?
write(2)在磁盘满的时候的行为
write(2)这个看似简单的系统调用，在磁盘满时的行为其实相当微妙，且容易让人困惑。这篇技术博客深入剖析了其中的关键细节。 文章的核心发现是，当磁盘空间耗尽时，write(2)并不总是立即返回错误。它的行为取决于几个关键变量：文件是否以`O_NONBLOCK`模式打开，以及写入的是否是常规文件或管道。对于常规文件，在非阻塞模式下，内核可能会先“接纳”数据，将其放入内核缓冲区，此时调用甚至可能立即返回成功，但随后的`fsync`或`close`才可能触发真正的空间不足错误（ENOSPC）。而更令人警惕的是，如果写入的是管道，并且使用`O_NONBLOCK`，write(2)可能直接返回`EAGAIN`，这意味着数据并未被写入，存在丢失风险。 作者详细拆解了内核`generic_perform_write`函数的执行路径，解释了这些不同行为背后的实现逻辑。这篇文章的价值在于，它澄清了开发者常有的“write成功即数据落盘”的误解，明确指出了在磁盘I/O的边界条件下，可靠性需要依赖更严格的检查（如fsync）和对不同文件描述符特性的深入理解。
玩转Protocol Buffers
这篇讲的是 Protocol Buffers 为何能成为众多开发者首选的数据序列化工具。作者从实际开发中数据交换与存储的常见需求出发，深入浅出地讲解了 Protobuf 的核心优势：相比 JSON 等文本格式，它采用二进制编码，体积更小、解析速度更快；其强类型特性和清晰的 `.proto` 定义文件，能有效减少前后端或不同服务间的沟通成本与歧义。文章详细对比了 Protobuf 与 JSON 在可读性、灵活性及性能上的关键差异，指出当项目对传输效率、内存占用或类型安全有较高要求时，Protobuf 是更优的选择。 此外，文中通过实例演示了如何定义 `.proto` 文件、利用工具生成对应语言的代码，并在实际项目中集成，展现了其跨语言支持的强大能力。无论是微服务间的 RPC 通信，还是需要高性能序列化的本地数据缓存场景，Protobuf 都提供了可靠的解决方案。通过清晰的对比和实战示例，文章不仅阐明了技术优势，也为读者在不同场景下选择合适的数据交换格式提供了实用指南。
离奇“undefined reference”错误分析与解决方案
这篇讲的是一个挺隐蔽的 C/C++ 链接错误排查故事。作者遇到的“undefined reference”并不罕见，但情况有点离奇：明明用 `-l` 指定了库，`ld -verbose` 也证实库文件能被找到，链接时却依然报错，找不到目标函数。 文章没有停留在表面现象，而是深入到了链接器的工作细节。作者从库的生成、链接顺序，一直追查到符号的可见性。最终发现的根因是，虽然库文件存在，但函数符号可能没有被正确导出（比如未在头文件中声明为 `extern "C"`），或者因为链接器处理库的依赖顺序问题，导致符号未能被正确解析。 这篇分享的价值在于，它超越了“链接库文件”的常规步骤，展示了当基础操作看似正确时，如何一步步从链接器的视角反向追踪问题。对于常和底层构建打交道的开发者来说，这种对工具链细节的深挖思路，往往能解决那些最让人头疼的“离奇”问题。
hadoop笔记 (2)：pipes例子分析 (1)
这篇讲的是Hadoop中一个相对小众但很实用的C++接口——Pipes。由于官方文档的缺失，作者选择了一条很实际的路径：直接从Hadoop自带的示例代码入手，一步步拆解其工作原理。 文章基于Debian 6 amd64和Hadoop 1.0.3的环境，没有空谈理论，而是带着读者走进具体的代码文件。分析的重点在于Pipes如何作为桥梁，让C++编写的Mapper和Reducer能与Java框架进行通信和协作。作者梳理了从任务启动、数据流传输到结果汇总的关键流程，揭示了框架背后如何用序列化和网络通信封装了分布式计算的复杂性。 对于想在Hadoop生态里使用C++，或者对跨语言RPC实现感兴趣的开发者来说，这篇从实际例子出发的梳理，比零散的片段信息更能帮你建立起对Pipes工作机制的整体认识。
分布式知识的总结(V1.0)
这篇讲的是分布式系统领域那些零散却至关重要的知识，如何被系统性地梳理成一张清晰的“全景地图”。作者从CAP、BASE这类基础理论出发，一路梳理到分布式事务、一致性算法、服务治理等具体实践中的核心议题。 文章不仅罗列了知识点，更侧重于厘清不同概念和方案之间的对比与取舍。比如，在探讨分布式事务时，它没有停留在理论，而是对比了2PC、TCC、Saga等模式在一致性、性能和复杂度上的关键差异，并指明了它们各自最适用的业务场景。这种从原理到选型建议的贯穿，使得这篇总结超越了简单罗列。 对于正在应对分布式复杂性的工程师而言，这更像是一份实用的指南和速查手册。它帮助你在面对具体问题时，能快速回顾相关的核心概念与主流方案的优劣，从而做出更合理的设计决策。文末对分布式知识未来的演进方向也给出了自己的思考，为这份V1.0的总结留下了开放的接口。
MogileFS 对大文件的支持
这篇讲的是作者使用 MogileFS 存储视频等大文件的实践经验与一个关键优化点。作者发现，MogileFS 本身对大文件支持不错，且文件越大，查询数据库的次数反而越少。 不过，他特别提醒：在上传超过4GB的大文件时，必须对默认的客户端参数进行调整。只需在 `new_file` 方法中加入 `largefile => 1`，客户端就会自动切换到底层不同的上传模块，从而支持 chunked 和 partial (Content-Range) 分片上传。这个简单的参数调整能显著提升大文件在 MogileFS 中的存放速度，对于需要混合存储海量小文件与超大文件的源站场景，是个值得掌握的实战技巧。
再一次, 不要使用(include/require)_once
这篇文章重申了在 PHP 开发中一个常见的争议点：**“不要使用 `include_once` 或 `require_once`”**。 作者从 PHP 一个历史悠久的扩展配置项 `apc.include_once_override` 的去留讨论切入，指出这个旨在优化 `_once` 函数性能的 APC 配置，长期以来都未能被完美实现，本身就反映了这类函数带来的复杂性和性能开销问题。 文章的核心观点在于，依赖 `_once` 变体虽然方便（无需手动去重），但它迫使 PHP 引擎在每次文件引入时都进行额外的“文件是否已引入”的检查与记录，这本质上是一种性能损耗。作者认为，在绝大多数场景下，通过清晰的代码结构和依赖管理（例如使用命名空间、自动加载或显式管理文件引入顺序）来确保文件不会被重复加载，是比依赖引擎去重更高效、更可控的做法。文章建议开发者重新审视自己的代码习惯，优先考虑使用普通的 `include` 或 `require`。
位置同步策略
这篇文章记录了一位技术团队成员在团队扩张期的真实工作状态与思考。作者正面临一个常见的挑战：当新同事陆续加入，团队需要进入协作磨合阶段时，个人的技术节奏该如何调整？ 他没有选择继续深入某个技术细节，而是将重心转向了维护已有模块，以及将之前的代码成果清晰地交接给新同事。这背后是一种务实的协作优先策略：在人力尚未齐备、团队需要建立共同认知的阶段，保证现有系统的稳定运行和知识的顺利传递，比个人攻克一个新问题更具价值。 作者的选择揭示了技术工作中一个常被忽视的维度：个人的技术产出需要与团队的实时节奏相协同。他为我们提供了一个视角——在项目或团队的成长期，适时从“个人沉浸模式”切换到“团队支持模式”，本身就是一种重要的技术判断力。这对于同样面临团队协作与个人技术成长平衡的读者，或许能带来一些具体的启发。
AOI 服务的设计与实现
这篇讲的是团队如何将一个 AOI（自动光学检测）服务从规划落到实现。作者从一次例会后的实际工作计划切入，点明了 AOI 模块开发的起点。 文章核心围绕“如何设计并实现一个可用的 AOI 服务”展开。它没有停留在概念，而是深入到了方案选型的思考：比如，面对具体的检测需求，应该选择何种图像处理与算法模型？系统架构上如何分层，以确保服务的稳定性、可维护性以及未来扩展性？作者分享了在平衡检测精度、实时性与计算成本时的关键决策，这些细节让设计过程显得非常真实。 在实现层面，文章提到了将设计落地为代码时遇到的具体挑战与解决方案。比如，如何处理来自产线的高并发图像数据流，如何设计模块以适配不同的硬件设备。这些内容使得整个设计不只是纸上蓝图，而是一个经过工程化考量的完整故事。 从规划到落地，这篇文章提供了一个工业视觉服务从 0 到 1 的实践参考，对有类似系统建设需求的团队来说，其中的技术权衡和实现路径值得借鉴。
Nginx默认虚拟主机如何在server中添加
这篇讲的是如何配置Nginx的默认虚拟主机，以应对用户直接通过IP地址或使用未正确解析的域名访问服务器时可能出现的问题。作者指出，这类访问如果处理不当，可能被导向错误的网站或暴露非预期内容，其关键在于在server配置块中明确指定默认主机。 具体解决方案是在对应的server段内，添加 `listen 80 default;` 这一行配置。该指令明确告诉Nginx，当收到请求的Host头与任何其他已定义的server_name都不匹配时，就使用这个设置了 `default` 标志的server块来处理。这样，所有无法识别的域名或纯IP请求都会被统一引导至此，便于集中管理和设定统一的拦截或跳转策略，避免了潜在的混淆和安全风险。这个小而关键的配置项，是生产环境中保证Nginx服务健壮性的一个常见实践。
MooC的一些设计思路
这篇讲的是作者在设计 MooC（大规模开放在线课程）平台时的一些思考路径。作者从实际教学场景出发，直面传统在线课程单向灌输、完课率低的核心痛点，核心思路是将课程从“观看的视频”转变为“可交互的学习项目”。 具体设计上，文章拆解了几个关键模块：如何把知识体系切分成颗粒度适中、可独立完成的“任务单元”，每个单元都配备可验证的实践目标（比如一段可运行的代码或一份分析报告）；如何利用轻量化的代码沙盒与即时反馈机制，让学习者能在“做中学”；以及后台如何通过学习行为数据，为助教提供干预依据。 最有趣的部分在于作者对“进度条”的重新定义——它不再只是视频的观看比例，而是综合了任务完成度、社区贡献与代码提交质量的动态学习画像。这种设计将评估点从“有没有看完”巧妙地转向了“能不能做到”，为提升在线学习的深度和留存率提供了一套扎实的实现方案。
计算机网络协议包头赏析-IP
这篇讲的是IP数据报的格式细节。作者延续上一篇对以太网帧的讨论，从数据链路层递进到网络层，具体解析IP协议头部的每一个字段。文章从IP版本号、头部长度、总长度这些基础字段说起，重点阐释了标识、标志和片偏移这三个与分片机制相关的字段如何协同工作，也解释了生存时间（TTL）、协议号、首部校验和等字段的设计逻辑与作用。 文中特别强调了IP头部中可变长度选项字段的处理方式，以及它如何影响数据报的解析。作者不是简单罗列字段，而是从协议设计的角度，分析这些字段如何在实际数据传输中承载控制信息、确保寻址、分片与重组，以及维持网络的健壮性。这种从基础协议格式出发的细致剖析，对于理解整个互联网的通信模型是很有价值的。
计算机网络协议包头赏析-以太网
这篇从校招面试官的视角切入，深入剖析了以太网数据帧的包头结构。作者发现许多求职者对底层协议的理解停留在理论层面，因此决定以最常见的以太网为例，逐个拆解其5个核心字段：从各占6字节的目标与源MAC地址如何定位设备，到2字节的类型字段如何区分上层协议（如IPv4或ARP），再到46至1500字节的数据载荷与4字节的CRC校验和如何保障传输的可靠性与完整性。 文章没有停留在枯燥的字段定义上，而是结合实际的网络通信场景，解释了每个字段在数据从网卡发出到交换机再到接收端的全过程中扮演的角色。比如，MAC地址如何在二层网络中实现精准投递，CRC校验如何帮助发现并丢弃传输中的错误帧。这种“赏析”方式，让原本生硬的协议头变得生动起来，清晰地展现了计算机网络分层模型中数据链路层的精巧设计。对于想扎实掌握网络基础、应对技术面试或进行网络编程的读者来说，这是一次非常透彻的底层探秘。
空指针的解引用
这篇讲的是C语言中空指针解引用的一个反直觉现象——通常会导致程序崩溃的NULL指针访问，在某些特定情况下居然可以成功。 作者从C程序员最常遇到的“空指针访问异常”问题切入，但并未停留在常规的排查层面。文章通过几个具体的代码示例，揭示了在内存布局、编译器优化（如 `-fno-strict-aliasing`）以及特定系统内存映射等条件下，对地址 0（即 NULL）进行读写操作反而不会触发段错误。这些例子直观地说明了“空指针不可解引用”这一准则在实践中存在的灰色地带。 文章的核心价值在于，它并非鼓励滥用这一特性，而是引导读者深入理解指针、内存模型与底层硬件交互的复杂性。作者指出，这种“可解引用”的情况高度依赖于平台、编译器和运行时状态，具有不可移植性，因此在生产代码中必须严格避免。对于想夯实C语言功底、理解系统编程陷阱的开发者而言，这篇文章提供了一个从反例中学习规范的好视角。
Skynet 设计综述
这篇讲的是知名游戏服务器框架Skynet的C版本从零构建过程。作者在一个月内完成了框架开发，期间对多个模块进行了反复重构，最终将代码精简至仅六千余行C代码与一千余行Lua代码。文章透露出作者对代码质量与可维护性的坚持：在紧凑的篇幅内保持清晰结构，以期后续Bug能够被快速定位与修正。这种对“小而精”设计目标的追求，展现了作者对底层框架工程化的深刻理解——用精炼的代码承载高并发的服务框架，本身就是一项充满挑战的设计实践。
7年之痒：读《谁偷了MySpace》
MySpace从如日中天到以3500万美元被甩卖，只用了七年。这篇讲的是这家社交网络巨头从2004年创立、2008年登顶，再到迅速陨落的完整历程。作者没有停留在表面的兴衰叙事，而是从这段商业兴衰史出发，深入探讨了一个核心问题：当技术优势面临商业决策失误、产品迭代停滞以及用户需求变迁的多重冲击时，究竟会发生什么？ 文章剖析了MySpace在巅峰期后所犯的一系列关键错误，比如对开放平台的谨慎、对用户界面复杂化的放任，以及被新闻集团收购后可能出现的文化冲突与战略摇摆。这些细节共同勾勒出一家公司如何被时代抛弃的轨迹。它提醒我们，技术产品的生命周期远不止于代码和架构，更在于其能否持续洞察并响应一个动态变化的用户生态。对于所有技术从业者而言，这不仅是回顾一个商业案例，更是一面镜子。
Dump Plugin并行化实践
这篇讲的是搜索Dump中心如何通过模块化设计，将原本串行的Plugin业务逻辑转变为可并行处理的架构。 文章的出发点很明确：在Dump中心服务化的项目中，数据产出被拆分为Loader（数据准备）和Join（逻辑计算）两个阶段。Join阶段需要处理各种复杂的业务逻辑，这些逻辑繁琐且容易出错，为了实现逻辑复用与解耦，团队设计了一套Plugin接口，允许不同的业务方将计算逻辑封装成独立的模块。 作者从这个Plugin架构的由来和设计讲起，核心聚焦于如何让这些Plugin并行化运行。这不仅仅是简单的多线程调度，而是涉及到对Plugin依赖关系的分析、执行框架的改造以及资源隔离等实际工程问题。文章具体描述了在现有架构上实施并行化的实践步骤与遇到的挑战，展示了从单线程顺序执行到充分利用计算资源进行并行产出的完整过程。 通过这次实践，Dump系统在Join阶段的执行效率得到了显著提升，处理大量业务逻辑插件的整体耗时大幅缩短，为下游数据消费提供了更及时的支持。