http keepalive
这篇讲的是HTTP KeepAlive机制的工作原理与正确配置。作者从早期每个HTTP请求都需要单独建立TCP连接的性能瓶颈出发，解释了KeepAlive如何允许在一个TCP连接上持续传输多份数据，从而显著减少连接建立开销、降低服务器内核调用与TIME_WAIT状态连接数。 不过，文章也明确指出KeepAlive并非“免费午餐”，配置不当的长连接反而会导致系统资源被无效占用，其损失可能超过重复建立连接。因此，正确设置`keepalive_timeout`参数至关重要。 作者通过编写脚本与`tcpdump`抓包，细致地分析了三种场景：关闭KeepAlive、开启KeepAlive（超时300秒）、以及在同一连接上发送多个请求（超时180秒）。测试清晰地揭示了TCP连接从建立、数据传输到最终释放的完整生命周期。一个关键发现是，`keepalive_timeout`的计时器是在最后一个HTTP响应发送完毕后才开始启动，并在每次收到新请求后重置。这意味着合理的超时设置需要在复用连接提升性能与避免资源长期占用之间取得平衡。
记一次tps提升,做的配置变更
这篇讲的是作者如何将一个php应用的TPS从120稳定提升至810的实战过程。 文章开篇直面问题：系统TPS低下、响应慢、并发能力差。作者从应用代码入手，借助xhprof定位瓶颈，优化了如避免高频内核调用、用memcached缓存数据等细节。随后，思路扩展到整个服务栈的配置调优。 在php层面，通过禁用不必要的模块、重新编译、配置php-fpm等方式节约资源。Web服务器Nginx侧，则涉及worker进程数、epoll模型、keep-alive、gzip压缩及静态资源处理等关键配置。更深层的，作者对操作系统进行了“瘦身”：精简守护进程、调整文件描述符限制、优化磁盘挂载参数。 整个过程的转折点在于对内核参数的精细调整。通过sysctl优化TCP连接、缓冲区等设置后，系统不仅TPS达标，性能曲线也趋于稳定。作者总结道，提升TPS的核心在于缩短单个请求的响应时间，并可通过strace等工具分析，从减少上下文切换和系统调用入手，最终实现更少资源开销下的更高吞吐。
Java将Object对象转换为String的总结合集
这篇讲的是Java开发中一个高频却容易出错的细节：如何将Object对象稳妥地转换为String字符串。作者直接从常见的三种转换方式切入——Object.toString()、强制类型转换（String）object，以及String.valueOf(object)。 文章没有停留在简单介绍，而是深入剖析了每种方法的“脾气”和陷阱。比如，直接调用toString()必须警惕null指针；强制转换看似语法正确，但在运行时可能因类型不符而抛出ClassCastException；而看似万能的String.valueOf()，在传入null时返回的是字符串“null”而非null引用，这个细微差别足以导致后续的判断逻辑出现严重错误。 作者通过源码片段和代码对比，把这些容易踩坑的点讲得非常透彻。后半部分还扩展到了Integer包装类与基本类型转换、不同进制间的转换，以及字节数组与数值类型互转等实用技巧，内容相当扎实。对于需要经常处理数据类型转换的Java开发者来说，这是一篇能帮你理清思路、避开常见错误的实用指南。
C的那些事儿
这篇讲的是C语言在Linux生态中的实践心得与工具推荐。作者从C语言作为许多人的编程启蒙谈起，指出尽管学习路径在演变，但C语言在Linux系统编程领域——如操作系统、数据库等高性能场景——仍占据着核心地位。 文章重点分享了提升C语言“品味”的具体路径。一方面推荐使用Source Insight这类静态分析工具，通过代码跳转、关系图等功能，在庞大的开源代码库中理清脉络；另一方面更推崇借助gprof和cgprof进行动态性能分析，生成可视化的函数调用图，直观展示函数调用次数与时间占比，以真实运行数据替代主观猜测。 作者还特别赞赏了Linux的管道（Pipe）机制，它让不同程序能够无缝衔接，实现了二进制层面的高效代码复用，这比单纯的语句级复用更为精妙。文中以通过管道串联grep、awk等命令为例，展现了这种设计的优雅与强大。 整篇文章并非泛泛而谈，而是结合了作者手边的函数手册、亲测有效的工具链（从编译选项`-pg`到生成调用图的完整流程），以及对Linux设计哲学的具体感受，为想在开源世界中精进C语言的读者，提供了一条清晰、可操作的实践思路。
腾讯分析系统架构解析
这篇讲的是腾讯分析（TA）系统如何应对日均处理上TB级数据、实现秒级更新的架构挑战。作者从数据采集到实时计算、存储的全链路出发，揭示了TA“数据全二进制化、计算全内存化、存储NoSQL化”的核心设计思路。 文章的重点在于其实时解决方案。在计算层面，系统借鉴了流式计算框架，采用增量计算模型，通过将所有数据类型转化为整型来大幅提升内存与计算效率。在存储层面，系统则巧妙地针对不同数据特性，组合使用Redis（高频更新的统计数据）和LevelDB（固定不变数据），并深度扩展Redis命令（如支持四则运算和批量字段更新）来优化查询与写入性能，显著降低了延迟与资源消耗。 此外，文中还详细阐述了其分片策略与双写复制等高可用设计。整个架构解析为构建高吞吐、低延迟的实时数据处理系统提供了清晰且可落地的思路，尤其对类似流式计算与海量数据应用场景具有参考价值。
Yupoo（又拍网）的系统架构
这篇讲的是国内最大图片服务商Yupoo又拍网的系统架构。文章没有空谈理论，而是直接列出其生产环境中使用到的具体技术栈，为读者提供了一个真实、可参考的大型互联网服务构建蓝图。 核心方案体现在对开源软件的组合运用上。操作系统层采用CentOS、Ubuntu等，服务器由Nginx、Apache、Squid共同处理请求；数据存储与缓存依赖MySQL、Memcached、Redis乃至Riak等多种方案；业务逻辑则由PHP、Python、Erlang等多语言实现。值得注意的是，其架构中还包含了Hadoop、Mogilefs用于分布式存储与计算，RabbitMQ处理消息队列，以及完善的监控（Nagios、Cacti）和任务管理（Redmine）体系。 这种“搭积木”式的架构，其效果在于通过成熟开源组件的高效组合，支撑起海量图片的上传、处理、存储与分发需求。对于技术团队而言，这份清单的价值在于它展示了一个经过实践验证的技术选型思路，而非单一工具的介绍。
fatcache源码浅析
这篇讲的是Twitter开源的缓存服务fatcache，可以把它理解为一个“SSD版的Memcached”。作者从其源码出发，剖析了它如何用有限的内存索引，去管理大容量的SSD存储。 文章详细解读了fatcache的核心设计。它使用通用的队列（generic queue）来管理资源池，底层则采用了经典的slab allocator内存模型。作者拆解了slabclass、slab和item等关键结构，并说明了fatcache如何在内存中用哈希表快速索引key，而实际的value数据则可能存储在内存或磁盘的slab里。 最精巧的部分在于其读写与淘汰机制。为了适配SSD，fatcache设计了一套基于FIFO的淘汰策略。在写入时，它能将内存中的slab成片地交换到磁盘，巧妙地将随机写转化为顺序写，提升了IO效率。对于删除操作，它只在索引层面标记删除，而不立即修改SSD数据，等待后续自然淘汰，这种设计充分避免了不必要的随机写入。 整个设计体现了对硬件特性的深刻理解，用相对简单的队列和slab管理，在缓存层实现了高效的数据存取。
SNS 背后的技术: 消息流的推拉模式选择
这篇文章深入对比了SNS消息分发的推模式与拉模式，从技术实现、资源消耗到用户体验进行了全面剖析。 作者从传统通信的推模式（如短信）在SNS场景下遇到的挑战切入，引出了拉模式作为更节省存储的替代方案。文章的核心在于辩证地分析了两种模式的优劣：拉模式在存储效率上能实现百倍级节省，并更有利于处理垃圾信息、好友关系变更、隐私权限修改等复杂的“删除与修改”操作；而推模式在保证信息即时性、减少登录后延迟方面有理论优势，但面临巨大的缓存维护成本和一致性挑战。 文章并未止于理论推演，而是结合了对Twitter、Facebook、新浪微博、QQ空间等主流平台的公开信息与现象观察，指出了各平台在推拉选择上的实际权衡。例如，新浪微博的拉模式有助于快速应对大规模删帖需求，而Facebook对离线用户采用拉模式则体现在登录时News Feed的短暂加载上。 最后，文章通过具体的数据模型计算，直观展示了在不同用户规模和行为模式下，推拉模式对缓存资源和网络开销产生的巨大影响。作者犀利指出，推模式下频繁的缓存修改操作会“让cache痛不欲生”，而一个设计良好的拉模式配合临时缓存，往往能在性能、成本与灵活性上取得更好的平衡。
Tomcat内存溢出的原因
生产环境中Tomcat内存设置不当容易引发各类溢出错误，这篇文章就系统总结了三种常见情况及其解决思路。 最典型的是Java heap space堆溢出，通常发生在98%时间用于GC且可用堆不足2%时。在无内存泄露的前提下，通过调整-Xms和-Xmx参数（建议设为相同值，如1024m）可解决，但需注意其上限受操作系统数据模型、虚拟内存及物理内存限制。 其次是PermGen space永久保存区域溢出，多因加载过多Class信息（如Hibernate、Spring框架动态生成类）导致。解决办法是加大-XX:PermSize与-XX:MaxPermSize参数，并需注意它们与-Xmx的总和不能超过系统最大JVM堆支持（如1.5G）。 第三种较为特殊，是unable to create new native thread无法创建新线程，这与JVM和系统内存分配比例有关。文章深入分析了JVM占用内存过多时，操作系统可用内存不足以创建更多物理线程的原理，并给出了线程数估算公式。此类问题需要同时调整操作系统与JVM参数。 作者从实际遇到的问题出发，不仅列出参数调整方案，还通过测试数据（如32位系统下堆大小限制）和原理分析（如线程创建机制）来支撑结论，强调需要根据不同溢出类型进行针对性诊断才能治本。
文件系统的树形结构改善构思
传统树形文件系统在管理一个文件属于多个分类时显得力不从心。要么得在多个目录下复制文件，造成空间浪费，要么就得忍受层级嵌套带来的繁琐点击。作者从这一痛点出发，提出了一个结合“标签”的改进思路。 核心方案是为文件系统增加一个自动生成的标签区。当文件被放入某个目录时，系统会为其打上该目录名的标签，同时也支持用户手动添加其他标签。这样，像《C/C++编程指南》这样的书籍就能同时关联“C语言”和“C++语言”两个标签，无需重复存储。 文章进一步探讨了两种访问逻辑：传统的树形目录用于文件管理，而标签则提供了另一种扁平化的快速索引路径。作者还设想了更人性化的交互——点击一个标签，文件管理器能直接打开包含该标签内容的相关目录，让访问路径更直观。 这篇构思主要在于抛砖引玉，探讨如何融合目录与标签的长处，来改善文件管理的体验。
PhpIniDir的应用以及php.ini-dist和php.ini-recommended的区别
在PHP配置管理中，PhpIniDir指令决定了php.ini文件的查找路径，这对环境部署至关重要。PHP5更新了查找顺序，优先检查PHPIniDir设置（仅适用于Apache模块），然后依次是注册表键值、环境变量、PHP或服务器目录，最后才是Windows默认目录。文章建议在Apache2中直接通过httpd.conf配置PHPIniDir，例如设置PHPIniDir 'C:/php'，同时提醒在NTFS系统上需确保服务器有读取权限，避免常见部署问题。 文章还对比了php.ini-dist和php.ini-recommended两个初始配置文件。php.ini-dist是PHP安装时的默认选项，适合开发环境，提供标准设置便于调试；而php.ini-recommended则增强了安全性配置，比如限制错误显示和潜在危险函数，专为生产环境设计。官方文档明确指出，php.ini-dist仅适用于开发，上线前应切换到php.ini-recommended，并参考PHP安全手册进行额外调整。 这种对比清晰指出了两者在场景适配上的差异，帮助开发者根据部署阶段选择合适配置，避免因误用开发设置而引入安全风险，强调了配置细节在PHP应用中的实际影响。
Erlang集群全联通问题及解决方案
这篇讲的是Erlang集群一个看似“贴心”但可能致命的设计：默认全联通。 作者从Erlang集群节点加入时的“引荐”机制讲起，新节点会被介绍给所有现有节点，从而建立一个完全连接的网状拓扑。问题在于，这种全联通连接数（N*(N-1)/2）会随节点数增加而爆炸式增长，不仅消耗大量系统资源，更因定期的心跳检测引发网络风暴，严重制约集群规模。 解决这个问题的方案出人意料地简单：在节点启动参数中加入“-hidden”标志，使其成为“隐藏节点”。如此一来，节点间的连接不会被主动发布，从而有效避免了不必要的全联通。 不过，作者特别提醒了一个关键细节：隐藏节点的行为是“或”逻辑——只要通信双方中有一方是隐藏节点，global模块就不会进行自动引荐。这个特性在实际部署和故障排查时必须留意。文章最后指出，社区已开始正视并规避这一设计带来的问题，对从事大规模分布式Erlang开发的工程师来说，这个经验颇具价值。
Erlang集群RPC通道拥塞问题及解决方案
当Erlang集群采用默认的全联通架构时，节点间通过RPC通道的密集调用可能引发严重的通道拥塞。文章从社区主流的分层服务架构出发，指出大量节点间消息流易导致dist端口忙，进而阻塞发送进程——由于RPC模块基于单进程gen_server，这种阻塞会直接拖累系统响应时间。 作者指出，这类问题可通过`erlang:system_monitor`的`busy_dist_port`事件及时感知，例如Riak系统便利用此机制告警。解决关键在于调整`dist_buf_busy_limit`参数：默认1MB的分布缓冲区上限可能不足，通过启动参数`+zdbbl`将其调大（如Riak案例中增至8MB），即可显著缓解阻塞、提升吞吐。文章结合监控实践与参数调优案例，提供了从问题定位到彻底解决的完整路径。
gen_tcp发送缓冲区以及水位线问题分析
这篇讲的是一个线上 Erlang 服务器遇到的具体困惑：为什么按预期，客户端发送第 4 字节就该阻塞，实际上却到了第 7 字节才阻塞？作者从这个问题出发，深入剖析了 gen_tcp 的发送缓冲区与水位线（high_watermark/low_watermark）机制。 文章指出，理解的关键在于 ERTS 内部 port 的消息队列模型。发送数据（send）实质是向 port 发消息，当队列数据达到高水位线时，port 进入“忙碌”状态，调用者进程会被挂起，直到数据降至低水位线。文章结合参数设置详细推演了缓冲区与水位线的实际交互过程，并澄清了一个常见误解：高水位线更多是一个“软”限制，用于流程控制，而非精确的阻塞点；最终发送端的阻塞，很大程度上取决于接收端的 recv 行为。 作者通过源码与机制分析，将配置选项、内部数据流与观察到的行为串联起来，为理解 Erlang 网络编程中的流量控制提供了清晰的视角。
编码规范集锦
这篇文章探讨的是编码规范——一套团队共同遵守的编码约定。作者认为，规范不仅仅是风格统一，更是构建健壮软件的基石。它能帮助新成员快速融入、减少低级错误，甚至防止滥用语言特性带来的隐患。 文章没有停留在理论层面，而是直接列举了几个业界著名的规范作为参考。比如，谷歌的风格指导因其同时剖析了建议的优点和局限而备受作者推崇；Linux内核那标志性的8空格缩进规则则令人印象深刻；而GNU规范则更全面地涵盖了编程中的一致性与错误预防。 作者通过这些具体例子说明，选择何种规范取决于项目和团队，但遵循一个成熟的规范本身，能大幅提升协作效率与代码可维护性。它让编码从个人习惯上升为可工具化、可文档化的工程实践。
为什么编码规范里要求每行代码不超过80个字符的限制是合理的
这篇探讨了Python编码规范PEP8中备受争议的“每行不超过80字符”限制。作者从实际编码体验出发，为这个看似过时的规定做了辩护。他认为，尽管我们早已摆脱VT100终端的小屏幕，但坚持这个限制能让代码更紧凑、可读性更强。 文章指出，Python语句本身通常只占35到60个字符，过长的行会破坏视觉平衡。通过合理的换行与空格，开发者能更直观地控制嵌套深度——这正是Python代码清晰度的关键。作者对比了两个函数示例：一个行宽无限制，需要横向滚动；另一个遵守80字符规范，结构一目了然。这种“约束”反而促进了代码的整洁。 另一个现实好处是屏幕空间的高效利用。当你在并排对比多个文件或函数时，80字符的宽度能确保所有内容都清晰地呈现在眼前，无需反复调整编辑器或担心自动换行干扰。即便在使用Django等框架时（其方法链调用很长），作者也坚持这一原则，以保证核心逻辑的可读性。 最终，作者强调，这条规范的本质是督促程序员将代码可读性置于首位。它不仅是历史遗留，更是一种有助于写出清晰、紧凑且易于团队协作的代码的实践哲学。
推荐一些socket工具，TCP、UDP调试、抓包工具
作者从Fiddler和Charles这些HTTP调试神器聊起，引出了对socket及TCP/UDP调试工具的需求。文章没有停留在理论，而是直接推荐了几款作者亲测的实战工具，并点明了它们各自的长处。 Wireshark依然是底层抓包分析的王者，但文章特意提醒了它可能按端口号自动解码协议带来的小烦恼。而国产工具sokit则更像一把“瑞士军刀”，作者重点介绍了它基于QT的跨平台特性、方便的二进制包组装能力，以及模拟分包/粘包和轻量级抓包的实用功能，甚至分享了自己曾因一个空格导致发送数据异常的真实小故事，这恰恰凸显了详细日志的重要性。 除此之外，文章还对比了体积小巧的TCP/IP Builder，以及能直观监控系统所有连接、帮助排查异常进程的Windows工具TCPView。整体来看，这篇推荐就像一份从实战出发的工具清单，帮助开发者根据具体场景——是深度抓包分析、快速调试协议，还是监控连接状态——选择最顺手的兵器。
gen_tcp如何限制封包大小
这篇讲的是如何在Erlang的TCP服务器（基于gen_tcp）中，从底层实现上来限制单个数据包的大小，以防范潜在的安全风险和资源耗尽问题。 文章从两种包接收模式入手。对于同步接收（{active, false}），作者指出，当使用gen_tcp:recv时，实际上内核会为接收分配一个缓冲区。通过源码可以看到，这个缓冲区大小存在一个硬编码的上限：TCP_MAX_PACKET_SIZE（64MB），一旦请求超过此限制，就会直接返回ENOMEM错误。这可以看作是系统级的防线。 而对于更常见的异步消息投递（{active, true}），控制则发生在协议解析层面。通过inet:setopts设置的packet_size选项，会在数据解析时被检查。文章通过追踪tcp_remain等函数的源码揭示了这一机制：当解析器发现包头声明的长度超过了设定的psize值，这个数据包就会被判定为无效。 核心巧妙之处在于，这两种机制一个在缓冲区分配时卡住，一个在协议解析时拦截，共同构成了对包大小的纵深防御。文章通过解读底层C驱动代码，让读者清晰地看到这些看似简单的应用层选项是如何被严格实现的，对于需要定制或深入理解Erlang网络编程的开发者来说，提供了扎实的内部视角。
Ruby的多线程应用服务器介绍
这篇讲的是随着Rails 4.0默认开启多线程模式，Ruby Web开发迎来了多线程服务器选型的新阶段。作者对三款主流选择进行了对比分析。 Rainbows和Puma都支持master-worker集群模式，能充分利用多核服务器。Rainbows脱胎于稳定的unicorn，提供了丰富的进程控制信号，适合对稳定性和运维控制要求高的大型应用。Puma的特色在于线程数可根据请求量在设定范围内自动伸缩，且单进程模式更节省内存，对中小型应用更友好。而Zbatery是极简的单进程多线程版本，是三者中最省内存的，适合在VPS上托管多个低流量应用。 作者的性能测试显示两者差异不大，选择更多取决于场景：追求稳定与可管理性选Rainbows，希望节省资源与灵活伸缩则Puma更佳。
解析Google集群资源管理系统Omega
这篇文章梳理了 Google 内部三代集群资源调度系统的演进，清晰地勾勒出从单体到分布式、从集中控制到共享状态的设计变迁。 文章首先回顾了早期“中央式调度器”的局限，即所有调度逻辑和资源管理都耦合在一个进程中，导致扩展性和新策略集成困难。为解决这一问题，以 Mesos 和 YARN 为代表的“双层调度器”被提出，它将调度策略下放到各个应用框架，中央调度器只负责资源推送。但这又带来了两个核心痛点：应用框架无法获知全局资源视图，从而无法做出更优决策；以及因为使用全局锁（悲观锁），并发调度效率受限。 为突破这两个瓶颈，Google 推出了 Omega 系统。它的核心创新是“共享状态调度器”：将全局资源状态作为共享数据，并采用数据库领域的“多版本并发控制”（乐观锁）来处理并发访问。这使得应用框架能主动查看全局状态并竞争资源，极大提升了调度灵活性和并发度。文章还具体对比了 Mesos 的“全有或全无”与 YARN 的“增量分配”两种资源授予模式在不同场景下的利弊。 最后，作者点明了一个对业界极具参考价值的观点：由于 Omega 与 Mesos/YARN 的主要差异集中在资源管理模块，因此可以通过改造开源系统的“Resource Master”部分来快速构建类似 Omega 的调度器，这对人力有限的公司来说是一条务实的技术路径。