国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

干貨：分布式系統學習筆記

EsgynChina / 428人閱讀

摘要：即服務不能無響應，或出錯分區的容忍性，這里的分區不是指數據分布式存儲中的分區。假設一個分布式系統中，有兩個節點，處于分區狀態。在大多數的分布式系統設計中，人們多會選擇滿足兩點特性。為了解決最終的一致性，這就涉及到分布式事務。

一、分布式的兩大場景

數據存儲的分布式

服務的分布式

二、數據存儲的分布式

比如海量數據，單機存儲不下，需要多機，以集群的方式存儲，即為數據的分布式存儲，數據存儲的分布式一般涉及如下幾個方面

數據的分片策略

全局主鍵的實現機制

跨結點數據的聚合

分布式事務

數據容災機制

2.1數據分片策略

2.1.1 基于數據范圍來分

比如庫1,存放id 1到1000w的數據，庫2存放id 1000w到2000w的數據

優點 ：

單庫數據規模提前預估。超規模后，加機器，不需要遷移數據。

且相鄰數據大都存放在一個庫上，查詢時，可以減少跨庫聚合。

缺點

容易出現熱點數據，比如項目初期，只有庫1被高頻率訪問

待解決問題 ：業務變更導致部分數據被刪除后，如何做到數據容量的在平衡。一般也不用考慮這個問題。空間不值錢。

2.1.2 基于id hash來分

優點 ：hash分配，數據分布均勻不會出現數據熱點問題

缺點

數據的查詢聚合可能需要頻繁跨庫。解決辦法：hash算法和用于計算hash的key去保證，將業務關心的數據分片到同一庫，甚至同一張表

集群擴容時，會導致重新hash。可能面臨部分數據的遷移

2.1.3 怎么解決擴容時，數據重新hash的問題

方法來至于58沈劍。主要思想：分布式存儲的每個庫，出于數據可用性的考慮，設置一個主從庫，這使得一份數據，有兩份存儲。擴容時，將每個從庫，變成主庫。于是容量就擴容了一倍，修改后的hash算法，依然能正確路由。同時由于新的主庫包含了完整的數據，所以不需要做數據遷移，只需要做冗余數據的清理。圖例如下：

擴容之前的狀態

擴容，將從變主。%2=0的庫，會變為%4=0與%4=2 。%2=1的部分，會變為%4=1與%4=3;

對擴容后的所有主數據庫，新增從庫，方便下次的翻倍擴容。刪除冗余數據

2.2全局主鍵的實現機制

snowflake

2.3跨結點數據的聚合

對于跨節點聚合有兩種思路，一是通過現有數據庫，從查詢算法上考慮。第二種，對于過于復雜的聚合統計查詢，使用外置索引來實現，比如elasticsearch

第一種，幾種跨庫分頁的方式

http://www.10tiao.com/html/24...

第二種，索引外置，比如使用elasticsearch。參看elasticsearch 原理

三、服務的分布式

服務的分布式，一般涉及如下幾個方面

服務注冊

服務發現

負載均衡

分布式事務

服務的降級熔斷

3.1服務的注冊

3.2服務的發現

3.3負載均衡

以上三點的大概模式，可以參看之前的筆記微服務的注冊與發現 https://chen-jun.me/wei-fu-wu...

3.4分布式事務

3.5服務的降級熔斷

服務的降級熔斷，可以在兩方面做文章。比如A服務調用B服務。當B服務處理失敗，導致A服務故障時。在A端，可以設置熔斷，當故障率達到一定，A服務可以有一個默認值，不在調用B服務。B服務本身，也可以在A調用自己出故障時，不走計算流程，直接返回一個默認值。這方面的框架有Spring Cloud Hystrix

Spring Cloud Hystrix是基于Netflix的開源框架Hystrix實現，該框架實現了服務熔斷、線程隔離等一系列服務保護功能。

對于熔斷機制的實現，Hystrix設計了三種狀態：

1.熔斷關閉狀態（Closed）

服務沒有故障時，熔斷器所處的狀態，對調用方的調用不做任何限制。

2.熔斷開啟狀態（Open）

在固定時間窗口內（Hystrix默認是10秒），接口調用出錯比率達到一個閾值（Hystrix默認為50%），會進入熔斷開啟狀態。進入熔斷狀態后，后續對該服務接口的調用不再經過網絡，直接執行本地的fallback方法。

3.半熔斷狀態（Half-Open）

在進入熔斷開啟狀態一段時間之后（Hystrix默認是5秒），熔斷器會進入半熔斷狀態。所謂半熔斷就是嘗試恢復服務調用，允許有限的流量調用該服務，并監控調用成功率。如果成功率達到預期，則說明服務已恢復，進入熔斷關閉狀態；如果成功率仍舊很低，則重新進入熔斷關閉狀態。

關系轉換圖如下

四、 分布式事務

4.1 CAP理論

CAP理論是 Eric Brewer提出的一種分布式狀況下，面臨的三個無法同時兼顧的問題

Consistency所有分布式節點，對同一份數據，擁有相同的副本。不會出現數據不一致的情況

Availability對數據的更新和讀寫，具有高可用性。即服務不能無響應，或出錯

Partition Tolerance分區的容忍性，這里的分區不是指數據分布式存儲中的shard分區。而是指，由于諸如網絡等原因，導致分布式節點之間，無法正常同性時，導致的結點隔離，成為分區。在分區時，整個系統還能允許多大程度的對外服務，成為分區容忍性。

假設一個分布式系統中，有兩個節點，處于分區狀態。若允許分區中節點可以更新數據，那么會喪失一致性 C 。如果要保證一致性 C ，那處于分區狀態的節點將不允許提供服務，這又會喪失可用性 A 。如果一定要保證 CA ，必須保證節點之間能夠互相通信，那分區就不能容忍，就無從談起分區容忍性 P

Eric Brewer提出，在分布式環境下，一個系統只能同時滿足以上兩點特性，而無法同時滿足所有特性。在大多數的分布式系統設計中，人們多會選擇滿足 AP 兩點特性。而放棄強一致性，轉而追求最終一致性。這種選擇還有另外一個描述叫： B asically A vailable, S oft-state, E ventually consistent 簡稱 BASE

以上CAP理論的簡潔抽象，容易讓人們大概理解分布式系統中的難處，但也容易產生一些誤導。那就是CAP中的3選2，并不是絕對的。所有Eric Brewer后來又做了一次澄清解釋。為什么有誤導？

1、很多時候，如果我們不能保證P，那CA也無從談起

比如用戶是通過html訪問服務的，這個服務對應的節點，出現分區，導致html都無法訪問時。那CA 就不用提了。只有在html能在客戶端緩存，支持用戶離線模式，才可以說系統保證了 P ,同時保證了 A

2、保證AP,并不是完全放棄C，當恢復分區時，我們依然要采取各種方式解決分區導致的不一致。

由于網絡延遲，或網絡斷連，甚至一個寫請求，同步至所有節點，由于節點跨機房，寫完成的時間不同步，都可能導致分區。只是分區的時間長短不一而已。為了解決最終的一致性，這就涉及到分布式事務。對于分布式數據庫中，某個值的寫，保證其一致性，可以使用paxos,raft協議算法。對于業務類型的事務。可以使用TCC或者消息通知的模式來進行事務管理

4.2 最終一致性方案——paxos,raft

zookeeper就是使用的paxos協議

4.3最終一致性方案——TCC

分為 T ry , C onfirm, C ancel ，簡稱TCC。

Try:嘗試鎖定事務涉及的資源，進行資源預留

Confirm:對預留的資源做確認提交

Cancel:如果confirm失敗，則進行補償操作，回滾業務處理，解鎖預留資源

可以看到這種，try , confrm/cancel。也是兩階段。那跟傳統JAT支持的兩階段事務有什么區別？

JTA支持的傳統兩階段事務，需要涉及的資源支持XA協議標準，但TCC則需要遵循什么工業標準，可以是完全的業務實現。傳統的兩階段提交，任然要求滿足事務的ACID，這導致資源的可用性很差。

傳統兩階段提交的特點：

TCC事務的特點：

4.4 最終一致性方案——消息通知

這類事務的特點是，需要借助消息通知，來使得事務涉及的多個分布式服務能夠協調，完成業務期望。這種方式，也有幾種細分的設計。

4.4.1 使用本地事務

同一個共用的消息表，來協調服務雙方的業務執行狀況

4.4.2 使用MQ

4.4.3 另外一種使用MQ的方式

想要了解更多分布式知識點的，可以關注我一下，我后續也會整理更多關于分布式架構這一塊的知識點分享出來

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11843.html

相關文章

  • 干貨：分布式系統學習筆記

    摘要：即服務不能無響應，或出錯分區的容忍性，這里的分區不是指數據分布式存儲中的分區。假設一個分布式系統中，有兩個節點，處于分區狀態。在大多數的分布式系統設計中，人們多會選擇滿足兩點特性。為了解決最終的一致性，這就涉及到分布式事務。 showImg(https://segmentfault.com/img/bV7kd4?w=500&h=253); 一、分布式的兩大場景 數據存儲的分布式 服務的...

    劉德剛 評論0 收藏0

  • 后臺開發常問面試題集錦（問題搬運工，附鏈接）

    摘要：基礎問題的的性能及原理之區別詳解備忘筆記深入理解流水線抽象關鍵字修飾符知識點總結必看篇中的關鍵字解析回調機制解讀抽象類與三大特征時間和時間戳的相互轉換為什么要使用內部類對象鎖和類鎖的區別，，優缺點及比較提高篇八詳解內部類單例模式和 Java基礎問題 String的+的性能及原理 java之yield(),sleep(),wait()區別詳解-備忘筆記 深入理解Java Stream流水...

    spacewander 評論0 收藏0

  • 后臺開發常問面試題集錦（問題搬運工，附鏈接）

    摘要：基礎問題的的性能及原理之區別詳解備忘筆記深入理解流水線抽象關鍵字修飾符知識點總結必看篇中的關鍵字解析回調機制解讀抽象類與三大特征時間和時間戳的相互轉換為什么要使用內部類對象鎖和類鎖的區別，，優缺點及比較提高篇八詳解內部類單例模式和 Java基礎問題 String的+的性能及原理 java之yield(),sleep(),wait()區別詳解-備忘筆記 深入理解Java Stream流水...

    xfee 評論0 收藏0

  • 后臺開發常問面試題集錦（問題搬運工，附鏈接）

    摘要：基礎問題的的性能及原理之區別詳解備忘筆記深入理解流水線抽象關鍵字修飾符知識點總結必看篇中的關鍵字解析回調機制解讀抽象類與三大特征時間和時間戳的相互轉換為什么要使用內部類對象鎖和類鎖的區別，，優缺點及比較提高篇八詳解內部類單例模式和 Java基礎問題 String的+的性能及原理 java之yield(),sleep(),wait()區別詳解-備忘筆記 深入理解Java Stream流水...

    makeFoxPlay 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<