Qcon杭州2011 听课笔记&小结

上周有幸参加Qcon大会，一睹大牛风采，会后我重新整理了redis相关的听课笔记，供大家参考。

 

整体印象

此行我听课的主线围绕与社区紧密相关的“（社会化）开放平台”及“大数据和nosql”两个议题展开。两天的课听下来，给我最直观的感受是，目前互联网的发展趋势为：

l  社会化（过滤掉信息爆炸产生的干扰，只显示你需要关心或应该关心的内容，过滤参数除了传统的人际圈外，还有地理位置、用户偏好如购买行为等等。）

l  实时化（数据挖掘，即时分析；无需用户请求，即时反馈；占领用户手机，即时推送）

l  平台化（硬件上通过云平台，降低企业部署和伸缩的成本；软件上通过开放平台和服务化，共享基础数据和通用服务，以便企业专注于业务创新，迅速上线）

 

Redis相关

社区搭载redis的sns化应用已经上线，我重点听了与redis有关的几场分享，汇总了一些前辈的经验：

 

l  选择nosql产品，需清楚业务场景与侧重点

redis侧重于缓存，特点是对集合的支持，源码易读易修改。

mongoDb侧重于持久化，特点是对json的支持，文档详细。

新浪和飞信都拿redis当缓存用，数据仍然保存在mysql集群中；盛大用mongoDB作存储。

 

l  避免单点，规避雪崩风险

所谓雪崩，即中文站此前曾激烈讨论过的memcache（下文简称mc）挂了之后，DB一下承受不了被击穿的问题。业界的解决方案是，缓存也要有完善的同步机制从而避免单点。新浪提到redis在HA Cluster上支持不好，他们用的是自己的java实现。

 

l  谨慎考虑持久化

持久化会影响性能。目前redis提供两种持久化模式，定时dump的rdb模式和实时log的aof模式，新浪和飞信都选择后者，牺牲一点实时性能换取更高的一致性，同时可以避免rdb启动时整体性能急剧抖动。

 

l  推模式不可行

新浪提到，当粉丝数极大时，会产生恐怖的数据量，因此推模式不可行，twitter也曾碰到过类似的问题，最终改为拉模式。新浪目前的做法是，粉丝可以无限，但关注的人限2000个，然后通过拉模式获取数据。

 

l  新浪的现状

redis集群有200台机器，8核96g或4核48g，开4-6个端口，容量规划的结论是预算吃紧。

通过aof持久化+写多份（raid1）来做灾备，数据永远以mysql为准。

仍无法解决灾备时数据一致性和恢复慢的问题。

 

l  新浪的远期规划

对于“未读数”业务场景，采用向量相减算法为计数器优化。

冷数据刷到磁盘的自动化解决方案（正考虑开源）。

去redis化：HA原生支持不完善，因此未来会考虑其它nosql方案或自己实现HA。

 

l  飞信的缓存分配策略

飞信也采用redis作为缓存。前面说过redis的问题之一是持久化对性能影响较大、HA不完善且耗费内存。他们分享了根据业务数据的重要性和重建成本两个指标给reids分区，分别调整持久化和HA策略，从而优化响应性能、节约硬件成本的方案。

区1、全局缓存区：短连接之类的数据，可随着访问缓慢重建，且对可靠性要求不高。策略：无持久化无复制。

区2、弱session区：用户登录后需要的数据，与每个用户session相关，用户感知失败主要来自ajax轮询，失败也关系不大。它的构建成本> 全局缓存区。策略：无持久化，但有三对一复制，备机不对外服务，且内存较大。如果有机器挂掉，备机顶上。

区3、强session区：一致性高、重建成本高，如用户在线队列之类的数据。aof持久化+复制。