Clik here to view.
Request Header Or Cookie Too Large
运营反馈 Nginx 报 400 错误，具体点说：Request Header Or Cookie Too Large。其实随便搜搜就知道可以通过加大 client_header_buffer_size 和 large_client_header_buffers 来解决问题，不过这里面有一些细节值得讨论，正所谓：知其然，知其所以然。 首先，让我们想想为何 Nginx...
View ArticleClik here to view.
记一次LVS/Nginx环境下的访问控制
偶然间，我发现 Graphite 显示服务器网卡流量呈锯齿状，于是查了一下 Nginx 日志，发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。 简单分析一下访问日志，很容易就能拿到了可疑的 IP 段，直接用 iptables 封杀： shell> iptables -A INPUT -s x.y.z.0/24 -j DROP...
View Article监控进程
有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。 实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的 Upstart 或者 Systemd 均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个...
View ArticleNginx带宽控制
有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。 好消息是 Nginx 提供了 limit_rate 和 limit_rate_after，举个例子来说明一下： location /download/ { limit_rate_after 500k;...
View Article如何统计Redis中各种数据的大小
如果 MySQL 数据库比较大的话，我们很容易就能查出是哪些表占用的空间；不过如果 Redis 内存比较大的话，我们就不太容易查出是哪些（种）键占用的空间了。 有一些工具能够提供必要的帮助，比如 redis-rdb-tools 可以直接分析 RDB 文件来生成报告，可惜它不能百分百实现我的需求，而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单，利用 SCAN 和 DEBUG...
View ArticleClik here to view.
监控Netstat数据
我的日常工作有很大一部分比重是处理各种网络问题。很多时候，面对突发故障，完全搞不清楚缘由，此时，一个完善的监控系统能起到事半功倍的效果。 一个好消息是「netstat...
View Article记一次Auto Increment故障
实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。...
View ArticleClik here to view.
一个Laravel队列引发的报警
一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。 首先通过「free -m」确认一下内存情况，发现用掉了 6893M，还剩 976M： free 然后通过「top」查看一下哪些进程占用内存多，通过「shift + m」按内存排序： top 虽然通过 free 命令我们能确认系统可用内存不足，但是通过...
View ArticleClik here to view.
实战Sentry
不管你用什么编程语言，都会面临如何处理错误日志的问题。很多程序员对错误日志放任自流，直到出现故障了才追悔莫及，如果问我怎么办，我会推荐 Sentry！ Sentry 是一个错误记录和聚合的平台，只要看看它漂亮的界面就会喜欢上它： sentry 关于如何安装 Sentry，官方文档里已经给出了详细的说明，建议大家仔细阅读，一般通过 Virtualenv 来安装...
View Article如何正确设置CRON定时任务
相信很多人看了标题后都会纳闷：设置 CRON 定时任务有什么难的？不过请相信我，正确设置 CRON 真的不是一件简单的事情！各位看官不妨听我慢慢道来。 关于 CRON，出镜率最高的一个问题莫过于：为什么手动执行一切正常，放到 CRON 里就不执行呢？实际上此类问题多半是因为环境变量导致的，答案就在配置文件里： shell> cat /etc/crontab SHELL=/bin/bash...
View Article手把手教你用Dropwatch诊断问题
老实说，Dropwatch 并不是什么新鲜玩意，很多年前霸爷就专门撰文介绍过它，通过它可以大概找出系统为什么会丢包，其原理就是跟踪 kfree_skb 的调用行为。不过虽然很多人知道它的存在，但是却并不知道如何具体使用它，所以我写下了这篇文字。 以 CentOS 为例，动手前需要了解系统的版本，并确保已经安装了对应的包： shell> uname -r...
View ArticleClik here to view.
SQL里是否可以使用JOIN
很多公司都禁止程序员在 SQL 中使用 JOIN，至于原因则出奇的一致：用 JOIN 慢。不过我从没见过谁来论证为什么用 JOIN 慢，结果这个人云亦云的结论越传越广，让我觉得是时候来讨论一下这个看似正确的结论了。 举个例子：查询最新的十篇帖子和对应的用户信息，用 JOIN 是这样的： SELECT posts.id, posts.content, users.name, ... FROM...
View ArticleClik here to view.
自动打Tag杂记
给一段文字标记 Tag 是一个很常见的需求，比如我每篇博客下面都有对应的 Tag，不过一般说来，Tag 是数据录入者人为手动添加的，但是对大量用户产生的数据而言，我们不能指望他们能够主动添加合适的 Tag，于是乎就产生了这样的需求：自动打 Tag。 实际上这已经属于 NLP 高大上的范畴了，不是我这种非科班出身的人所能掌控的。好消息是百度和腾讯都有 NLP 平台可供选择，坏消息是免费版的 API...
View ArticleLaravel专供：实现Schemaless
之所以要实现 Schemaless，主要是因为在线 DDL 有很多痛点，关于这一点，我在以前已经写过文章，没看过的不妨看看「史上最LOW的在线DDL解决方案」，不过那篇文章主要以介绍为主，并没有涉及具体的实现，所以我写了一个 Laravel 的例子。 首先创建测试用的 users 表，并且添加虚拟字段 name、address、level： mysql> CREATE TABLE users...
View ArticleClik here to view.
真假百度蜘蛛的甄别
虽然百度的口碑并不好，但是不可否认的是，它一直是中文搜索中的霸主，所以对大多数中小型商业公司而言，都对百度蜘蛛的抓取行为予以放行，不过还有很多非法的蜘蛛，它们会通过 User-Agent 把自己伪装成百度蜘蛛，此时如果单纯以 User-Agent 来判断是否是百度蜘蛛就不合适了。虽然网上能找到很多现成的百度蜘蛛 IP 段，但是并不能确认它们的准确性，所以我打算自己收集，进而甄别真假百度蜘蛛。...
View ArticleClik here to view.
使用Mitmproxy分析接口
对于服务端开发者来说，通过抓包分析接口是必备技能之一，常见工具有 Charles 和 Fiddler 等等，不过 Charles 是收费的，Fiddler 虽然是免费的，但是其 Mac 版还不稳定，本文使用另一个工具：Mitmproxy。 Mitmproxy 的安装没什么好说的，按照官方文档来就行了，不过需要注意的是，为了能够抓取 Https 请求，还需要安装证书：首先启动...
View ArticleClik here to view.
如何抓取汽车之家的车型库
实际上，关于「如何抓取汽车之家的车型库」，我已经在「使用 Mitmproxy 分析接口」一文中给出了方法，不过那篇文章里讲的是利用 API 接口来抓取数据，一般来说，因为接口不会频繁改动，相对 WEB 页面而言更稳定，所以通常这是数据抓取的最佳选择，不过利用 API 接口来抓取数据有一些缺点，比如有的数据没有 API 接口，亦可能虽然有 API 接口，但是数据使用了加密格式，此时只能通过 WEB...
View ArticleClik here to view.
买不起Alfred和Dash怎么办
对于码畜而言，如果使用 Mac 笔记本的话，那么 Alfred 和 Dash 基本属于必装软件，其中 Alfred 可以免费使用，但是高级的 Powerpack 功能需要付费，而 Dash 则更进一步，不仅要付费购买，连后续升级也要花钱。这点钱对于富人来说或许不算什么，但对我这种工薪阶层来说就不一样了，能省就省，于是我折腾了一个不花钱的替换方案。 说到这里，不得不提到 DevDocs，它集成了很多...
View ArticleClik here to view.
说说压力测试工具
系统写好了，能不能顺利上线？一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量，并且访问时段主要集中在早八点到晚八点，那么平均下来 RPS 大约是 22 次左右，不过用户的访问量通常不会很平均，假设峰值流量是平均流量的 3 到 5 倍的话，那么我们可以推断出项目要想顺利上线，RPS 至少应该达到 66+ 次，110+ 次更好。由此可见上线前用压力测试工具测试 RPS...
View Article