溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了redis如何擴容，具有一定借鑒價值，需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。
方案一：
首先想到的是，增加Redis服務器的數量，在客戶端對存儲的key進行hash運算，存入不同的Redis服務器中，讀取時，也進行相同的hash運算，找到對應的Redis服務器，可以解決問題，但是不好的地方：
第一，客戶端要改動代碼；
第二、需要客戶端記住所有的Redis服務器的地址；
這個方案可以使用，但能不能不用改動代碼就能實現擴容呢？
方案二：
搭建一個集群，由于Redis服務器使用的版本低于3.0，不支持集群，只能通過使用代理，就想到了有名的Redis代理twemproxy。
twemproxy的性能也是杠杠滴，雖然是代理，但它對訪問性能的影響非常小，連Redis作者都推薦它。
twemproxy使用方便，對于一個新手來說，不到一個小時就能學會使用，而且關鍵是不用改動客戶端代碼，幾乎支持所有的Redis命令和管道操作，只需要改下客戶端的配置文件中配置的Redis的IP和PORT，由原來的Redis的IP和Port改成twemproxy服務的IP和PORT。
客戶端不需要考慮hash的問題，這些twemproxy會做，客戶端就像操作一臺Redis一樣。
上面用了“幾乎”這個詞，因為有些命令，比如"keys *"就不支持
很快部署了好了twemproxy和后面跟著的四個Redis機器，壓測發現，后面的四臺Redis的CPU使用率降下來了，但新問題來了，twemproxy也是單進程的！性能瓶頸又跑到twemproxy上來了！
方案三：
對Redis的訪問分為寫和讀，類似生產者和消費者， 再仔細分析，發現寫的少，讀的相對多些，這就可以將讀寫分離，寫的往主的寫，讀的從備的讀，遇到的情況恰好是讀和寫是兩個服務，做到讀寫分離通過改下配置信息就可以很簡單的做到，，這樣分散了主Redis的壓力。
這里對Redis的訪問壓力有好轉，但不是長久之計，比如遇到舉辦活動， 數據量增大時，還是會有性能的風險。
最終采用的方法是綜合方案二和三，如下圖所示：
這種方法對現有的服務改動最小，可以有效緩解redis壓力的問題
producer端和consumer端的twemproxy使用的hash算法要求一致，不然找不到key了。
如果把方案一也加進來，會比較復雜，暫時用不到。
感謝你能夠認真閱讀完這篇文章，希望小編分享redis如何擴容內容對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，遇到問題就找億速云，詳細的解決方法等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
