薄荷 App 上的伙伴功能大量使用了內(nèi)存數(shù)據(jù)庫 Redis，隨著數(shù)據(jù)量的快速增長，Redis 膨脹得很快，已經(jīng)接近 12 GB規(guī)模，這些數(shù)據(jù)全部放在單個 Redis 實例中。單個巨大 Redis 實例有如下幾個壞處：
1.首先，需要一臺內(nèi)存很大的機(jī)器。Redis 是內(nèi)存數(shù)據(jù)庫，它需要把所有需求全部放在內(nèi)存中，需要為之裝下 12 GB的 Redis 實例，至少需要 12 GB 內(nèi)存大小的機(jī)器，考慮的預(yù)留增長空間，一般需要 12 * 1.5 約 18 GB 內(nèi)存。 另外還有一個考慮的因素是，Redis 進(jìn)行硬盤數(shù)據(jù)存儲時，fork 進(jìn)程需要消耗同樣大小的內(nèi)存，因此一個 12GB 的 redis 實例需要 32 GB左右的內(nèi)存比較合適，這對機(jī)器提出了很高的要求，常常難以滿足。
2.然后，Redis 容易成為性能瓶頸。Redis 的并發(fā)模型是單進(jìn)程單線程，它不能充分利用多核 CPU，在請求數(shù)很高，或者某一些請求處理比較慢時（比如一些大的數(shù)據(jù)排序），可能會成為系統(tǒng)的性能瓶頸。有方法可以緩解甚至這個問題，就是建立多個 Redis 實例，通過多個 Redis 連接來實現(xiàn)。
3.另外，單個巨大的 Redis 實例也會增加數(shù)據(jù)管理難度，因為這么大的數(shù)據(jù)量，無論是復(fù)制，備份操作都比較慢，容易對線上系統(tǒng)造成沖擊。
因此，十分有必要把單個巨大的 Redis 實例分割成多個小的 Redis 實例。
使用 Redis 的復(fù)制機(jī)制，可以在線平滑處理 Redis 實例分割，幾乎不會對系統(tǒng)有很大的影響。
分割的具體操作思路如下：
1.首先，規(guī)劃 Redis 分割策略，通常是基于業(yè)務(wù)劃分，比如薄荷伙伴是基于業(yè)務(wù)分成 timeline, user_relationship, other 3個 Redis 實例。規(guī)劃好之后，需要根據(jù)規(guī)劃結(jié)果對應(yīng)用程序中 Redis 程序代碼做修改，通常是有一個統(tǒng)一的 Redis 鏈接修改為多個 Redis 連接，不同業(yè)務(wù)使用不同的連接。
2.然后，通過 Redis 復(fù)制功能建立多個 Redis 副本，讓不同 Redis 連接使用不同的 Redis 副本，在 Redis 副本中刪除多余的數(shù)據(jù)。批量刪除某個模式的 keys，可以使用下面的 shell 命令：
復(fù)制代碼 代碼如下:
redis-cli KEYS "pattern>" | xargs redis-cli DEL
改成實際的模式，如
復(fù)制代碼 代碼如下:
redis-cli KEYS "user:*:followers" | xargs redis-cli DEL
表示刪除 user followers 數(shù)據(jù)。
最后通過來回切換并重啟 Redis 實例達(dá)到完全分割 Redis 實例。
