最新 | 最热门 | 最高评价
^..^

+0  谈谈Redis的SETNX

Tag: Technical | Redis
老王 发于 2015年09月14日 22:23 | 点击: 170 | 展开摘要
在 Redis 里，所谓 SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果，不过很多人没有意识到 SETNX 有陷阱！

比如说：某个查询数据库的接口，因为调用量比较大，所以加了缓存，并设定缓存过期后刷新，问题是当并发量比较大的时候，如果没有锁机制，那么缓存过期的瞬间，大量并发请求会穿透缓存直接查询数据库，造成雪崩效应，如果有锁机制，那么就可以控制只有一个请求去更新缓存，其它的请求视情况要么等待，要么使用过期的

查看全文: http://www.udpwork.com/item/15975.html
---

+0  Laravel队列的一些细枝末节

Tag: Technical
老王 发于 2015年07月31日 23:23 | 点击: 940 | 展开摘要
因为我崇尚简单，所以我憎恨一切所谓的「重量级」框架，比如「Laravel」，有时候这种憎恨甚至到了偏执的程度，以至于如果我看到简历里写着诸如「精通 Laravel」之类的话，那么便会毫不犹豫的 PASS 掉候选人。不过现在我承认有点喜欢「Laravel」了，虽然性能依然是无法回避的短板，但是又有几个网站能触及其性能瓶颈呢？而它丰富的组件则实实在在的节约了开发者大把的时间，比如本文要说的队列。

在 Laravel 里调用队列功能是非常简单的一件事情，详细介绍参考官方文档：

查看全文: http://www.udpwork.com/item/14451.html
---

+0  实战Sentry

Tag: Technical | Linux
老王 发于 2015年06月19日 17:29 | 点击: 1168 | 展开摘要
不管你用什么编程语言，都会面临如何处理错误日志的问题。很多程序员对错误日志放任自流，直到出现故障了才追悔莫及，如果问我怎么办，我会推荐 Sentry！

Sentry 是一个错误记录和聚合的平台，只要看看它漂亮的界面就会喜欢上它：

sentry

关于如何安装 Sentry，官方文档里已经给出了详细的说明，建议大家仔细阅读，一般通过 Virtualenv 来安装 Sentry，具体可以参考：学习搭建Python环境。

提醒：我在安装 7.5 的时候，测试有循环重定向，如果

查看全文: http://www.udpwork.com/item/14322.html
---

+0  一个Laravel队列引发的报警

Tag: Technical | Linux
老王 发于 2015年06月10日 17:43 | 点击: 915 | 展开摘要
一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。

首先通过「free -m」确认一下内存情况，发现用掉了 6893M，还剩 976M：

free

然后通过「top」查看一下哪些进程占用内存多，通过「shift + m」按内存排序：

top

虽然通过 free 命令我们能确认系统可用内存不足，但是通过 top 命令我们却没有发现有内存占用大户的进程，那么内存到底都去哪里了呢

查看全文: http://www.udpwork.com/item/14293.html
---

+0  记一次Auto Increment故障

Tag: Technical | MySQL
老王 发于 2015年05月30日 23:00 | 点击: 920 | 展开摘要
实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。

故障的来龙去脉大致是这样的：在一个月黑风高的晚上，苦逼的程序员被一阵急促的报警短信声惊醒，原来是数据库的某个表出问题了，虽然查询操作都正常，但创建操作却都失败了，经过调试，发现原因是表被插入了一行问题数据，其自增字段的值被显式的设置为整型的最大值，导致后续缺省插入的数据不能获取到一个合法的主键值。

我们不妨创建一个测试表说明问题：

CRE

查看全文: http://www.udpwork.com/item/14249.html
---

+0  监控Netstat数据

Tag: Technical | Linux | PHP
老王 发于 2015年04月09日 14:33 | 点击: 1279 | 展开摘要
我的日常工作有很大一部分比重是处理各种网络问题。很多时候，面对突发故障，完全搞不清楚缘由，此时，一个完善的监控系统能起到事半功倍的效果。

一个好消息是「netstat -s」里的各种计数器包含了很多有用的信息；一个坏消息是计数器记录的通常都是一些硕大无比的绝对值，不够直观。以前，我写过一篇的文章来介绍如何监控相关数据，但写得并不完善；最近，浏览文章时偶然发现一个工具，可以很方便的实时查询计数器相对值的变化情况，可惜不能方便的对接到监控系统里。既然现有的轮子都不太合适我的需求

查看全文: http://www.udpwork.com/item/14076.html
^..^

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

Tag: Technical | Redis
老王 发于 2015年03月25日 16:45 | 点击: 1982 | 展开摘要
如果 MySQL 数据库比较大的话，我们很容易就能查出是哪些表占用的空间；不过如果 Redis 内存比较大的话，我们就不太容易查出是哪些（种）键占用的空间了。

有一些工具能够提供必要的帮助，比如 redis-rdb-tools 可以直接分析 RDB 文件来生成报告，可惜它不能百分百实现我的需求，而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单，利用 SCAN 和 DEBUG 等命令，没多少行代码就能实现：

<?php

$patterns = arra

查看全文: http://www.udpwork.com/item/14027.html
---

+0  Nginx带宽控制

Tag: Technical | Nginx
老王 发于 2015年03月20日 17:28 | 点击: 1064 | 展开摘要
有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。

好消息是 Nginx 提供了 limit_rate 和 limit_rate_after，举个例子来说明一下：

location /download/ {
limit_rate_after 500k;
limit_rate 50k;
}

大概意思是：用户下载达到 500k

查看全文: http://www.udpwork.com/item/14007.html
---

+0  监控进程

Tag: Technical | Linux
老王 发于 2015年02月11日 16:08 | 点击: 1372 | 展开摘要
有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。

实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的 Upstart 或者 Systemd 均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个 PHP 实现的 Worker 进程等等，如果你有类似的需求，那么可以考虑试试

查看全文: http://www.udpwork.com/item/13849.html
---

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

Tag: Technical | LVS | Nginx
老王 发于 2015年01月23日 16:56 | 点击: 1378 | 展开摘要
偶然间，我发现 Graphite 显示服务器网卡流量呈锯齿状，于是查了一下 Nginx 日志，发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。

简单分析一下访问日志，很容易就能拿到了可疑的 IP 段，直接用 iptables 封杀：

shell> iptables -A INPUT -s x.y.z.0/24 -j DROP

本以为世界会就此清净，可没想到一点儿用都没有。莫非小偷已经突破锁头的限制？不能够啊！直觉告诉我问题应该和 LVS 有关，可

查看全文: http://www.udpwork.com/item/13795.html
^..^

+0  Request Header Or Cookie Too Large

Tag: Technical | AWK | Nginx
老王 发于 2014年12月31日 11:45 | 点击: 1297 | 展开摘要
运营反馈 Nginx 报 400 错误，具体点说：Request Header Or Cookie Too Large。其实随便搜搜就知道可以通过加大 client_header_buffer_size 和 large_client_header_buffers 来解决问题，不过这里面有一些细节值得讨论，正所谓：知其然，知其所以然。

首先，让我们想想为何 Nginx 不能用一个指令来搞定问题，而要用两个指令？为了搞清楚这个问题，我们不妨先看看官方文档的描述：

client

查看全文: http://www.udpwork.com/item/13701.html
---

+0  PHP优化杂烩

Tag: Technical | PHP
老王 发于 2014年12月25日 19:06 | 点击: 1268 | 展开摘要
讲 PHP 优化的文章往往都是教大家如何编写高效的代码，本文打算从另一个角度来讨论问题，教大家如何配置高效的环境，如此同样能够达到优化的目的。

pool

一个让人沮丧的消息是绝大多数 PHP 程序员都忽视了池的价值。这里所说的池可不是指数据库连接池之类的东西，而是指进程池，PHP 允许同时启动多个池，每个池使用不同的配置，各个池之间尊重彼此的主权领土完整，互不干涉内政。

pool

有什么好处呢？默认情况下，PHP 只启用了一个池，所有请求均在这个池中执行。一旦某些请求

查看全文: http://www.udpwork.com/item/13673.html
|<<<1234567>>>| 一共12页, 138条记录