海滨公园

今天和老婆一起步行上班，天气很好

网站为提高响应速度，越来越依赖在内存中存放数据。之前使用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/

可乐四周岁两个月了。最近不怎么玩电脑了，他更爱画画了。或许算不上画画，更像涂鸦吧。他自己也不知道画的是什么，他只喜欢自己画出各种形状的轮廓（都是封闭的），然后涂上各种颜色。当然，偶尔也会要爸爸妈妈画出一些诸如飞机、汽车的形状，他再涂色。

他要我陪他“玩”，其实我不需要做什么，他只要我在旁边陪着他，看着他画，和他随意的交流一下就好，房间小，更能其乐融融。这种感觉，或许就是天伦之乐吧，非常享受。

昨天下雨，路上拍的

顺便留一下前三集的链接：
http://ncblog.net/830/
http://ncblog.net/771/
http://ncblog.net/751/

说实话，这个预告片我爱看

台词：
同学们，冲过去！
你他娘的算老几！
我们今天的行动，是中国美好未来的先声！
彻底改变这个世界！

Chrome/Chromium毫无疑问是速度最快的主流浏览器。不过，时常遇到其狂读硬盘僵在那里的情况，感觉有点诡异。
google一下发现了解决方法：
将“高级选项”中的“启用针对网上诱骗和恶意软件的防护功能”功能关闭即可。