分布式定理

cap定理:一致性,可用性,分割槽容錯性

redis單機版的可靠性是由本地磁碟保證的,如果當前機器會宕機,那麼本地可靠性也沒有了

akf:x、y、z軸

x軸:全量映象,大家都一樣

y軸:根據功能業務區分資料,比如訂單、使用者資訊、頁面熱點資料,

z軸:在業務資料量極大,需要拆分業務資料到不同的redis裡,再根據業務拆分

redis單機不行,可能會宕機,那麼就x軸增強,加入多台redis,做redis例項副本,主備,客戶端只訪問第一台redis,第一台掛了下面的頂上.

開了這麼多機器,單單當備用機很浪費,增刪改往第一台機器寫,讀往後面的機器讀但是資料都是一樣的

redis在y軸就可以業務區分資料,訂單,熱點,使用者,mysql則是分庫分表

一變多,資料一致性問題

1號主機 2、3號備機

redis在x軸上就是1主2備,備不參與運算,主機時刻同步資料到備機,

資料一致性方式:client傳送資料到1號,1號傳送資料到2、3號,完畢後1號返回client,ok,這是資料強一致性,但是如果2號宕機了,那麼這個過程就永遠不會有返回,強一致性會破壞可用性,單redis變為多redis就是為了可用性.

修改一下,client資料發給1號機,1號機寫成功了就直接返回,1號機非同步的傳送資料給2、3號機完成資料一致性.但是會發生資料丟失一部分

再優化一下,在1號機後面增加乙個可靠的資料儲存軟體(kafka),同步將資料發到這,然後2、3號機從kafka裡取資料同步到自己這,(最終一致性)

但是最終一致性的黑盒集群,client可能會取到不一致的資料.主從

無論是主從還是主備,都有乙個主,主又是乙個單點,主掛了就沒了.

對主機做高可用,最終是要把備機變成主機

網路分割槽、腦裂,client取資料可以取到不一樣的資料,不一定是壞事,看是否可以容忍

主從複製,配置檔案中配置,主機資料複製到從節點

從節點在複製過程中是否可以被查詢原先的資料(分割槽容錯性)

redis可以先磁碟io將資料落盤,在將資料發給從節點,或者直接通過網路將資料發給從節點

增量複製,rdb被從節點讀取後,從節點下線再上線後,需要重新同步資料,全量同步效率低,於是可以配置乙個大小的佇列,佇列中儲存著增量的資料,然後將增量資料發給從節點

redis-server --sentienl

由於主節點知道自己的從節點,所以哨兵只需要監控主節點就可以,

通過發布訂閱模型,訂閱哨兵的主題,發現其他哨兵

乙個client通過編寫業務**將資料存放到多個redis節點中,有好幾種模型

1.單個redis進行業務分割槽.client編寫邏輯**區分redis,取模sharding分片,缺點是擴容困難,模數固定

2.客戶端隨機給某個redis節點,能往裡扔但是找不到,但是其他的客戶端,鏈結這兩個redis節點取資料就可以了,(訊息佇列,裡面的key就是topic,每個redis節點是partition)

3.一致性hash演算法,對映演算法,hash環,擴容時不會造成全域性洗牌,缺點是可能造成一小部分資料無法命中

上面的方式採用客戶端與redis直連,如果客戶端鏈結反向**伺服器,再由反向**伺服器連線redis,對客戶端**簡單許多,不會有上面三種y軸處理的方法.三種實現都被遷移到了**層

**層有了邏輯實現:modula,random,kemata

技術:twemproxy

有很多方式比如hash將資料分布到節點上.

1節點,2節點,存放著模數值範圍為1,2,3,4,5 6,7,8,9,0

如果此時新增加了乙個節點,那麼就需要從1,2號節點取出一些模數值遷移到3號節點,同時將模數值下的key也傳輸給3號節點

client連線redis時,隨機訪問乙個redis節點,每個redis節點有演算法,得到算出的值,比如取模的值,與自己節點有的模數值進行匹配,沒匹配上則檢視其他節點的模數值(每個redis節點都有其他節點的模數值,有點像eureka),每個redis節點都可以做路由

##資料分治問題:聚合操作,事物,取交集等

使用相同的key hash時會落到同乙個節點上

predixy

分布式定理

分布式定理 CAP定理

理解分布式CAP定理

分布式系統CAP定理

分布式定理

分布式定理 CAP定理

理解分布式CAP定理

分布式系統CAP定理

相關推薦