在使用Redis過程中，我們發(fā)現(xiàn)了不少Redis不同于Memcached，也不同于MySQL的特征。
(本文主要討論Redis未啟用VM支持情況)

1. Schema

MySQL: 需事先設計
Memcached: 無需設計
Redis: 小型系統(tǒng)可以不用，但是如果要合理的規(guī)劃及使用Redis，需要事先進行類似如下一些規(guī)劃

• 數(shù)據(jù)項: value保存的內(nèi)容是什么，如用戶資料
• Redis數(shù)據(jù)類型: 如String, List
• 數(shù)據(jù)大小: 如100字節(jié)
• 記錄數(shù): 如100萬條(決定是否需要拆分)
• ??

上面的規(guī)劃就是一種schema，為什么Redis在大型項目需要事先設計schema？因為Redis服務器有容量限制，數(shù)據(jù)容量不能超出物理內(nèi)存大小，同時考慮到業(yè)務數(shù)據(jù)的可擴充性，記錄數(shù)會持續(xù)增多、單條記錄的內(nèi)容也都會增長，因此需要提前規(guī)劃好容量，數(shù)據(jù)架構(gòu)師就是通過schema來判斷當前業(yè)務的Redis是否需要“分庫分表”以滿足可擴展需求。

2. 容量及帶寬規(guī)劃

容量規(guī)劃
MySQL: < 硬盤大小
Memcached: < RAM
Redis: < RAM

帶寬規(guī)劃
由于Redis比MySQL快10倍以上，因此帶寬也是需要事先規(guī)劃，避免帶寬跑滿而出現(xiàn)瓶頸。

3. 性能規(guī)劃(QPS)

當系統(tǒng)讀寫出現(xiàn)瓶頸，通常如何解決？
MySQL
寫: 拆分到多服務器
讀: (1) 拆分 (2) 寫少也可以通過增加Slave來解決

Memcached
讀寫: 都通過hash拆分到更多節(jié)點。

Redis:
寫：拆分
讀: (1) 拆分 (2) 寫少也可以通過增加Slave來解決

4. 可擴展性

MySQL: 分庫分表
Memcached: hash分布
Redis：也可以分庫，也可以hash分布

小結(jié)

通過以上分析，Redis在很多方面同時具備MySQL及Memcached使用特征，在某些方面則更像MySQL。
由于Redis數(shù)據(jù)不能超過內(nèi)存大小，一方面需要進行事先容量規(guī)劃，保證容量足夠；另外一方面設計上需要防止數(shù)據(jù)規(guī)模無限制增加，進而導致Redis不可擴展。
Redis需要象MySQL一樣預先設計好拆分方案。

小問題

在MySQL中，通過預先建立多表或者庫可以在業(yè)務增長時候?qū)⑦@些表或庫一分為二部署到更多服務器上。
在Redis中，“分庫分表”應當如何實現(xiàn)？有什么好的設計模式？

?

老徐,人人安家網(wǎng) (http://www.renrenaj.com) 技術(shù)架構(gòu)

Redis容量及使用規(guī)劃