在使用Redis过程中，我们发现了不少Redis不同于Memcached。也不同于MySQL的特征。
(本文主要讨论Redis未启用VM支持情况)
1. Schema
MySQL: 需事先设计
Memcached: 无需设计
Redis: 小型系统能够不用。可是假设要合理的规划及使用Redis，须要事先进行类似例如以下一些规划
- 数据项: value保存的内容是什么。如用户资料
- Redis数据类型: 如String, List
- 数据大小: 如100字节
- 记录数: 如100万条(决定是否须要拆分)
- ⋯⋯
上面的规划就是一种schema，为什么Redis在大型项目须要事先设计schema？由于Redisserver有容量限制。数据容量不能超出物理内存大小，同一时候考虑到业务数据的可扩充性，记录数会持续增多、单条记录的内容也都会增长。因此须要提前规划好容量。数据架构师就是通过schema来推断当前业务的Redis是否须要“分库分表”以满足可扩展需求。
2. 容量及带宽规划
容量规划
MySQL: < 硬盘大小
Memcached: < RAM
Redis: < RAM
带宽规划
因为Redis比MySQL快10倍以上。因此带宽也是须要事先规划。避免带宽跑满而出现瓶颈。
3. 性能规划(QPS)
当系统读写出现瓶颈。通常怎样解决？
MySQL
写: 拆分到多server
读: (1) 拆分 (2) 写少也能够通过添加Slave来解决
Memcached
读写: 都通过hash拆分到很多其它节点。
Redis:
写：拆分
读: (1) 拆分 (2) 写少也能够通过添加Slave来解决
4. 可扩展性
MySQL: 分库分表
Memcached: hash分布
Redis：也能够分库，也能够hash分布
小结
通过以上分析，Redis在非常多方面同一时候具备MySQL及Memcached使用特征，在某些方面则更像MySQL。
因为Redis数据不能超过内存大小，一方面须要进行事先容量规划，保证容量足够；另外一方面设计上须要防止数据规模无限制添加，进而导致Redis不可扩展。
Redis须要象MySQL一样预先设计好拆分方案。
小问题
在MySQL中。通过预先建立多表或者库能够在业务增长时候将这些表或库一分为二部署到很多其它server上。
在Redis中，“分库分表”应当怎样实现？有什么好的设计模式？