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