最近redis很“忙”，一到上午10点左右，redis就频繁出现各种报错，大部分的场景还好，我们对cache的异常进行了捕获，只是在日志里边记录一下，而不会抛出异常，所以顶多就慢一些而已。不过，还是有让我们也不得不忙的场景出来：
1、有的场景使用redis缓存校验码，比如用户通过手机验证码登录时，明明发送验证码成功，明明输入正确的验证码，但是就是提示验证失败。
2、随着每个依赖redis的服务不断变慢，网站不断出现502，最后，基本上不能访问了。
于是，运维人员不得不一声令下，重启redis。终于，作为cache的redis内存占用量急剧下降，连接数也迅速降低，网站也很快恢复稳定，一切似乎完美地回归了。
这样的事情重复了几天，大家找到规律了，于是索性定了个定时任务，每天凌晨5点的时候，重启一下redis，为即将躁动的10点偃旗息鼓，杀杀他的威风。
不过，作为有技术素养有技术追求的团队，怎么能这样就认怂了呢？
一般我们说优化mysql，总是会将着眼点放在mysql的慢查询的优化上，或者字段的数据类型，mysql的分库/分表，读写分离，异或事务这些看上去高大上的东东上。但是，对于一些更加基础或者更加常识的地方，往往会加以忽视。就比如，本文将要提到的：mysql的查询本身的优化。
这次接到的优化任务出现的背景是：
我们有一个内部电话呼叫的系统，在下午使用客服相对较多的时候，在很随机的情况下，会出现突然的卡顿，这种现象维持的时间很短，检查的时候，往往发现cpu、内存、负载、网络，都很正常，查询错误日志也看不到异常。
系统用的是阿里云，2C4G，看负载的曲线也维持得很小很平稳，内存消耗也没有达到瓶颈。中间一度怀疑过对缓存的使用有问题，因为有很多临时数据都是通过cache在传输和保存的，调用频率也很高。于是，负责此项目的同学也做过很多方面的优化，想过很多招数。比如：
1、临时数据的保存从全量改为增量，大大降低了数据传输的量。
2、将数据库改成长连接，减少连接使用量。
原来我们使用的数据库是由阿里云提供的，后来降配了，长连接经常出现连接数不够的时候，又改为普通连接了。最后，我们又把mysql改成了自建，连接数2000，还是够用的。不过，即使使用长连接的时候，依然会出现卡顿，索性，就一直维持着使用普通连接了。
本文对比了php的各种压缩工具的解压缩速度，试图找出在性能和时间上更具有性价比的工具。具体包括：
在进行系统优化的时候，发现系统使用了大量的缓存，而在写入缓存的时候，需要先对内容进行序列化，读取缓存的时候，则需要进行内容的反序列化，从而保证可以写入和读取任何类型的缓存。早期，缓存量不大的时候，我们一直使用json进行序列化和反序列化，随着整体服务从IDC的物理机迁移到混合云平台的虚拟机，单台机器的cpu从原来的8核、16核降低到2核，cpu上就显得非常吃紧了，经常能从满日志里边看到序列化和反序列化时的日志。因此，优化序列化性能成为我们系统优化的一个重要环节。
经过对几种序列化函数的对比，最终我们选定了igbinary可以作为其中比较优秀的一个方案。要正式转型之前，当然要通过一些压测进行有效对比，才能做到有据可循。