本文作者是新浪微博的 Timyang 同學，Tim 前段時間對Redis 做過一些測試和研究，本文是一篇更直接地接近於實際應用方面的總結文章。本文說到的規划，不僅對 Redis 適用，對我們常用的數據庫和緩存的使用規划思路也有指導意義。
在使用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中，“分庫分表”應當如何實現？有什么好的設計模式？