这个国家最让我心悸的，不是国家机器任意妄为地作恶，而是占据主流力量的普通人纷纷告诉你：这个国家就是这样的，你改变不了的，习惯了就行。他们可能是你的同学，同事，朋友，亲人，爱人。只要自己不被伤害，他们可以容忍任何人被伤害。

http://blog.sina.com.cn/s/blog_4701280b0102drhj.html

你一直问，他们何以如此的丧心病狂，他们却觉得自己已经非常的克制忍让。
你一直问，他们何以如此的颠倒黑白，他们却觉得自己已经非常的公正坦率。
你一直问，他们何以如此的包庇凶手，他们却觉得自己已经非常的愧对炮友。
你一直问，他们何以如此的掩盖真相，他们却觉得自己已经非常的透明开放。
你一直问，他们何以如此的生活腐化，他们却觉得自己已经非常的艰苦朴素。
你一直问，他们何以如此的骄横傲慢，他们却觉得自己已经非常的姿态低下。

你觉得自己很委屈，他们也觉得自己很委屈，他们认为，在清政府的统治下，老百姓连电视机都看不上，现在电视机已经走进了千家万户，这是多大的进步。

他们觉得，我们建了这个，我们建了那个，你别管过程中发生了什么，也别管这是给谁献礼，至少你用到了吧。你以前从上海到北京火车要一天一夜，现在只要不被雷劈，五个小时就到了，你为何不感激，为何充满了质疑？

偶然发生一个安全事故，中央最高领导都已经表示了关心，我还派人来回答你们记者的问题，原来赔17万，现在赔50万，甚至撤职了一个兄弟，事情都做到这份上了，你们为什么还抓着一些细节不放呢，你们的思想怎么反而就这样不开放呢？你们的大局观都去哪里了呢？为什么要我谢罪呢，我又没犯罪，这是发展的代价。迅速处理尸体是我们的惯例，早签字多发奖金，晚签字少拿赔偿，这是我们的兄弟部门在强拆工作中被证明了行之有效的手段。掩埋车厢的确是当时一个糊涂做出的一个决定，况且是上头叫我们这么做的。因为上头觉得任何可能引发的麻烦都是可以就地掩埋的。错就错在大白天就开始施工，洞挖太大，而且没有和宣传部门沟通好，现场的摄影记者也没有全控制住，准备工作比较仓促。这次事故最大的教训就是以后在就地掩埋的时候还是要考虑到物体的体积和工作的保密。还是低估了。

他们认为，总体来说，这次的救援是成功的，及时的。调度合理，统筹规范，善后满意。唯一的遗憾是在舆论上有点失控，他们觉得这就不是我们的责任了，舆论不归我们管。

他们认为，从大的来说，我们举办了奥运会，我们取消了农业税，这些你们不赞美，老是抓住一些细枝末节的东西，这是什么居心。我们本可以在政治上比朝鲜更紧，在经济上比苏丹更穷，在治国上比红色高棉更狠，因为我们拥有比他们更多的军队，但是我们没有那么做，你们不感恩，却要我们谢罪，我们觉得很委屈。这个社会里，有产者，无产者，有权者，无权者，每个人都觉得自己很委屈。一个所有人都觉得委屈的国家，各个阶层都已经互相脱节了，这个庞大的国家各种组成的部分依靠惯性各顾各的滑行着，如果再无改革，脱节事小，脱轨难救。

国家为什么不进步，是因为他们中的很多人一直在用毛泽东斯大林时代的他们来衡量自己，所以他们永远觉得自己太委屈了，太开明了，太公正了，太仁慈了，太低姿态了，太不容易了。他们将科技裹着时代向前走的步伐当成了自己主动开放的幻象，于是你越批评他，他越渴望极权，你越搞毛他，他越怀念毛。

有一个国家机器朋友对我说，你们就是不知足，你这样的文人，要是搁在四十年前，你就被枪毙了，你说这个时代，是进步了还是退步了。
我说，你们就是不知足，你这样的观点，要是搁在九十年前，早就被人笑死了，你说这个时代，他到底是进步了还是。

@刘峻：当一个国家烂到打个雷就能让火车追尾、过个车就能让大桥垮塌、喝几包奶粉就能肾结石的地步，我们每一个人都无法再置身事外。今天的中国本身就是一列在雷雨中行驶的动车，你我不是看客，你我都是乘客。

海滨公园

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

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