最近用Cassandra的又逐渐多了，除了之前的360案例，在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例。而这篇百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例。考虑到到目前仍然有不少网友在讨论Redis的用法问题，Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题，因此简单谈下相关区别。
首先，Redis和Cassandra完全是适合不同的使用场景的NoSQL产品。前者是适用小规模内存型的key value或者key list数据，后者适合存储大规模数据。因此这篇文章提到切换主要原因或许还是前期Redis使用场景不合适，在初创公司项目初期，以顺手的工具快速实现功能的做法也可以理解。
Redis的几种使用场景
- 访问量大
- key value或者key list数据结构
- 容量小，可控，可以全部放入内存。由于Redis是单线程设计，因此大value会导致后续的请求一定的堵塞。另外hashset当hgetall时候由于存在遍历操作，也不适合集合太大。如果数据超过单机容量可以使用常规的sharding方法分布到多台机
- 需持久化的场景
上面四点一般情况下应是必要条件。因此常见网站的用户资料、好友列表就适用用Redis来保存。由于Redis具有memcached所有的特性，也有讨论说memcache是否可以退出了？在以下情况下，我会倾向于选择memcached而非redis
- 简单无需持久化的key value，比如100字节以下。这种情况下使用memcached空间更节约且维护更简便。
- 有滚动过期需求，如网站的session，每个新登录的用户定期过期。
相关观点也可参考Memcached真的过时了吗
几个问题
- 既然Redis可以持久化，用Redis保存的好友列表是否还需要保存到关系数据库？
- 手机游戏Clash of Clans中的城堡属性、及用户的金币、圣水、奖杯适用用什么数据结构保存？
1. redis做cache也已是趋势：毕竟团队只使用一种高性能小数据量存储或缓存服务，可以投入更少成本使团队来拥有更多经验，让系统更稳定。
2. Clash of Clans的用户的建筑（城堡、防御、资源、兵营等）数据更新相对少（升级慢，个数增加也少但需求变更（扩展多），客户端缓存能更有效， 采用松scheme数据结构就具有很强适应业务变更与扩展能力（如： docment, column family）。
Clash of Clans的用户的金币、圣水、奖杯 数据更新频繁（打仗，或收集，或等级积分提升）但需求变更少, 采用key->mutiltValue 或 key->hash 比较节约资源且性能好。
1. 好友列表应该以保存在持久性数据库为主，redis作为缓存使用，有变化时同时更新DB和Redis，读取只从redis里读。
2. COC是长连接游戏，跟网游一样，用户登录时数据从DB加载到内存，后续请求只改变内存数据，用户退出时内存dump到DB中。服务器崩溃怎么办？用户数据回滚： COC早期我遇到过多次用户数据回滚。要选一个合适的dumpToDB策略。
couchbase 呢。redis 和memcached扩展太麻烦了
如果只是简单的key-value操作，考虑到数据扩展性，cassandra绝对是首选。
但如果*非常*关注性能，那redis绝对是首选。
另外cassandra的counter功能和redis的计数器比起来，绝对是弱爆了，分布式情况下做这个事情，性能是不能保证的。
所以还是要看干什么吧，拙见，嘿嘿。
@Jee @yangwm 考虑到外挂及金融系统的严谨性，我判断COC的计算逻辑基本都在服务端的，包括数据的变化。当然考虑到移动端的特点，中间有巧妙的异步设计。
“有滚动过期需求，如网站的session，每个新登录的用户定期过期”
这一点redis的expire也很容易实现啊
既然Redis可以持久化，用Redis保存的好友列表是否还需要保存到关系数据库？
因此常见网站的用户资料、好友列表就适用用
– basement foundation repairs near st louis missouri