最新 | 最热门 | 最高评价

+0  一个PHP实现的ID生成器

Tag: Technical | PHP
老王 发于 2016年11月03日 20:03 | 点击: 403 | 展开摘要
通常来说,不管使用什么数据库,表里都有一个名为 id 的主键,既然是主键,那么必然要满足唯一性,对于 MySQL 用户来说,它多半是一个 auto_increment 自增字段,也有一些别的用户喜欢使用 UUID 做主键,不过对 MySQL(特别是 InnoDB)来说,UUID 通常不是一个好选择,因为聚簇索引要求物理数据按照主键排序,而 UUID 本身是无序的,所以会带来很多不必要的 IO 消耗。于是乎我们得到一个结论:ID 最好是顺序的唯一值。

如此说来,就用 MySQ

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

+0  史上最LOW的在线DDL解决方案

Tag: Technical | MySQL | PostgreSQL
老王 发于 2016年11月23日 18:31 | 点击: 801 | 展开摘要
说起在线 DDL,最常见的操作莫过于在线加一个字段或者索引,不过如果数据量比较大的话,伴随而来的往往是长时间的等待,更要命的是系统在操作期间很可能会出现不可用的情况,所以一般只能等到凌晨操作,简直就是梦魇一般的存在。

在 PostgreSQL 中,如果注意使用方法,那么在线 DDL 并不是一个太难的事情。这里面说注意使用方法,指的是 PostgreSQL 跟其它一些数据库一样,在加字段或者索引的时候会锁住表,不过有一些技巧可以绕开此限制:

加字段:使用 ALTER TAB

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

+0  手把手教你用Sar诊断问题

Tag: Technical | Linux
老王 发于 2016年12月02日 15:18 | 点击: 1254 | 展开摘要
如今各种高大上的监控工具早已经让人目不暇接了,但是熟悉基础的 Linux 监控命令依然是必要的,就好比 IDE 再好用,我们也得学会 vi 或者 emacs 才行。如果让我选一个必须学会的 Linux 监控命令的话,那么我想我一定会选 sar,没有之一。

监控命令 sar 隶属于 sysstat 包,监控的内容可以说是无所不包,常见的有:

sar -q:查看 Load

sar -u:查看 CPU

sar -r:查看 Memory

sar -b:查看 IO

除了这些

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

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

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

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

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

+0  实战Sentry

Tag: Technical | Linux
老王 发于 2015年06月19日 17:29 | 点击: 1324 | 展开摘要
不管你用什么编程语言,都会面临如何处理错误日志的问题。很多程序员对错误日志放任自流,直到出现故障了才追悔莫及,如果问我怎么办,我会推荐 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 | 点击: 974 | 展开摘要
一台服务器报警了,内存占用过高,奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看:每一个匪夷所思的问题背后,都隐藏着一个啼笑皆非的答案。

首先通过「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 | 点击: 1027 | 展开摘要
实际上本次故障的素材来自于朋友的朋友,虽然我并不是故障的亲身经历者,但即便只是作为旁观者,依然感觉有所收获,于是乎记录下来以馈读者。

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

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

CRE

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

+0  监控Netstat数据

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

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

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

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

Tag: Technical | Redis
老王 发于 2015年03月25日 16:45 | 点击: 2380 | 展开摘要
如果 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 | 点击: 1137 | 展开摘要
有个老项目,通过 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 | 点击: 1449 | 展开摘要
有时候,进程突然终止服务,可能是没有资源了,也可能是意外,比如说:因为 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 | 点击: 1517 | 展开摘要
偶然间,我发现 Graphite 显示服务器网卡流量呈锯齿状,于是查了一下 Nginx 日志,发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。

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

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

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

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