转载自新浪微博架构师杨卫华的博客 http://timyang.net/tag/redis/，省略了部分内容
按：杨卫华在2010年就已经测试了Redis的性能，并给出了初步的结论：“Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。” 而我在今天才开始看Redis，已经落后了6年。
Redis是什么？
这个问题的结果影响了我们怎么用Redis。如果你认为Redis是一个key value store, 那可能会用它来代替MySQL；如果认为它是一个可以持久化的cache, 可能只是它保存一些频繁访问的临时数据。Redis是REmote DIctionary Server的缩写，在Redis在官方网站的的副标题是A persistent key-value database with built-in net interface written in ANSI-C for Posix systems，这个定义偏向key value store。还有一些看法则认为Redis是一个memory database，因为它的高性能都是基于内存操作的基础。另外一些人则认为Redis是一个data structure server，因为Redis支持复杂的数据特性，比如List, Set等。对Redis的作用的不同解读决定了你对Redis的使用方式。
互联网数据目前基本使用两种方式来存储，关系数据库或者key value。但是这些互联网业务本身并不属于这两种数据类型，比如用户在社会化平台中的关系，它是一个list，如果要用关系数据库存储就需要转换成一种多行记录的形式，这种形式存在很多冗余数据，每一行需要存储一些重复信息。如果用key value存储则修改和删除比较麻烦，需要将全部数据读出再写入。Redis在内存中设计了各种数据类型，让业务能够高速原子的访问这些数据结构，并且不需要关心持久存储的问题，从架构上解决了前面两种存储需要走一些弯路的问题。
Redis是适用小规模内存型的key value或者key list数据，Redis的几种使用场景是：
- 访问量大
- key value或者key list数据结构
- 容量小，可控，可以全部放入内存。由于Redis是单线程设计，因此大value会导致后续的请求一定的堵塞。另外hashset当hgetall时候由于存在遍历操作，也不适合集合太大。如果数据超过单机容量可以使用常规的sharding方法分布到多台机
- 需持久化的场景
上面四点一般情况下应是必要条件。因此常见网站的用户资料、好友列表就适用用Redis来保存。由于Redis具有memcached所有的特性，也有讨论说memcache是否可以退出了？在以下情况下，我会倾向于选择memcached而非redis
- 简单无需持久化的key value，比如100字节以下。这种情况下使用memcached空间更节约且维护更简便。
- 有滚动过期需求，如网站的session，每个新登录的用户定期过期。
在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。
(本文主要讨论Redis未启用VM支持情况)
1. Schema
MySQL: 需事先设计
Memcached: 无需设计
Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划
数据项: value保存的内容是什么，如用户资料
Redis数据类型: 如String, List
数据大小: 如100字节
记录数: 如100万条(决定是否需要拆分)
⋯⋯
上面的规划就是一种schema，为什么Redis在大型项目需要事先设计schema？因为Redis服务器有容量限制，数据容量不能超出物理内存大小，同时考虑到业务数据的可扩充性，记录数会持续增多、单条记录的内容也都会增长，因此需要提前规划好容量，数据架构师就是通过schema来判断当前业务的Redis是否需要“分库分表”以满足可扩展需求。
2. 容量及带宽规划
容量规划
MySQL: < 硬盘大小
Memcached: < RAM
Redis: < RAM
带宽规划
由于Redis比MySQL快10倍以上，因此带宽也是需要事先规划，避免带宽跑满而出现瓶颈。
3. 性能规划(QPS)
当系统读写出现瓶颈，通常如何解决？
MySQL
写: 拆分到多服务器
读: (1) 拆分 (2) 写少也可以通过增加Slave来解决
Memcached
读写: 都通过hash拆分到更多节点。
Redis:
写：拆分
读: (1) 拆分 (2) 写少也可以通过增加Slave来解决
4. 可扩展性
MySQL: 分库分表
Memcached: hash分布
Redis：也可以分库，也可以hash分布
小结
通过以上分析，Redis在很多方面同时具备MySQL及Memcached使用特征，在某些方面则更像MySQL。
由于Redis数据不能超过内存大小，一方面需要进行事先容量规划，保证容量足够；另外一方面设计上需要防止数据规模无限制增加，进而导致Redis不可扩展。
Redis需要象MySQL一样预先设计好拆分方案。
用MongoDB的一句设计哲学结尾
Databases are specializing – the “one size fits all” approach no longer applies.