火丁笔记 -- IT技术博客大学习 -- 共学习共进步！

• 通过Twemproxy提升PHP/Redis的性能

Twemproxy 可以说是最古老的 Redis 代理软件了，一般来说，引入代理后性能会比没有引入代理时低一些，毕竟代理会导致一些额外的性能损耗，可是 Twemproxy 却会提升性能，这主要得益于它的 Pipelining 功能可以实现打包请求，简单点说：当代理收到多个并发请求时，它会把这些请求打包成一个请求发送给后端服务器，从而减少不必要的 RTT。关于 Pipelining 本文不做过多讨论，实际上我想说的是它的另一个功能：连接池！下面看看如何通过 Twemproxy 提升 PHP/Redis 的性能。

• 真假百度蜘蛛的甄别

虽然百度的口碑并不好，但是不可否认的是，它一直是中文搜索中的霸主，所以对大多数中小型商业公司而言，都对百度蜘蛛的抓取行为予以放行，不过还有很多非法的蜘蛛，它们会通过 User-Agent 把自己伪装成百度蜘蛛，此时如果单纯以 User-Agent 来判断是否是百度蜘蛛就不合适了。虽然网上能找到很多现成的百度蜘蛛 IP 段，但是并不能确认它们的准确性，所以我打算自己收集，进而甄别真假百度蜘蛛。

• 使用Mitmproxy分析接口

对于服务端开发者来说，通过抓包分析接口是必备技能之一，常见工具有 Charles 和 Fiddler 等等，不过 Charles 是收费的，Fiddler 虽然是免费的，但是其 Mac 版还不稳定，本文使用另一个工具：Mitmproxy。

• SQL里是否可以使用JOIN

很多公司都禁止程序员在 SQL 中使用 JOIN，至于原因则出奇的一致：用 JOIN 慢。不过我从没见过谁来论证为什么用 JOIN 慢，结果这个人云亦云的结论越传越广，让我觉得是时候来讨论一下这个看似正确的结论了。

• 一个Laravel队列引发的报警

一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。

• Nginx带宽控制

有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。

• 如何统计Redis中各种数据的大小

如果 MySQL 数据库比较大的话，我们很容易就能查出是哪些表占用的空间；不过如果 Redis 内存比较大的话，我们就不太容易查出是哪些(种)键占用的空间了。有一些工具能够提供必要的帮助，比如 redis-rdb-tools 可以直接分析 RDB 文件来生成报告，可惜它不能百分百实现我的需求，而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单，利用 SCAN 和 DEBUG 等命令，没多少行代码就能实现。

• 监控进程

有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的 Upstart 或者 Systemd 均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个 PHP 实现的 Worker 进程等等，如果你有类似的需求，那么可以考虑试试 Monit 和 Supervisor，相信会有不一样的感受。

• 记一次LVS/Nginx环境下的访问控制

偶然间，我发现 Graphite 显示服务器网卡流量呈锯齿状，于是查了一下 Nginx 日志，发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。

• 关于FIN_WAIT1

前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况....

• PHP优化杂烩

讲 PHP 优化的文章往往都是教大家如何编写高效的代码，本文打算从另一个角度来讨论问题，教大家如何配置高效的环境，如此同样能够达到优化的目的。

• Nginx缓存解决方案：SRCache

前些天帮别人优化PHP程序，搞得灰头土脸，最后黔驴技穷开启了FastCGI Cache，算是勉强应付过去了吧。不过FastCGI Cache不支持分布式缓存，当服务器很多的时候，冗余的浪费将非常严重，此外还有数据一致性问题，所以它只是一个粗线条的解决方案。对此类问题而言，SRCache是一个细粒度的解决方案。其工作原理大致如下。。。

• 通过FastCGI Cache实现服务降级

在自然界中，很多生物面临生死考验的时候，往往会做出惊人的反应，其中最为大家熟知的当属壁虎，危难关头，与其坐以待毙，不如断尾求生，通过自残来换取活下去的希望。对于互联网项目而言，同样存在着很多生死考验，比如：访问量激增；数据库宕机等等，此时如果没有合理的降级方案，那么结局必然是死路一条。

• 再叙TIME_WAIT

之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章，不过当时基本属于浅尝辄止，并没深入说明问题的来龙去脉，碰巧这段时间反复被别人问到相关的问题，让我觉得有必要全面总结一下，以备不时之需。

• 如何安全的Include文件

似乎多数人都觉得Include文件是一件非常简单的事情，可惜漏洞往往出现在我们忽视的地方。正所谓千里之堤溃于蚁穴，二战期间，法国人寄希望与马奇诺防线，却忽视了原本认为非常安全的阿登高地，让德国人有机可乘，最终的结果大家都知道了。

• 监控Netstat中的TCP数据

通过netstat命令，我们能获取TCP数据，监控它们有助于了解系统状态。如果netstat版本比较老的话，那么运行时可能会遇到类似下面的错误信息： error parsing /proc/net/netstat: Success 假设操作系统是CentOS，首先让我们看看如何确认netstat隶属于哪个软件包。。

• 记我配置Nginx代理的遭遇

我一直觉得自己的Nginx知识还算过得去，可是我错了，配置Nginx代理的遭遇让我苦不堪言，即便如此，我还是挣扎着记录一二，以便让后来者能够踩着我的足迹继续前进。说起来非常简单：某项目的搜索功能升级了，需要把请求从旧的服务代理到新的服务上面去，其中有点儿不一样的地方是参数的传递形式发生的变化，例子如下。。。。

• Web框架与太阳系

古语有云：工欲善其事，必先利其器。对于Web开发亦是如此，不过现在的Web框架实在是太多了！以PHP为例，有CakePHP、CodeIgniter、Symfony，Zend，Yii等等，到底谁是最合适的？事实上过多的选择往往会让人陷入「乱花渐欲迷人眼」的窘境，这些年我一直游走在各种PHP框架之间，却始终没有觅得属于自己的屠龙刀，于是我决定自己动手，就像歌里唱的那样：不是你亲手点燃的那就不能叫做火焰。

• 简易云端Hosts的构建

如果大家记忆力不太差的话，那么应该会记得前段时间发生的全国性DNS解析故障：很多顶级域名被解析到了IP地址「65.49.2.178」，导致中国互联网瘫痪了几个小时。不过在那起事件里一些移动客户端应用得以幸免，其原因在于它们使用了云端Hosts。

• 跟我学Rsyslog

关于Syslog的内容我并不想多说，否则就偏离了主题，大家如果有不清楚的地方，可以参考鸟哥的Linux私房菜。虽然Syslog中规中矩，但是随着时间的推移，无论是功能还是性能，它都显得捉襟见肘，于是出现了：Rsyslog和Syslog-ng，它们都涵盖SysLog的常用功能，不过在功能和性能上更为出色，至于孰优孰劣是个仁者见仁智者见智的问题，鉴于多数Linux发行版均选择了Rsyslog，姑且让我随波逐流一次。