回顧Redis：Redis是單機(jī)、單進(jìn)程的，一般常用于緩存和數(shù)據(jù)使用。然而我們要進(jìn)行Redis集群，搭建高可用Redis方式。
Redis 特點(diǎn)：
單機(jī)、單進(jìn)程、單實(shí)例
正因?yàn)槭菃螜C(jī)的，所以會(huì)有一下問(wèn)題：
1：?jiǎn)吸c(diǎn)故障
2：數(shù)據(jù)容量有限
3：壓力（CPU計(jì)算壓力和socket連接壓力）
而假如在面試的時(shí)候有被問(wèn)到設(shè)計(jì)到“單機(jī)”的相關(guān)問(wèn)題，就可以往AKF上面引入
了解AKF：
????AKF是從X、Y、Z三個(gè)軸方向去嘗試解決上述3個(gè)問(wèn)題
????從X角度，可以使用多臺(tái)Redis，做第一臺(tái)Redis的副本，這樣就可以解決【單點(diǎn)故障問(wèn)題】：
????隨著發(fā)展，這些多臺(tái)機(jī)器也搭建起來(lái)了，那這些錢可千萬(wàn)不能浪費(fèi)呀，能壓榨就壓榨?？蛻舳丝梢詫?duì)主Redis進(jìn)行增刪改，對(duì)副Redis進(jìn)行讀? ?取，就實(shí)現(xiàn)了讀寫分離：
????基于X軸的解決方案，是全量鏡像的，什么意思呢？意思就是：X軸上的主Redis和副Redis的容量是一樣的，比如主Redis有10G，其他其他的副Redis同樣也是10G，那這樣的話，問(wèn)題2【數(shù)據(jù)容量有限】的問(wèn)題就出來(lái)了。數(shù)據(jù)有時(shí)候會(huì)遠(yuǎn)超10G的！
????從Y軸角度，對(duì)庫(kù)中的數(shù)據(jù)按照業(yè)務(wù)進(jìn)行劃分不同的實(shí)例去存儲(chǔ)：
????這樣，不同的數(shù)據(jù)就會(huì)存到不同的Redis中去，如此就可以解決【數(shù)據(jù)容量有限】的問(wèn)題。是不是有點(diǎn)像微服務(wù)拆分的原則？而AKF正式微服務(wù)拆分四項(xiàng)原則中的第一條，而且AKF不僅僅只限定于微服務(wù)，如數(shù)據(jù)庫(kù)，Tomcat都可以。 了解微服務(wù)拆分四項(xiàng)原則：https://www.cnblogs.com/guanghe/p/10978349.html
????基于Y軸一般是按照業(yè)務(wù)、功能等來(lái)劃分?jǐn)?shù)據(jù)，這是只針對(duì)于Y軸來(lái)說(shuō)，但Y軸上的每個(gè)節(jié)點(diǎn)也要解決【單點(diǎn)故障問(wèn)題】，所以就需要X軸、Y軸同時(shí)部署Redis實(shí)例矩陣。
????從Z軸角度，再對(duì)Y軸實(shí)例（某個(gè)業(yè)務(wù)）的數(shù)據(jù)進(jìn)行再次拆分
????假設(shè)Y軸上的某個(gè)節(jié)點(diǎn)存放的是“用戶信息”，那么從Z軸的角度來(lái)講，Z軸上的每個(gè)節(jié)點(diǎn)可以存放100萬(wàn)個(gè)用戶，不同的用戶出現(xiàn)在固定的庫(kù)里。一般Z軸是按照優(yōu)先級(jí)，或者特定的邏輯再進(jìn)行拆分，Z軸的出現(xiàn)，是為了確保解決【數(shù)據(jù)容量有限】和【壓力】的問(wèn)題。
????經(jīng)過(guò)X、Y、Z軸拆分之后，每臺(tái)實(shí)例的數(shù)據(jù)量已經(jīng)足夠小，當(dāng)數(shù)據(jù)量足夠小的時(shí)候，更能夠發(fā)揮單機(jī)的性能，再也沒(méi)有了容量的限制。而且，主Redis都還有多臺(tái)副Redis，就不會(huì)出現(xiàn)單點(diǎn)故障問(wèn)題。而且當(dāng)數(shù)據(jù)量足夠小的時(shí)候，訪問(wèn)量自然不會(huì)大。
????AFK三軸拆分后，引入的數(shù)據(jù)一致性問(wèn)題
????當(dāng)客戶端對(duì)Redis進(jìn)行寫的時(shí)候，主Redis先不返回客戶端是否寫入成功，而是先去通知副Redis同步復(fù)制寫入，主Redis在阻塞等待著，直到數(shù)據(jù)全部一致，主Redis再返回客戶端寫入成功：【強(qiáng)一致性】
這是通過(guò)同步方式達(dá)成的強(qiáng)一致性，但是強(qiáng)一致性的缺陷也很明顯，只要有一個(gè)Redis的網(wǎng)絡(luò)通信不好，就會(huì)導(dǎo)致所有的寫入失敗，所以強(qiáng)一致性極容易破壞可用性。簡(jiǎn)單說(shuō)，我用你了，但你不太好用，或者根本不能用。
????只要主Redis寫入成功，就直接和客戶端說(shuō)返回成功了，然后副Redis異步復(fù)制寫入Redis數(shù)據(jù)；【弱一致性】
這是通過(guò)異步方式達(dá)成弱一致性，但是弱一致性的缺陷在于，有可能主Redis寫入成功，但是副Redis沒(méi)有成功寫入，就導(dǎo)致副Redis丟失部分?jǐn)?shù)據(jù)。
????為了解決弱一致性問(wèn)題，可以在主Redis和眾多副Redis鐘搭建kafka，jnode等中間件去解決問(wèn)題。主Redis和kafka是阻塞的，主Redis必須等Kafka返回成功才可以向客戶端返回成功。而Kafka中的數(shù)據(jù)副Redis自己從中去取，然后寫入庫(kù)中。這個(gè)叫【最終一致性】。
