關於redis的分佈式架構

2019-07-31 08:57:05 一點php分享關於redis分佈式架構理念的一些總結並不涉及實際部署方式以及代碼，不管是redis還 是其餘軟件全部的架構理念是同樣的，我的認爲理念更爲重要，代碼是死的理念是活的，沒有一種 架構能夠解決一切問題，只有遇到不一樣的問題採用不一樣的架構根據實際場景調整架構方案。 分佈式算法無非是運維開發者手動實現或者是軟件自身支持某種算法實現。搭建分佈式的目的就在 於將不一樣的請求壓力以及讀寫io分散開，關鍵在於如何分散請求以及後續如何能夠精確的命中請 求。

一致性hash算法： redis存儲採用一致性hash方式命中節點，將全部緩存以及節點都放入hash空間中，數據進來後 通 過hash計算得出本身的位置而後順時針尋找就近節點，若是節點宕機則尋找下一個。若是分佈不均 勻，致使某一節點壓力過大，能夠採用虛擬節點。

hash取模方式： 數據進來後經過hash取模的方式算出節點位置，從而進行讀寫操做，這種算法實現簡單也有必定的 做用，可是server總數不能輕易變化。由於若是增長/減小server的數量，對原先存儲的全部key的 後續查詢都將定位到別的server上，致使全部的cache都不能被命中而失效。

區別： 爲了解決這個問題，須要採用一致性hash算法 相對於取模的算法，一致性hash算法除了計算key的hash值外，還會計算每一個server對應的hash 值，而後將這些hash值映射到一個有限的值域上（好比0~2^32）。經過尋找hash值大於 hash(key)的最小server做爲存儲該key數據的目標server。若是找不到，則直接把具備最小hash值 的server做爲目標server。

在redis3.0版本以後推出redis自身的實現方式： 生產經過hash槽將0~16383範圍分片給不一樣節點存儲數據，最少6臺redis才能將這個架構跑起來， 3臺master以及3臺slave分別爲主各自的主從，而且將16383個hash槽位置分散在3臺master節點 中。好處是顯而易見的主掛從上，同時主從數據基本同步固然也不是強一致性的，並不能100%的認 爲數據一致。當master數量少於必定程度或者某個節點的主從同時宕機，這個集羣將中止工做。 關於redis的分佈式架構

總結： 以上只是博主分享的一部分關於redis的架構理念，只是讓你們有個概念，具體細節一篇文章也講不 完。同時並非說只有這些方式，例如某些大廠中會有自身的一套算法，還有redis中也有哨兵算法等，本文主要做爲拋磚引玉的做用。

個人開源商城立刻要發佈 了，歡迎你們關注 開源地址：github.crmeb.net/u/lsq