薄荷 App 上的伙伴功能大量使用了內存數(shù)據(jù)庫 Redis，隨著數(shù)據(jù)量的快速增長，Redis 膨脹得很快，已經接近 12 GB規(guī)模，這些數(shù)據(jù)全部放在單個 Redis 實例中。單個巨大 Redis 實例有如下幾個壞處：

1.首先，需要一臺內存很大的機器。Redis 是內存數(shù)據(jù)庫，它需要把所有需求全部放在內存中，需要為之裝下 12 GB的 Redis 實例，至少需要 12 GB 內存大小的機器，考慮的預留增長空間，一般需要 12 * 1.5 約 18 GB 內存。 另外還有一個考慮的因素是，Redis 進行硬盤數(shù)據(jù)存儲時，fork 進程需要消耗同樣大小的內存，因此一個 12GB 的 redis 實例需要 32 GB左右的內存比較合適，這對機器提出了很高的要求，常常難以滿足。

2.然后，Redis 容易成為性能瓶頸。Redis 的并發(fā)模型是單進程單線程，它不能充分利用多核 CPU，在請求數(shù)很高，或者某一些請求處理比較慢時（比如一些大的數(shù)據(jù)排序），可能會成為系統(tǒng)的性能瓶頸。有方法可以緩解甚至這個問題，就是建立多個 Redis 實例，通過多個 Redis 連接來實現(xiàn)。

3.另外，單個巨大的 Redis 實例也會增加數(shù)據(jù)管理難度，因為這么大的數(shù)據(jù)量，無論是復制，備份操作都比較慢，容易對線上系統(tǒng)造成沖擊。

因此，十分有必要把單個巨大的 Redis 實例分割成多個小的 Redis 實例。

使用 Redis 的復制機制，可以在線平滑處理 Redis 實例分割，幾乎不會對系統(tǒng)有很大的影響。

分割的具體操作思路如下：

1.首先，規(guī)劃 Redis 分割策略，通常是基于業(yè)務劃分，比如薄荷伙伴是基于業(yè)務分成 timeline, user_relationship, other 3個 Redis 實例。規(guī)劃好之后，需要根據(jù)規(guī)劃結果對應用程序中 Redis 程序代碼做修改，通常是有一個統(tǒng)一的 Redis 鏈接修改為多個 Redis 連接，不同業(yè)務使用不同的連接。

2.然后，通過 Redis 復制功能建立多個 Redis 副本，讓不同 Redis 連接使用不同的 Redis 副本，在 Redis 副本中刪除多余的數(shù)據(jù)。批量刪除某個模式的 keys，可以使用下面的 shell 命令：

改成實際的模式，如

表示刪除 user followers 數(shù)據(jù)。

最后通過來回切換并重啟 Redis 實例達到完全分割 Redis 實例。