构建C1000K的服务器(2) – 实现百万连接的comet服务器
这篇讲的是作者如何从零实现一个支持百万并发连接的Comet服务器。在解决了系统内核参数调整的基础问题后，文章将焦点转向了具体的应用实现。 作者选择用C/C++和libevent来构建核心，重点在于如何高效管理百万级的连接与通道。一个巧妙的设计是：服务器启动时便预先分配好100万个通道对象，而动态的订阅者则通过内存池管理，这使得初始内存占用控制在24MB。 最吸引人的是文章展示的实测数据。通过逐步增加连接数进行压力测试，结果非常直观：每个Comet连接大约只消耗2.7KB内存。最终，在支撑100万空闲连接时，进程总内存占用约2.7GB，而CPU使用率维持在0%。这清晰证明了该架构在高并发、低活跃度场景下的高效性。 项目的代码已在GitHub开源，文章提供的测试方法和详细数据，为需要构建类似长轮询服务的开发者提供了一个扎实的参考范例。
构建C1000K的服务器(1) – 基础
当C10K问题已成为历史，作者将目光投向了更宏大的C1000K挑战。对于Twitter、微博这类需要维持千万级实时连接的平台，单机百万连接（C1000K）的能力能极大降低服务器集群规模。 这篇文章并没有直接给出某个框架或库的解决方案，而是从根源出发，剖析了限制C1000K实现的四大核心因素。作者以Linux为例，深入讲解了如何突破操作系统默认的“最大打开文件数”限制，给出了包括临时修改（ulimit）和永久配置（sysctl.conf， limits.conf）在内的具体方法与命令。文章还通过一个原始的C语言服务器程序，实际测量并验证了操作系统为维护百万连接所消耗的内存，将理论估算与实际开销结合起来分析。 作者强调，解决C1000K问题不能盲目追求新技术，而应先理清操作系统内核、内存分配与网络吞吐这些底层瓶颈。文中的系统参数配置和测试思路，为需要应对海量并发连接的开发者提供了切实可行的排查起点和优化依据。
Linux 安装 Nginx PHP fpm
这篇教程针对初学者在Linux下搭建Nginx+PHP环境时常遇到的依赖复杂、步骤陈旧的困扰，提供了一条从零开始、清晰简洁的实操路径。作者从建议使用Ubuntu Server系统出发，完整演示了从源码编译安装Nginx和PHP的全过程，核心步骤都配有明确的命令行代码。 文章不仅讲解了如何让Nginx和PHP-CGI协同工作的基础配置，更关键的是，它指出了临时运行与生产环境的区别，并详细说明了如何通过PHP-FPM配置守护进程，实现更稳定可靠的部署。此外，教程还涉及了单独编译安装PHP扩展模块（如sockets）这一实用技巧，使读者无需重新编译整个PHP即可按需添加功能。 整体而言，这是一篇注重实战、步骤连贯的现代指南。它强调方法的简洁性与可用性，并承诺会保持内容更新，对于希望快速搭建起标准Web开发环境的新手来说，提供了扎实且可跟随的步骤。
小心 int 乘法溢出!
这篇讲的是 C/C++ 编程中一个隐蔽却危害巨大的陷阱：32 位 `int` 类型在进行乘法运算时可能发生的溢出问题。作者从一个实际场景切入——试图用 `malloc()` 分配 3000MB 内存时，代码 `mb * 1024 * 1024` 由于 `int` 只有 32 位，其计算结果早已溢出为负值 `-1073741824`。这个负值作为 `size_t`（64位系统中是64位无符号整数）参数传入 `malloc`，会被解释成一个天文数字（约 1844 亿亿），导致分配请求远超预期，引发程序崩溃或内存损坏。 文章特别点明，这种错误非常具有迷惑性，因为无论操作系统是 32 位还是 64 位，`int` 通常是 32 位的。作者以亲身在 SSDB 项目中多次踩坑的经历作为佐证，强调了问题的普遍性与现实危害。核心告诫在于：当运算结果可能超出 `int` 范围，尤其是作为内存大小等参数时，必须显式地进行类型转换或选用合适的数据类型（如 `size_t`），以确保计算的正确性与安全性。对于处理大数据的系统开发者而言，这是个值得时刻警惕的细节。
jQuery 设置复选框选中状态的 BUG
这篇讲的是 jQuery 开发中一个容易被忽略的“坑”。作者从一个过去一直正常工作的全选/全不选功能代码突然失效说起——使用 `attr('checked')` 设置复选框状态，代码却只在第一次点击时生效，之后无论怎么点击都无效，让人非常困惑。 经过反复测试，作者发现问题出在 jQuery 版本兼容性上。在新版本中，`attr()` 方法对 `checked` 这类布尔属性的处理与浏览器原生属性不同步，导致状态无法被正确切换和识别。文章指出，正确的做法是使用 `prop('checked')` 来显式地设置 DOM 属性，或者采用更直接的原生 JS 遍历赋值，以确保所有 jQuery 版本都能兼容。 这个案例典型地揭示了 jQuery 早期版本中 `attr()` 和 `prop()` 在语义上的一个重要区别：前者侧重于 HTML 属性（attribute），后者侧重于 DOM 对象属性（property）。对于像 `checked`、`selected`、`disabled` 这类状态属性，直接操作 DOM 属性才是稳定可靠的方式。
如何让 PHP json_encode 函数不转义中文?
这篇讲的是如何让 PHP 的 json_encode 函数在处理中文时不再输出 `\uXXXX` 形式的转义码。 文章开头就指出了一个常见的恼人场景：直接调用 json_encode，中文字符会被转义成看似“乱码”的 Unicode 序列。作者澄清，这并非 JSON 标准的要求，标准是允许直接保留 Unicode 字符的。根因在于 PHP 的 json_encode 在早期版本默认开启了转义。 文章核心给出两种解决方案。对于 PHP 5.4.0 及以上版本，可以简单地通过添加 `JSON_UNESCAPED_UNICODE` 选项来禁用此行为，这是最便捷的方式。针对无法升级的环境，作者则分享了一个自定义的 `Util::json_encode` 函数实现。这个函数递归地处理字符串、数组和对象，其核心思路是：当值是字符串时，手动处理必要的转义（如反斜杠、换行符），并直接将其包裹在引号中返回，从而跳过对中文字符的 Unicode 编码。文章最后也坦诚地提到，这个自定义实现在处理复杂的关联数组判断时可能未覆盖所有边界情况，留给读者根据实际情况调整。
网页适配手机移动版的CSS
这篇讲的是用几个关键 CSS 技巧，来解决网页在手机上显示错乱、需要缩放的问题。作者从实际移动端适配场景出发，给出了三个环环相扣的解决方案。 首先，要通过添加一个 `` 标签来禁止用户手动缩放页面，确保你的布局能按预设尺寸正常渲染。其次，用一条简单的 `img { max-width: 100% }` 规则，就能防止图片撑破容器，出现讨厌的横向滚动条。最后，对于表格、表单或内容容器，通过设置 `width: 100%` 并结合一个 `max-width`（比如 880px），可以让它们在电脑端保持合适的最大宽度，而在手机上则自动占满屏幕。 这三个步骤非常基础但极其有效，分别处理了视口控制、图片响应式和容器流式布局这几个核心问题，是快速实现移动端友好网页的实用清单。
TCP网络协议以及其思想的应用
这篇深入探讨了TCP协议核心思想的文章，跳出了单纯的网络协议讲解，聚焦于如何将TCP在不可靠网络上构建可靠传输的智慧，活用到更广泛的系统设计中。 作者从大多数程序员对TCP的熟悉但未必精通的状态切入，明确指出TCP的精髓是在IP层的不可靠传输之上建立可靠机制。其核心技术如滑动窗口、慢启动、指数退避等，目的都是优化传输。但更重要的，是它提供的设计范式。 文章强调，TCP的“可靠”是相对自身协议栈而言的，一旦跨越不同系统边界（比如从一个应用到另一个应用），就需要重新审视可靠性。因此，任何涉及通信与交互的场景，都可以借鉴TCP的思想。 作者提炼出了在任何通信系统之上构建可靠传输所必须的三要素：确认、重传和顺序。这为我们设计自定义可靠协议（例如在UDP之上）或解决复杂交互问题，提供了清晰且根本的思路。
Web 开发程序员谈网游服务器开发
这篇讲的是作者在参加一次网游开发团队交流后的思考。他敏锐地捕捉到，传统网游服务器开发因逻辑与存储高度绑定，往往忽视了动态扩展与容灾能力，而这些恰恰是Web开发领域的强项。 作者的核心观点是，网游服务器可以借鉴Web架构的“服务无状态化”原则。关键在于将服务拆分为“逻辑（指令）”和“存储（状态）”两部分。一旦逻辑层本身无状态，就能像典型的Web应用（如PHP + MySQL）一样，实现服务器的弹性增减。即使面对“用户切换服务器后状态丢失”这类网游特有疑问，通过分离设计和将存储层集群化，同样能构建出高可扩展、高容灾的系统。 这个视角为游戏后台架构提供了一条清晰的优化路径：用Web成熟的工程思想，去解耦游戏服务器的紧耦合状态。
用TAB缩进, 用SPACE对齐
这篇讨论聚焦于一个经典争议：编程时到底该用TAB键还是空格键来缩进？作者没有简单地站队，而是提出了一个清晰且实用的区分原则。 他指出，大部分情况下TAB和空格都能正常工作，但关键在于用途。对于代码的**缩进**，即行首的空白，TAB是更优解——只需按一次键就能统一缩进层级，避免了数空格的麻烦，也终结了“用两个空格还是四个”的无谓争论。 然而，文章真正的点睛之笔在于强调“对齐”的场景。为了代码的竖直对齐（比如让等号、注释在列上整齐），**必须使用空格**。作者展示了一段代码，清晰地说明了空格在此处的不可替代性，而这与缩进是两码事。 因此，文章最终给出了一个干脆利落的结论：**用TAB缩进，用SPACE对齐**。这相当于为TAB和空格找到了各自最合适的岗位，各司其职，既提升了编写效率，又保证了代码在需要精确对齐时的美观与可读性。对于被这个小问题困扰过的开发者，这篇文章提供了一个清晰的操作指南。
人人都用 Retina 屏幕的 MacBook Pro 笔记本电脑
这篇讲的是作者从个人使用 Retina 屏 MacBook Pro 的体验出发，强烈推荐这款笔记本成为每个人的首选。他认为，Retina 屏幕的高分辨率是核心优势——其像素数量是普通屏幕的 4 倍，通过将 12px 字体放大到 24px 并后退观看的比喻，直观展示了字体渲染的细腻效果。同时，作者强调 Mac OS X 的字体渲染技术天生适合高分辨率，低分辨率下视觉效果甚至不如 Windows 95，因此坚决反对购买非 Retina 屏幕的机型。 除了屏幕，作者将 SSD 硬盘视为性能关键，指出电脑速度的瓶颈早已是硬盘而非 CPU，批评 PC 笔记本常搭载慢速机械硬盘是“过时的骗人货”。在体验上，MacBook Pro 的即点即用、无风扇噪音和轻量设计，与 PC 笔记本的唤醒延迟和松散感形成鲜明对比。设计细节上，他推崇 MacBook Pro 的对称美学和完整质感，认为这超越了 PC 的拼凑感。 软件层面，作者欣赏 Mac OS X 的朴素界面，并指出 MacBook Pro 可用于 iOS 和 Android 开发，提供免费的 Xcode 环境。最后，他以成本效益论证：一台万元 MacBook Pro 相比占地费噪的台式机更具性价比，并预测苹果笔记本将持续领先多年。文章的核心启发是，选择笔记本时应优先考虑屏幕、SSD 和整体设计，而非盲目追求硬件参数。
在线状态服务在网站系统中的应用
这篇讲的是如何为一个百万级同时在线、日均亿级PV的网站构建高效的在线状态服务。作者从前篇Facebook聊天架构分析中提取出“在线状态服务器”这一通用模块，指出在普通网站中，它主要维护用户活跃列表，通常通过客户端定时发送心跳包来实现。 挑战在于，当用户量巨大时，服务需要承受极高的心跳包请求压力。文章对比了三种实现思路：最常见的PHP+MySQL方案会因数据库成为瓶颈；改用Redis虽能缓解存储压力，但PHP本身处理能力有限；最终，作者提出用C/C++开发专用HTTP服务器，整合精简协议处理与高速内存数据结构，结合libevent等库，有望在单机上轻松达到每秒万级请求的处理能力。 文章从实际性能瓶颈出发，逐步推导出一个针对性的技术方案，不仅分析了不同技术栈的优劣，也给出了具体的性能预期。文末作者还邀请有兴趣的开发者一起交流实现。
SSDB 配置文件
这篇讲的是如何理解和定制 SSDB 的配置文件。文章开篇就点明，默认附带的配置文件无需修改即可运行，但若需高度定制，了解其配置项就很有必要。 配置文件本身是层级 key-value 的静态格式，通过 TAB 缩进来表示结构，一目了然。文章逐一拆解了核心配置段：`work_dir` 指定了存放数据和日志的工作目录；`server` 段控制监听的 IP 与端口，出于安全考虑，可以将 IP 绑定为仅本机访问的 `127.0.0.1`；`replication` 段用于设置主从复制，明确了从服务器如何同步数据；`logger` 段管理日志级别、输出文件以及支持的大小轮转策略。 最值得关注的是 `leveldb` 段的配置。文章特别指出，`cache_size` 参数直接影响性能——适当增大缓存能提升读性能，但过大的缓存反而会拖慢写速度。这种基于实际使用场景的调优建议，对管理员来说非常实用。 总的来说，这篇文章将看似枯燥的配置文件讲解得清晰明了，不仅解释了“是什么”，还点出了“为什么”和“怎么调”，无论是初次接触 SSDB 的开发者，还是需要优化部署的运维人员，都能从中快速找到自己需要的配置要点。
谈谈Facebook的聊天系统架构
这篇讲的是Facebook在2009年公开的聊天系统核心架构。作者从一份内部PDF中的架构图出发，清晰地拆解了支撑数亿用户实时聊天的四个关键模块及其设计考量。 整个系统分为Web Tier（用PHP处理业务逻辑）、Chatlogger（C++开发的消息存储层）、Presence（C++编写的在线状态服务）以及Channel Cluster（基于Erlang和Mochiweb开发的服务器推送通道）。作者着重分析了每个模块的选型逻辑：Chatlogger需要应对海量历史数据，因此依赖Cassandra/HBase；Presence将用户在线状态全部存于内存以追求极致性能；Channel Cluster则通过保持长连接和本地缓存在线列表，实现了高效的实时推送，并减轻了Presence的压力。 文章不仅解释了“是什么”，还点明了“为什么”——例如为什么Presence不用PHP+Redis，为什么Comet服务器需要做二次开发。作者最后总结道，这个架构设计本身已经非常清晰透彻，但在实际应用中，仅靠整合现有开源组件远远不够，必须根据自身技术栈进行深度定制和二次开发，才能应对真正的规模化挑战。
JavaScript 设置浏览器标题闪动
这篇文章讲的是一个简单却实用的前端交互技巧：如何让浏览器标签页的标题闪动，从而在用户不看页面时也能有效提醒他们有新消息或内容更新。 作者直接给出了一个名为 `BlinkTitle` 的 JavaScript 类来实现这一功能。核心思路非常清晰：通过 `setInterval` 定时器，让 `document.title` 在一个新标题（如“新消息！”）和原始标题之间来回切换，制造视觉上的闪烁效果。代码实现中巧妙地做了备份和恢复，用户点击“停止”后，标题能立刻恢复原样。 这种方法不依赖任何库，代码轻量，非常适合嵌入到需要实时提醒的网页应用中，比如在线客服系统、后台管理界面或者任何使用 Ajax 长轮询的页面。当用户切换到其他标签页工作时，这个闪动的标题就能成为一个不容忽视的提醒信号。
Cocoa处理JSON转换, 兼谈计算机语言的哲学
作者从在Cocoa框架中使用NSJSONSerialization处理JSON转换时感到异常繁琐这一具体痛点出发，展开了一场关于编程语言设计哲学的讨论。他对比了Objective-C与PHP、JavaScript在核心操作上的体验差异：在PHP中，一个`json_encode()`与`json_decode()`就能直截了当完成任务；而在Cocoa中，开发者却不得不先处理NSData与字符编码的转换，并受限于顶层对象必须是数组或字典的约束。 这种对比引出了作者对“理想语言数据模型”的深层思考。他认为，字节数组（字符串）应统一且透明，数据本身是静态的，而解读方法才是赋予其意义的关键；映射表（字典）应保持“空间序”，即插入顺序即为可见顺序，这比无序的哈希表或强制的字典序对开发者更友好。他推崇像PHP和JavaScript那样，让最常用的操作（如数组操作）拥有最简洁的语法，避免为了所谓的“一致性”而让日常代码变得冗长。 文章并非单纯吐槽，而是在比较中提炼出语言设计的一些朴素原则：核心数据结构应与JSON等通用格式能自然映射，API应致力于降低常用场景的心智负担。最后，作者呼吁Cocoa开发者社区共同封装更易用的工具，并给出了一份融合类C语法、JavaScript数据模型及PHP/JS简洁API的“语言设计建议清单”。
苹果 Mac OS X 系统下锁屏的快捷键
作者发现了一个看似简单却被广泛误解的技术细节：Mac系统下锁屏快捷键。尽管在Windows上`Win+L`是常识，但许多Mac用户甚至网上教程都给出了复杂答案——或建议合上盖子，或引导创建脚本访问钥匙串，避开了直接回答。作者指出，这种“锁屏是Windows思维”的论调，反而让基础功能变得神秘化。 问题的根源在于，Mac默认未为“锁屏”提供类似Windows的全局快捷键，导致用户和内容创作者绕远路。文章的核心价值在于直接戳破这种信息差，给出最直接的解决方案：**同时按下`Control + Shift + Power (或Eject)`键**即可立即锁屏。这个组合键无需任何设置，真正做到了单手操作，堪比Windows的`Win+L`。 作者用略带调侃的语气批评了那些过度复杂化的回答，强调技术应当服务于效率。这篇短文提醒我们，在寻找技巧时，有时最简单的答案反而被忽视了。对于需要快速锁屏的Mac用户，记住这个快捷键组合就能解决问题，无需那些繁琐的教程。
LevelDB 的原理和动机
这篇讲的是LevelDB作为高性能键值存储系统的设计原理和动机。作者从持久化数据到硬盘的基本需求出发，解释了如何在实际场景中平衡写入速度和读取效率。 为了快速写入，LevelDB采用追加方式顺序写入日志文件（Log文件），这避免了随机写入的开销，但导致了数据无序。接着，为了从硬盘中高效读取数据，文章指出必须基于查找算法和局部性原理，将数据排序组织到SST文件（Sorted String Tables）中。 文章进一步探讨了为什么使用多个SST文件而不是单个。为了高效插入数据，每个SST文件只保存一定范围的数据，类似于堆的结构。更深入地，LevelDB引入层次（Levels）结构，将SST文件按层次组织，层次越深文件越多但合并频率越低，从而优化了数据合并过程，减少了每次合并影响的文件个数。 面对查找不存在数据时的性能瓶颈，文章强调了结合布隆过滤器（Bloom Filter）的重要性，利用其快速判定“不存在”的特性，避免了在每一层进行无效查找。通过这些层层递进的设计，LevelDB巧妙地解决了存储系统中写入、读取和查询的关键挑战，为读者提供了关于高效数据结构设计的实用思路。
宽带网络运营商劫持网站的技术分析
这是一篇关于宽带运营商劫持用户网页流量的深度技术排查记录。作者从自家网络出现异常弹窗广告入手，发现无论访问大小网站，网页都会被远程注入 iframe，导致浏览器右下角弹出无关的 Flash 广告。 文章的核心在于技术分析过程。通过直接发送 HTTP 请求而非依赖浏览器缓存，作者捕获了被篡改的完整响应包，揭示了运营商如何用一个“空壳”页面加载原始网站并侧载第三方广告脚本。更进一步，作者通过 Whois 查询追踪到广告域名（istreamsche.com）指向北京集奥众和公司，并在联系客服时发现，连运营商自家技术人员的办公网络也未能幸免，将问题根源指向了上级运营商或高层决策。 面对这种普遍存在的“流量劫持”，文章给出了一个切实可行的用户端解决方案：通过浏览器插件（如 User Agent Switcher）清空或修改发送给网站的 User-Agent 标识。由于大部分网站不依赖此字段进行功能判断，该方法能有效绕过运营商的劫持规则，恢复干净的网页浏览。
基于Redis构建系统的经验和教训
这篇文章从实际应用出发，讨论了Redis的优势与局限，并对比了其他海量数据存储方案。作者指出，Redis的有序集合（zset）等丰富数据结构使其在表达业务逻辑时极为高效，特别适合对性能要求高、数据规模可控的场景，比如消息传递系统的收发件箱。 然而，Redis“所有数据必须存放在内存中”的核心设计，直接导致了容量瓶颈和高昂的硬件成本。作者通过计算说明，对于一个百万级用户系统，数据量轻松超过单机内存极限。由此还引发了一系列问题：持久化时fork进程占用双倍内存，Aof日志写盘可能阻塞系统，以及不成熟的主从复制可能因网络抖动产生全量同步，严重消耗带宽。单机架构也迫使开发者在业务逻辑之外，必须额外设计复杂的数据分片方案。 面对海量数据，文章对比了Cassandra、HBase和MongoDB等方案。作者认为纯键值存储（如Cassandra）对结构化数据的表达能力太弱；而像HBase这类系统，其数据模型提供了更有序的组织方式。文章最终提出的观点是：理想的存储方案应当提供基础的有序数据结构，允许开发者通过“实体”加“有序子集”的方式来自然映射业务逻辑，从而在海量数据规模下，实现高效的数据访问与传输。 因此，Redis应定位在小而美的高性能缓存或结构化存储层，而非追求海量数据的存储目标。