redis單實例布置項目主要會出現(xiàn)下面三個方面的問題：
- 單點故障矢劲。如果這個redis實例掛掉赦拘，就需要重啟，或者重新布置實例卧须。這需要一定的時間另绩，在這個時間之內(nèi)儒陨，所有的請求都會透穿到數(shù)據(jù)庫花嘶。甚至在一些極端的情況下，整個物理機出現(xiàn)故障了蹦漠，就需要把硬盤取下來椭员，安裝到別的物理機上。無論是上述哪種情況笛园，都極為消耗時間隘击，對整個系統(tǒng)穩(wěn)定運行的威脅較大。
- 內(nèi)存不夠研铆。一臺redis的內(nèi)存本身是有限的埋同。如果需要往redis布置10個g的數(shù)據(jù)，但是內(nèi)存只有4個g棵红，或8個g凶赁。所以內(nèi)存大小本身也是有限制的。
-
訪問壓力大逆甜。無論是socket io虱肄，而是CPU本身的計算，壓力都比較大交煞。
那么如何解決這些問題呢咏窿？
有一個理論叫做AKF，即從x素征，y集嵌，z三個維度來進行服務(wù)的拆分萝挤。
（1）x軸方向：可以選擇主備模式，即一主多備纸淮，一臺redis作為主平斩，其他的多臺redis作為備⊙士椋“備”里存的是“主”的全量鏡像數(shù)據(jù)绘面，如下圖：
aa.png
這種情況下，就算主redis掛掉了侈沪，但是因為備redis里存的是全量數(shù)據(jù)揭璃，所以可以直接繞過出故障的主，而去訪問備亭罪，由此可見瘦馍，可以解決單點故障的問題。
另外应役，既然這么多redis都已經(jīng)準(zhǔn)備好了情组，所以的操作都壓在一臺redis上，明顯造成了其他redis資源的浪費箩祥。所以一般都會讓主redis進行增刪改的操作院崇，讓其他的備redis進行查詢的操作，所以可以解決一部分訪問壓力的問題袍祖。
由于存的是全量的數(shù)據(jù)底瓣，比如主redis里存了10個g的數(shù)據(jù)，所以每個備redis里必須也存10個g的數(shù)據(jù)蕉陋，所以并沒能解決內(nèi)存不夠的問題捐凭。
（2）y軸方向：從以上分析可以看出，x軸方向上的主備模式能夠解決單點故障的問題凳鬓，以及一部分訪問壓力的問題茁肠，但是沒能夠解決內(nèi)存限制的問題，所以y軸方向的布置主要解決的就是這個問題缩举。
y軸方向上主要是根據(jù)業(yè)務(wù)功能的模塊兒進行拆分垦梆，比如購物系統(tǒng)中的訂單模塊數(shù)據(jù)放到一個redis，支付模塊兒的數(shù)據(jù)放到一個redis蚁孔，商品信息模塊兒放到一個redis奶赔，等等。如下圖：
image.png
按照業(yè)務(wù)的功能模塊兒進行拆分之后杠氢，本來10個g的數(shù)據(jù)站刑，可以現(xiàn)在y軸上的每個redis只需存放3個g或者4個g的數(shù)據(jù)，所以解決了內(nèi)存限制的問題鼻百。由于每個redis上的數(shù)據(jù)分屬不同的模塊兒，所以訪問壓力的問題也得到了部分解決。每個模塊兒在x軸上都有備份笆环，所以單點故障的問題也得到了解決。
（3）z軸方向：根據(jù)以上分析堕汞，x軸+y軸的拆分模式基本上已經(jīng)解決了單實例三個主要的痛點問題。但是有些情況晃琳，比如我的每個redis只能存10個g的數(shù)據(jù)讯检，但是下單的人比較多，訂單數(shù)據(jù)里需要存放20個g的數(shù)據(jù)卫旱，所以需要把本來存放訂單數(shù)據(jù)的redis再進行z軸上的拆分人灼，如下圖：
image.png
可見，原來的訂單數(shù)據(jù)在z軸上分為了兩個小模塊兒顾翼，每個小模塊兒作為主redis投放，都可以在x軸上有備redis。
AKF拆分有效的解決了單點故障适贸，內(nèi)存限制灸芳，訪問壓力三個問題，但是在實踐中拜姿，仍然會存在一些問題的考量烙样。比如在主備數(shù)據(jù)同步的過程中，怎么保證數(shù)據(jù)的一致性問題砾隅，下節(jié)再作分析误阻。
