顺利切换到redis

网站为提高响应速度，越来越依赖在内存中存放数据。之前使用memcached，但却发现了一些由memcached的内存分配机制以及LRU导致的问题（详见 http://ahuaxuan.iteye.com/blog/225692）——简单来说是这样的，我们发现，在memcached还没有用尽其内存时，它就开始踢那些“永不超时”的数据了。对于memcached的设计理念是作为缓存来说，这当然不算是问题，或者可以说是有意设计的，但对于我们的实际需求来说（“永不超时”的数据必须保持在内存中）是无法接受的了。毕竟，缓存是缓存，数据是数据。

于是上周着手寻找新的替代方案，后来确定了使用redis。

“Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。”（http://www.iteye.com/topic/524977）

相比memcached，Redis毕竟是以DB为设计目标的，因此功能强大很多（比如内存中的数据维护功能，memcached几乎为0），却非常小巧，编译安装也非常方便。

“和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。”（http://timyang.net/tag/redis/）

redis支持很多客户端（http://redis.io/clients），我们使用的php（phpredis）和python（redis-py）当然都有，代码从memcached切换到redis几乎不用做改动，转移成本极小。

昨晚redis顺利部署到线上。切换后总结带来的好处如下：
1、当然是完成了切换到redis的初衷——保持web服务器内存中数据的完整性，避免类似memcached的LRU那样踢数据。
2、之前用memcached的时候，必须在线上用脚本将后台postgresql的关系数据“跑”进内存（memcached）里，这个步骤比较费时，在线上跑并不是很合适；现在用redis可以用线下服务器将关系数据跑进内存里，生成磁盘文件，再把该文件上传到线上服务器即可，线上服务器短时间就可以完成数据更新的切换（相当于把线下服务器的内存“拷贝”到了线上服务器的内存）。数据更新部署的流程简化多了。
3、不再担心重启memcached服务甚至重启服务器时，带来的内存中数据长时间空缺导致线上服务受到影响（见上一条“必须在线上用脚本将后台postgresql的关系数据“跑”进内存（memcached）里，这个步骤比较费时”），redis服务本身的维护也相当方便。

当然，基于切换的初衷，我们更多的还是把redis当作一个更合适的memcached来用，所以我们没有启用redis的VM特性（内存足够，性能是唯一要求）。redis更多强大功能，暂时还没有体会。

Redis官方网址：http://redis.io/