最新 | 最热门 | 最高评价

+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条记录