最近用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中的城堡属性、及用户的金币、圣水、奖杯适用用什么数据结构保存？
时间： 2024-12-16 16:26:23