在使用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一样预先设计好拆分方案。

小问题

    在MySQL中，通过预先建立多表或者库可以在业务增长时候将这些表或库一分为二部署到更多服务器上。

    在Redis中，“分库分表”应当如何实现？有什么好的设计模式？

建议继续学习：

1. redis源代码分析 - persistence    (阅读：31116)
2. Redis消息队列的若干实现方式    (阅读：10686)
3. 基于Redis构建系统的经验和教训    (阅读：9256)
4. 浅谈redis数据库的键值设计    (阅读：8264)
5. redis运维的一些知识点    (阅读：7391)
6. redis在大数据量下的压测表现    (阅读：7363)
7. Redis和Memcached的区别    (阅读：6740)
8. Redis作者谈Redis应用场景    (阅读：6545)
9. redis 运维实际经验纪录之一    (阅读：6451)
10. 记Redis那坑人的HGETALL    (阅读：6301)