Twemproxy 可以说是最古老的 Redis 代理软件了，一般来说，引入代理后性能会比没有引入代理时低一些，毕竟代理会导致一些额外的性能损耗，可是 Twemproxy 却会提升性能， 这主要得益于它的 Pipelining 功能可以实现打包请求，简单点说：当代理收到多个并发请求时，它会把这些请求打包成一个请求发送给后端服务器，从而减少不必要的 RTT。关于 Pipelining 本文不做过多讨论，实际上我想说的是它的另一个功能：连接池！下面看看如何通过 Twemproxy 提升 PHP/Redis 的性能。
如果有人说你的 HTTP 接口响应慢，那可能是他的电脑慢，也可能是网络本身慢，还可能是你的服务器慢，总之想搞清楚到底是哪里慢并不是一件简单的事情，好在有一些小工具可以帮你快速做出正确的判断。
我说的事务指的是一般的数据库事务，而不是什么分布式事务之类高大上的概念。听起来很简单，但是即便如此，想实现的优雅一点也不是一件容易的事情。 继续阅读
群里一位大佬上午说了一句箴言：「 世界上没有什么故障是重启解决不了的，如果有，再重启一次。」，结果下午群里就有一位朋友遇到了一个诡异的老版本 PHP 问题：当使用 file_get_contents 抓取网页内容的时候，总是返回空字符串，奇怪的是换用 curl 扩展后又一切正常。不过，重启没有解决他的问题，再重启一次也不行。
运营反馈某个功能速度很慢，查了一下，定位到如下 SQL：
select id from user
where name like ‘%foobar%’
order by created_at limit 10;
业务需要，LIKE 的时候必须使用模糊查询，我当然知道这会导致全表扫描，不过速度确实太慢了，直观感受，全表扫描不至于这么慢！
同事在使用 sftp 连接服务器的时候出现错误信息：session is down，已经自行检查了服务器地址，端口，用户名，密码等种种可能出现低级失误的地方，结果找不到原因。
现在服务端程序员的主要工作已经不再是套模版，而是编写基于 JSON 的 API 接口。可惜大家编写接口的风格往往迥异，这就给系统集成带来了很多不必要的沟通成本，如果你有类似的困扰，那么不妨关注一下 JSONAPI，它是一个基于 JSON 构建 API 的规范标准，一个简单的 API 接口大致如下所示：
JSONAPI
简单说明一下：根节点中的 data 用来放置主对象的内容，其中 type 和 id 是必须要有的字段，用来表示主对象的类型和标识，其它简单的属性统统放置到 attributes 里，如果主对象存在一对一、一对多等关联对象，那么放置到 relationships 里，不过只是通过 type 和 id 字段放置一个链接，关联对象的实际内容统统放置在根接点中的 included 里。
如果你有几房姨太太的话，那么想让她们和平共处，多半是痴人说梦。对程序员而言，虽然他们不会有娶几个老婆的好运气，但是很可能会遇到在同一个系统里使用多个版本的软件的情况，一旦处理不好，同样会焦头烂额。
大多数 PHP 程序员从来没有使用过连接池，主要原因是按照 PHP 本身的运行机制并不容易实现连接池，于是乎 PHP 程序员一方面不得不承受其它程序员的冷嘲热讽，另一方面还得面对频繁短链接导致的性能低下和 TIME_WAIT 等问题。 继续阅读