最近帮客户配置服务器，经常修改Nginx的配置文件，频繁的用到正式匹配规则，这里整理了一些常用的正则参数及规则，以备查询。
Nginx配置中Location的语法规则 location [ = | ~ | ~* | ^~ | !~ | !~* ] /uri/{ … }
= 表示精确匹配
~ 表示区分大小写正则匹配
~* 表示不区分大小写正则匹配
^~ 表示URI以某个常规字符串开头
!~ 表示区分大小写正则不匹配
!~* 表示不区分大小写正则不匹配
/ 通用匹配，任何请求都会匹配到
匹配顺序
多个location配置的情况下匹配顺序为：
首先匹配 =
其次匹配 ^~
其次是按文件中顺序的正则匹配
最后是交给 / 通用匹配
当有匹配成功时候，停止匹配，按当前匹配规则处理请求。 继续阅读 »
过去很长一段时间一直认为在服务器端对用户进行访问限速会使用户的浏览体验变差，是一种负优化，直到最近才发现对用户进行合理的限速也能改善用户的访问体验。
事情还要从一个多月前说起，在例行进行服务器检查的时候，发现几台Nginx缓存服务器的带宽波动非常大，经常短时间内顶满带宽，然后又降回到非常低的水平，害的我强迫症都犯了，到底要不要增加带宽呢？不增加的话，带宽顶满对用户体验来说肯定是会有影响的，但如果增加了带宽，一半以上的时间带宽使用率又非常的低，显然老板不会同意。
还是先从日志入手吧，随手翻了翻几台缓存服务器的日志，基本可以确定带宽顶满的时候是在进行视频文件的请求，经过上一次的教训，现在所有的视频文件都是从缓存服务器上直接读取缓存文件的，每个视频文件大小基本都在30-50M之间的样子，倒也不算太大，但访问量上去了以后的带宽占用情况还是比较可观的，就算每台服务器平均有5个视频连接并发，按目前顶满带宽的情况下，每个请求差不多只要5-10秒的样子才能完全下载完成。
但项目上用到的视频又不多，大部分的时间其实是没有视频文件的请求的，但一旦有视频文件的请求，哪怕是只有一个请求，由于视频文件偏大，还是会在短时间内把带宽顶到满的，这就造成了部分用户访问项目出现忽快忽慢的情况。
问题原因找到了，解决起来也就简单了，因为大部分视频文件的时长都在1分钟以上，并不是所有的用户都会耐心的把完整的视频都看完，所以完全没有必要让用户在几秒的时间将完整的视频下载到本地，只要能让视频保证流畅播放就可以了。 继续阅读 »
在日常使用Linux服务器搭建Nginx+PHP网站运行环境中经常会碰到各种的报错，除了最常见的404错误以外5XX错误也是出现频率比较高的一类报错，一共包含下面几类。
500（服务器内部错误） 服务器遇到错误，无法完成请求。
501（尚未实施） 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
502（错误网关） 服务器作为网关或代理，从上游服务器收到了无效的响应。
503（服务不可用） 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。
504（网关超时） 服务器作为网关或代理，未及时从上游服务器接收请求。
505（HTTP 版本不受支持） 服务器不支持请求中所使用的 HTTP 协议版本。 继续阅读 »
手里有一个中型的网站项目，项目上的图片等静态文件使用自己搭建的多台Nginx服务器做缓存加速，不要问我为什么不用OSS等云存储，当有持续的大量的请求量的时候你就知道按流量计费到底有多坑。
由于考虑到部分图片及js等静态文件可能会有更新的情况，所以缓存的有效期设为了1个小时。也就是每过一个小时Nginx缓存服务器都会去重新请求一次源服务器，以获取最新版本的静态文件。
整套系统稳定运行了几个月以后，通过流量监控系统分析了历史数据发现源服务器的带宽使用一直保持在1-3M之间，偶尔突发流量也会不超过5M，本着够用就好的原则，就把源服务器的带宽调整成了5M（这就是给自己挖了个大坑，真是自作孽不可活啊）。
带宽调整完的几个月里，系统运行也还算稳定，带宽使用也都在正常范围内。就在上个月的一天凌晨，产品经理一个电话把睡梦中我的给召唤起来，说是网站图片加载缓慢。第一反应是Nginx缓存服务器的带宽不够用了，马上查了一下各个节点的带宽使用情况，都不高，或者说低的有些不正常，而且伴随有持续的下行流量，这就不对劲了。
前些日子在公司的仿真系统的内网搭了一台FreeBSD的服务器，用来做业务系统的状态监测，由于需要使用到nat服务，所以把IPFW也配置上了，为了调试方便，日志最大记录数习惯性的设置了不做限制。
服务器正式上线以后，一直运行稳定，昨天突然就远程连接不上服务器了，于是进机房接上显示器一看，乖乖，1T的硬盘硬生生就撑爆了，可用空间为0了。要知道这台服务器上几乎没有任何会使用大量磁盘空间的应用，只跑了个状态监测系统，看应用目录使用了还不到100M的空间。完全有点匪夷所思啊，排查了一下各个目录，发现问题出在log文件夹下的ipfw的日志文件，一个文件就上百G啊。。。这才意识到自己挖了多大的一个坑啊。
赶紧把日志最大记录数设置上，然后删日志，重启IPFW。然后查看了一下新生成的日志文件，终于找到原因了。
出于安全考虑，我的IPFW设置的是最大安全策略，也就是只开放了几个需要使用的端口跟协议，其他的一率deny掉，为了知道都deny掉了哪些数据，自然就要把deny规则上加上日志记录。这样的设置在互联网的环境上是完全没有问题的，我以前为很多客户的web服务器都是这样做的策略。记录到的都是一些非法扫描之类的异常信息，每天的日志一般也不会超过10M。
可偏偏我们业务系统内部通讯大量使用了组播通讯，这就导致了所有的组播包都被IPFW认真的在log里给记录了下来。目测了一下，每秒能收到几千个组播包，这硬盘不爆才见鬼了呢。
近期评论