A. 分布式存儲是什麼
分布式存儲系統，是將數據分散存儲在多台獨立的設備上。傳統的網路存儲系統採用集中的存儲伺服器存放所有數據，存儲伺服器成為系統性能的瓶頸，也是可靠性和安全性的焦點，不能滿足大規模存儲應用的需要。分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，它不但提高了系統的可靠性、可用性和存取效率，還易於擴展。
分布式和集中式存儲
集中存儲的優缺點是，物理介質集中布放;視頻流上傳到中心對機房環境要求高，要求機房空間大，承重、空調等都是需要考慮的問題。
分布存儲，集中管理的優缺點是，物理介質分布到不同的地理位置;視頻流就近上傳，對骨幹網帶寬沒有什麼要求;可採用多套低端的小容量的存儲設備分布部署，設備價格和維護成本較低;小容量設備分布部署，對機房環境要求低。
鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。
B. 分布式緩存主要用在高並發環境下的作用
分布式緩存主要用在高並發環境下，減輕資料庫的壓力，提高系統的響應速度和並發吞吐。當大量的讀、寫請求湧向資料庫時，磁碟的處理速度與內存顯然不在一個量級，因此，在資料庫之前加一層緩存，能夠顯著提高系統的響應速度，並降低資料庫的壓力。作為傳統的關系型資料庫，Mysql提供完整的ACID操作，支持豐富的數據類型、強大的關聯查詢、where語句等，能夠非常客易地建立查詢索引，執行復雜的內連接、外連接、求和、排序、分組等操作，並且支持存儲過程、函數等功能，產品成熟度高，功能強大。但是，對於需要應對高並發訪問並且存儲海量數據的場景來說，出於對性能的考慮，不得不放棄很多傳統關系型資料庫原本強大的功能，犧牲了系統的易用性，並且使得系統的設計和管理變得更為復雜。這也使得在過去幾年中，流行著另一種新的存儲解決方案——NoSQL，它與傳統的關系型資料庫最大的差別在於，它不使用SQL作為查詢語言來查找數據，而採用key-value形式進行查找，提供了更高的查詢效率及吞吐，並且能夠更加方便地進行擴展，存儲海量數據，在數千個節點上進行分區，自動進行數據的復制和備份。在分布式系統中，消息作為應用間通信的一種方式，得到了十分廣泛的應用。消息可以被保存在隊列中，直到被接收者取出，由於消息發送者不需要同步等待消息接收者的響應，消息的非同步接收降低了系統集成的耦合度，提升了分布式系統協作的效率，使得系統能夠更快地響應用戶，提供更高的吞吐。
當系統處於峰值壓力時，分布式消息隊列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個系統被壓垮。垂直化的搜索引擎在分布式系統中是一個非常重要的角色，它既能夠滿足用戶對於全文檢索、模糊匹配的需求，解決資料庫like查詢效率低下的問題，又能夠解決分布式環境下，由於採用分庫分表，或者使用NoSQL資料庫，導致無法進行多表關聯或者進行復雜查詢的問題。
C. 分布式存儲有哪幾種類型
分布式存儲，分為文件存儲，塊存儲和對象存儲，是存儲設備提供的不同類型的服務，適配不同的使用場景。
分布式是存儲設備的部署方式，是部署在一台機器上，還是一個多台設備組成的集群中。軟體定義這個概念比較寬泛，是指通過軟體功能來實現曾經通過專用硬體完成的工作，也就是說，對於存儲硬體已經沒有要求了，用通用硬體+存儲軟體來實現將一台伺服器，變成存儲設備。其實無論是不是軟體定義存儲，其內部都運行著存儲系統軟體，把這個詞單拿出來，就是更加強調其對於硬體的無要求。
D. 高並發，你真的理解透徹了嗎
高並發，幾乎是每個程序員都想擁有的經驗。原因很簡單：隨著流量變大，會遇到各種各樣的技術問題，比如介面響應超時、CPU load升高、GC頻繁、死鎖、大數據量存儲等等，這些問題能推動我們在技術深度上不斷精進。
在過往的面試中，如果候選人做過高並發的項目，我通常會讓對方談談對於高並發的理解，但是能系統性地回答好此問題的人並不多。
大概分成這樣幾類：
1、對數據化的指標沒有概念 ：不清楚選擇什麼樣的指標來衡量高並發系統？分不清並發量和QPS，甚至不知道自己系統的總用戶量、活躍用戶量，平峰和高峰時的QPS和TPS等關鍵數據。
3、理解片面，把高並發設計等同於性能優化 ：大談並發編程、多級緩存、非同步化、水平擴容，卻忽視高可用設計、服務治理和運維保障。
4、掌握大方案，卻忽視最基本的東西 ：能講清楚垂直分層、水平分區、緩存等大思路，卻沒意識去分析數據結構是否合理，演算法是否高效，沒想過從最根本的IO和計算兩個維度去做細節優化。
這篇文章，我想結合自己的高並發項目經驗，系統性地總結下高並發需要掌握的知識和實踐思路，希望對你有所幫助。內容分成以下3個部分：
高並發意味著大流量，需要運用技術手段抵抗流量的沖擊，這些手段好比操作流量，能讓流量更平穩地被系統所處理，帶給用戶更好的體驗。
我們常見的高並發場景有：淘寶的雙11、春運時的搶票、微博大V的熱點新聞等。除了這些典型事情，每秒幾十萬請求的秒殺系統、每天千萬級的訂單系統、每天億級日活的信息流系統等，都可以歸為高並發。
很顯然，上面談到的高並發場景，並發量各不相同， 那到底多大並發才算高並發呢？
1、不能只看數字，要看具體的業務場景。不能說10W QPS的秒殺是高並發，而1W QPS的信息流就不是高並發。信息流場景涉及復雜的推薦模型和各種人工策略，它的業務邏輯可能比秒殺場景復雜10倍不止。因此，不在同一個維度，沒有任何比較意義。
2、業務都是從0到1做起來的，並發量和QPS只是參考指標，最重要的是：在業務量逐漸變成原來的10倍、100倍的過程中，你是否用到了高並發的處理方法去演進你的系統，從架構設計、編碼實現、甚至產品方案等維度去預防和解決高並發引起的問題？而不是一味的升級硬體、加機器做水平擴展。
此外，各個高並發場景的業務特點完全不同：有讀多寫少的信息流場景、有讀多寫多的交易場景， 那是否有通用的技術方案解決不同場景的高並發問題呢？
我覺得大的思路可以借鑒，別人的方案也可以參考，但是真正落地過程中，細節上還會有無數的坑。另外，由於軟硬體環境、技術棧、以及產品邏輯都沒法做到完全一致，這些都會導致同樣的業務場景，就算用相同的技術方案也會面臨不同的問題，這些坑還得一個個趟。
因此，這篇文章我會將重點放在基礎知識、通用思路、和我曾經實踐過的有效經驗上，希望讓你對高並發有更深的理解。
先搞清楚高並發系統設計的目標，在此基礎上再討論設計方案和實踐經驗才有意義和針對性。
高並發絕不意味著只追求高性能，這是很多人片面的理解。從宏觀角度看，高並發系統設計的目標有三個：高性能、高可用，以及高可擴展。
1、高性能：性能體現了系統的並行處理能力，在有限的硬體投入下，提高性能意味著節省成本。同時，性能也反映了用戶體驗，響應時間分別是100毫秒和1秒，給用戶的感受是完全不同的。
2、高可用：表示系統可以正常服務的時間。一個全年不停機、無故障；另一個隔三差五齣線上事故、宕機，用戶肯定選擇前者。另外，如果系統只能做到90%可用，也會大大拖累業務。
3、高擴展：表示系統的擴展能力，流量高峰時能否在短時間內完成擴容，更平穩地承接峰值流量，比如雙11活動、明星離婚等熱點事件。
這3個目標是需要通盤考慮的，因為它們互相關聯、甚至也會相互影響。
比如說：考慮系統的擴展能力，你會將服務設計成無狀態的，這種集群設計保證了高擴展性，其實也間接提升了系統的性能和可用性。
再比如說：為了保證可用性，通常會對服務介面進行超時設置，以防大量線程阻塞在慢請求上造成系統雪崩，那超時時間設置成多少合理呢？一般，我們會參考依賴服務的性能表現進行設置。
再從微觀角度來看，高性能、高可用和高擴展又有哪些具體的指標來衡量？為什麼會選擇這些指標呢？
2.2.1 性能指標
通過性能指標可以度量目前存在的性能問題，同時作為性能優化的評估依據。一般來說，會採用一段時間內的介面響應時間作為指標。
1、平均響應時間：最常用，但是缺陷很明顯，對於慢請求不敏感。比如1萬次請求，其中9900次是1ms，100次是100ms，則平均響應時間為1.99ms，雖然平均耗時僅增加了0.99ms，但是1%請求的響應時間已經增加了100倍。
2、TP90、TP99等分位值：將響應時間按照從小到大排序，TP90表示排在第90分位的響應時間， 分位值越大，對慢請求越敏感。
3、吞吐量：和響應時間呈反比，比如響應時間是1ms，則吞吐量為每秒1000次。
通常，設定性能目標時會兼顧吞吐量和響應時間，比如這樣表述：在每秒1萬次請求下，AVG控制在50ms以下，TP99控制在100ms以下。對於高並發系統，AVG和TP分位值必須同時要考慮。
另外，從用戶體驗角度來看，200毫秒被認為是第一個分界點，用戶感覺不到延遲，1秒是第二個分界點，用戶能感受到延遲，但是可以接受。
因此，對於一個 健康 的高並發系統，TP99應該控制在200毫秒以內，TP999或者TP9999應該控制在1秒以內。
2.2.2 可用性指標
高可用性是指系統具有較高的無故障運行能力，可用性 = 正常運行時間 / 系統總運行時間，一般使用幾個9來描述系統的可用性。
對於高並發系統來說，最基本的要求是：保證3個9或者4個9。原因很簡單，如果你只能做到2個9，意味著有1%的故障時間，像一些大公司每年動輒千億以上的GMV或者收入，1%就是10億級別的業務影響。
2.2.3 可擴展性指標
面對突發流量，不可能臨時改造架構，最快的方式就是增加機器來線性提高系統的處理能力。
對於業務集群或者基礎組件來說，擴展性 = 性能提升比例 / 機器增加比例，理想的擴展能力是：資源增加幾倍，性能提升幾倍。通常來說，擴展能力要維持在70%以上。
但是從高並發系統的整體架構角度來看，擴展的目標不僅僅是把服務設計成無狀態就行了，因為當流量增加10倍，業務服務可以快速擴容10倍，但是資料庫可能就成為了新的瓶頸。
像MySQL這種有狀態的存儲服務通常是擴展的技術難點，如果架構上沒提前做好規劃（垂直和水平拆分），就會涉及到大量數據的遷移。
因此，高擴展性需要考慮：服務集群、資料庫、緩存和消息隊列等中間件、負載均衡、帶寬、依賴的第三方等，當並發達到某一個量級後，上述每個因素都可能成為擴展的瓶頸點。
了解了高並發設計的3大目標後，再系統性總結下高並發的設計方案，會從以下兩部分展開：先總結下通用的設計方法，然後再圍繞高性能、高可用、高擴展分別給出具體的實踐方案。
通用的設計方法主要是從「縱向」和「橫向」兩個維度出發，俗稱高並發處理的兩板斧：縱向擴展和橫向擴展。
3.1.1 縱向擴展（scale-up）
它的目標是提升單機的處理能力，方案又包括：
1、提升單機的硬體性能：通過增加內存、 CPU核數、存儲容量、或者將磁碟 升級成SSD 等堆硬體的方式來提升。
2、提升單機的軟體性能：使用緩存減少IO次數，使用並發或者非同步的方式增加吞吐量。
3.1.2 橫向擴展（scale-out）
因為單機性能總會存在極限，所以最終還需要引入橫向擴展，通過集群部署以進一步提高並發處理能力，又包括以下2個方向：
1、做好分層架構：這是橫向擴展的提前，因為高並發系統往往業務復雜，通過分層處理可以簡化復雜問題，更容易做到橫向擴展。
上面這種圖是互聯網最常見的分層架構，當然真實的高並發系統架構會在此基礎上進一步完善。比如會做動靜分離並引入CDN，反向代理層可以是LVS+Nginx，Web層可以是統一的API網關，業務服務層可進一步按垂直業務做微服務化，存儲層可以是各種異構資料庫。
2、各層進行水平擴展：無狀態水平擴容，有狀態做分片路由。業務集群通常能設計成無狀態的，而資料庫和緩存往往是有狀態的，因此需要設計分區鍵做好存儲分片，當然也可以通過主從同步、讀寫分離的方案提升讀性能。
下面再結合我的個人經驗，針對高性能、高可用、高擴展3個方面，總結下可落地的實踐方案。
3.2.1 高性能的實踐方案
1、集群部署，通過負載均衡減輕單機壓力。
2、多級緩存，包括靜態數據使用CDN、本地緩存、分布式緩存等，以及對緩存場景中的熱點key、緩存穿透、緩存並發、數據一致性等問題的處理。
3、分庫分表和索引優化，以及藉助搜索引擎解決復雜查詢問題。
4、考慮NoSQL資料庫的使用，比如HBase、TiDB等，但是團隊必須熟悉這些組件，且有較強的運維能力。
5、非同步化，將次要流程通過多線程、MQ、甚至延時任務進行非同步處理。
6、限流，需要先考慮業務是否允許限流（比如秒殺場景是允許的），包括前端限流、Nginx接入層的限流、服務端的限流。
7、對流量進行 削峰填谷 ，通過 MQ承接流量。
8、並發處理，通過多線程將串列邏輯並行化。
9、預計算，比如搶紅包場景，可以提前計算好紅包金額緩存起來，發紅包時直接使用即可。
10、 緩存預熱 ，通過非同步 任務 提前 預熱數據到本地緩存或者分布式緩存中。
11、減少IO次數，比如資料庫和緩存的批量讀寫、RPC的批量介面支持、或者通過冗餘數據的方式幹掉RPC調用。
12、減少IO時的數據包大小，包括採用輕量級的通信協議、合適的數據結構、去掉介面中的多餘欄位、減少緩存key的大小、壓縮緩存value等。
13、程序邏輯優化，比如將大概率阻斷執行流程的判斷邏輯前置、For循環的計算邏輯優化，或者採用更高效的演算法。
14、各種池化技術的使用和池大小的設置，包括HTTP請求池、線程池（考慮CPU密集型還是IO密集型設置核心參數）、資料庫和Redis連接池等。
15、JVM優化，包括新生代和老年代的大小、GC演算法的選擇等，盡可能減少GC頻率和耗時。
16、鎖選擇，讀多寫少的場景用樂觀鎖，或者考慮通過分段鎖的方式減少鎖沖突。
上述方案無外乎從計算和 IO 兩個維度考慮所有可能的優化點，需要有配套的監控系統實時了解當前的性能表現，並支撐你進行性能瓶頸分析，然後再遵循二八原則，抓主要矛盾進行優化。
3.2.2 高可用的實踐方案
1、對等節點的故障轉移，Nginx和服務治理框架均支持一個節點失敗後訪問另一個節點。
2、非對等節點的故障轉移，通過心跳檢測並實施主備切換（比如redis的哨兵模式或者集群模式、MySQL的主從切換等）。
3、介面層面的超時設置、重試策略和冪等設計。
4、降級處理：保證核心服務，犧牲非核心服務，必要時進行熔斷；或者核心鏈路出問題時，有備選鏈路。
5、限流處理：對超過系統處理能力的請求直接拒絕或者返回錯誤碼。
6、MQ場景的消息可靠性保證，包括procer端的重試機制、broker側的持久化、consumer端的ack機制等。
7、灰度發布，能支持按機器維度進行小流量部署，觀察系統日誌和業務指標，等運行平穩後再推全量。
8、監控報警：全方位的監控體系，包括最基礎的CPU、內存、磁碟、網路的監控，以及Web伺服器、JVM、資料庫、各類中間件的監控和業務指標的監控。
9、災備演練：類似當前的「混沌工程」，對系統進行一些破壞性手段，觀察局部故障是否會引起可用性問題。
高可用的方案主要從冗餘、取捨、系統運維3個方向考慮，同時需要有配套的值班機制和故障處理流程，當出現線上問題時，可及時跟進處理。
3.2.3 高擴展的實踐方案
1、合理的分層架構：比如上面談到的互聯網最常見的分層架構，另外還能進一步按照數據訪問層、業務邏輯層對微服務做更細粒度的分層（但是需要評估性能，會存在網路多一跳的情況）。
2、存儲層的拆分：按照業務維度做垂直拆分、按照數據特徵維度進一步做水平拆分（分庫分表）。
3、業務層的拆分：最常見的是按照業務維度拆（比如電商場景的商品服務、訂單服務等），也可以按照核心介面和非核心介面拆，還可以按照請求源拆（比如To C和To B，APP和H5 ）。
高並發確實是一個復雜且系統性的問題，由於篇幅有限，諸如分布式Trace、全鏈路壓測、柔性事務都是要考慮的技術點。另外，如果業務場景不同，高並發的落地方案也會存在差異，但是總體的設計思路和可借鑒的方案基本類似。
高並發設計同樣要秉承架構設計的3個原則：簡單、合適和演進。"過早的優化是萬惡之源"，不能脫離業務的實際情況，更不要過度設計，合適的方案就是最完美的。
作者簡介：985碩士，前亞馬遜工程師，現大廠技術管理者。
E. 什麼是分布式存儲
分布式存儲簡單的來說，就是將數據分散存儲到多個存儲伺服器上，並將這些分散的存儲資源構成一個虛擬的存儲設備，實際上數據分散的存儲在企業的各個角落。
還可以這樣理解：
利用分布式技術將標准X86伺服器的本地HDD、SSD等存儲介質組織成一個大規模存儲資源池，同時，對上層的應用和虛擬機提供工業界標準的SCSI、iSCSI和對象訪問介面，進而打造一個虛擬的分布式統一存儲產品。
F. 海量分布式存儲系統Doris原理概述
Doris( https://github.com/itisaid/Doris )是一個海量分布式 KV 存儲系統，其設計目 標是支持中等規模高可用可伸縮的 KV 存儲集群。
Doris可以實現海量存儲，線性伸縮、平滑擴容，自動容錯、故障轉移，高並發，且運維成本低。部署規模，建議部署4-100+台伺服器。
Doris採用兩層架構，Client 和 DataServer+Store。
有四個核心組件，Client、DataServer、Store、Administration。
應用程序通過Client SDK進行Doris的訪問，
每台伺服器上部署一個Data Sever做伺服器的管理，每台伺服器上有自己的存儲Store，整個集群的數據存儲，每台機器獨立部署。數據通過路由選擇寫入到不同的機器中。
Administration為管理中心，提供配置、管理和監控。
config指，應用程序啟動一個Data Server，在啟動時要配置管理中心的ip地址，通關管理中心。管理中心會修改配置項感知到集群中加了新機器，對新機器管理，擴容等。待機器處於可用狀態，將該機器的配置項通知給KV Client。從而KV Client進行新的路由選擇。
擴容、下線機器等的控制台界面通過Management管理。
Monitor監控機器是否正常。
client寫數據，綁定產品的namespace（邏輯隔離），構成新key，路由到具體機器上讀寫。
路由解析演算法是設計的一個關鍵點，決定集群的管理方式，也決定了集群擴容的復雜性和難度。
Doris的演算法類似redis，有桶的概念，key映射到1w個虛擬節點，虛擬節點在映射到物理節點。
由於Doris設計時，用於4-100+規模的集群。因此，Doris分了1w個虛擬節點，當伺服器超過100會導致負載不均衡，1000會更差，相當於每一個集群上有10個虛擬節點，虛擬節點會有10%的影響。
擴容時，需要調節虛擬節點指向新的位置。具體過程為，暴利輪詢新節點添加後，一個伺服器上應該承載的虛擬節點個數，將超出的虛擬節點遷移到新機器即可。如上圖左圖有2個物理節點，擴容後，有3個物理節點，變為右圖。
為了保證高可用。doris所有服務分成2個組，兩組伺服器對等。兩個group是可以有不同數量的伺服器。
寫操作時，client的路由演算法在兩個group分別選2個伺服器，分別（同時）寫入，兩個伺服器全部返回後，再繼續向下進行。讀操作時，從兩個伺服器隨機選一個讀。這樣，提高可用性，數據持久性，不會丟失。
集群管理的重要角色Config Server，有一個功能是負責發現故障伺服器。
發現故障的方式有2種：
節點失效分為：瞬間失效、臨時失效、永久失效
應用伺服器向伺服器寫，如果寫失敗，為 瞬間失效 。接著應用伺服器進行3次重試。3次都失敗，通知管理伺服器，進行服務的失效判斷。
管理伺服器再寫一次，如果寫成功，認為是客戶端自己通信通信問題。如果寫入失敗，判斷為 臨時失效 ，通知所有client，伺服器失效，不要寫，也不讀。
如果2小時恢復，則節點為臨時失效。如果2小時沒有恢復，認為是 永久失效 。
如圖，如果節點2失效，進入臨時失效階段。
如圖，節點2臨時失效2個小時還未恢復，判定為永久失效。進入永久失效的恢復。
設計中，有臨時日誌節點（備份節點），有空白節點。實際使用中沒有節點3空白節點。原因：1 自動遷移有風險，還是需要手動遷移。2 幾年宕機1台，一直有一個空白節點standby浪費。一般晚上報警失效也沒有事情，第二天，找機器擴容即可。認為24小時之內，同樣編號的2台機器連續down掉，概率很低。
物理節點分成2個group，寫的時候，向2個group同時寫。當其中一個group擴容機器時，該group上的所有節點進入臨時失效狀態。停止讀寫，將數據遷移到新的伺服器上。
由於是虛擬節點的映射在調整，所以遷移是按照虛擬節點調整。為了遷移方便，虛擬節點物理化，一個虛擬節點對應一個文件。遷移時其實就是拷貝文件。這時，如果group1有節點失效也會出現不一致，但是，通常擴容的過程很快，因為，是scp拷貝文件，瓶頸為網路帶寬，通常幾十T數據，幾分鍾遷移完成，十來分鍾進行數據恢復。
G. 分布式雲存儲屬於sqlserver嗎
不屬於，分布式雲存儲屬於IPFS
分布式雲存儲,簡單說就是以區塊鏈的組成模式來存儲，碎片化分散存儲。
我們把信息存儲在區塊上，每一個區塊都會記錄著前一個區塊的ID，形成鏈條，並且不可逆不可更改。
分布式雲存儲可以理解為一個滴滴司機，不斷地轉運數據且碎片化，所有人都可以訪問公開的區塊鏈數據，並且可以通過交易來寫入。 礦工通過密碼學技術來參與數據維護賺取少量的利潤。 運行成本低，人人可以記賬，避免了第三方的暗箱操作。
假如這項技術普及，我覺得我們的電腦就不需要硬碟了，電腦直接通過網路，抓取區塊寫入，當我們需要的時候，通過私鑰來下載。
一個硬碟的價格是很貴的，但我們可能只花十分之一的錢就能得到類似的存儲服務，何樂而不為呢。
我們的私鑰僅僅保留在自己的手中，並且碎片化存儲時，拿到完整的文件代碼可能不僅僅是一個私鑰可以解決的，還可能需要人工智慧認證來激活私鑰，比如刷臉、指紋幾種共識共同形成閉環。
不過前提是我們需要高度發達的網路互聯以及成熟的資料庫基礎。2000年的時候，多數人們並不相信互聯網，覺得虛擬的東西不靠譜，經過多年印證，互聯網完全可以顛覆我們的生活，實現各種智能。
那麼現今的區塊鏈雖然不成熟，不過區塊鏈有著另一個層面上顛覆我們認知的潛力。
基於區塊鏈的分布式雲存儲主要具有如下特點：
1. 實現碎片資源的可利用
每個人都可以通過分享個人的硬碟空間獲得金錢回報。這個金錢回報由租戶直接支付 給個人，提供服務的平台只收取微小的服務費。可以理解為平台就是硬碟存儲的Uber。
2. 大眾廣泛參與
所有人都可以訪問公開區塊鏈上的數據，所有人都可以發出交易等待被寫入區塊鏈。 共識過程的參與者（對應比特幣中的礦工）通過密碼學技術以及內建的經濟激勵維護資料庫的安全。
3. 高效、低成本運行
區塊鏈技術在網路上是公開、透明、開源的。不需要通過任何的機構及組織，可以隨 時隨地上傳、下載所需要的信息。比起購買昂貴的存儲設備及配套的人力來說，租用硬碟 空間比較經濟、實惠。
4. 較高的安全性
傳統的雲存儲公司購買或租用伺服器來存儲他們的客戶文件，同時使用RAID方案或 多數據中心的方
H. 深入理解分布式事務，高並發下分布式事務的解決方案
1、什麼是分布式事務
分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。以上是網路的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分布式事務就是為了保證不同資料庫的數據一致性。
2、分布式事務的產生的原因
2.1、資料庫分庫分表
當資料庫單表一年產生的數據超過1000W，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的一個資料庫變成了多個資料庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，那麼就要用到分布式事務。
2.2、應用SOA化
所謂的SOA化，就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對於訂單中心，有專門的資料庫存儲訂單信息，用戶中心也有專門的資料庫存儲用戶信息，庫存中心也會有專門的資料庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那麼就會涉及到訂單資料庫和庫存資料庫，為了保證數據一致性，就需要用到分布式事務。
以上兩種情況表象不同，但是本質相同，都是因為要操作的資料庫變多了！
3、事務的ACID特性
3.1、原子性（A）
所謂的原子性就是說，在整個事務中的所有操作，要麼全部完成，要麼全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。
3.2、一致性（C）
事務的執行必須保證系統的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那麼不管並發多少，不管發生什麼，只要事務執行成功了，那麼最後A賬戶一定是450元，B賬戶一定是350元。
3.3、隔離性（I）
所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。
3.4、持久性（D）
所謂的持久性，就是說一單事務完成了，那麼事務對數據所做的變更就完全保存在了資料庫中，即使發生停電，系統宕機也是如此。
4、分布式事務的應用場景
4.1、支付
最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執行，要麼全部成功，要麼全部失敗。而對於買家賬戶屬於買家中心，對應的是買家資料庫，而賣家賬戶屬於賣家中心，對應的是賣家資料庫，對不同資料庫的操作必然需要引入分布式事務。
4.2、在線下單
買家在電商平台下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態，庫存和訂單一般屬於不同的資料庫，需要使用分布式事務保證數據一致性。
5、常見的分布式事務解決方案
5.1、基於XA協議的兩階段提交
XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如Oracle、DB2這些商業資料庫都實現了XA介面，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：
總的來說，XA協議比較簡單，而且一旦商業資料庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往並發量很高，XA無法滿足高並發場景。XA目前在商業資料庫支持的比較理想，在mysql資料庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。
5.2、消息事務+最終一致性
所謂的消息事務就是基於消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要麼本地操作成功成功並且對外發消息成功，要麼兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：
1、A系統向消息中間件發送一條預備消息
2、消息中間件保存預備消息並返回成功
3、A執行本地事務
4、A發送提交消息給消息中間件
通過以上4步完成了一個消息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：
步驟一出錯，則整個事務失敗，不會執行A的本地操作步驟二出錯，則整個事務失敗，不會執行A的本地操作步驟三出錯，這時候需要回滾預備消息，怎麼回滾？答案是A系統實現一個消息中間件的回調介面，消息中間件會去不斷執行回調介面，檢查A事務執行是否執行成功，如果失敗則回滾預備消息步驟四齣錯，這時候A的本地事務是成功的，那麼消息中間件要回滾A嗎？答案是不需要，其實通過回調介面，消息中間件能夠檢查到A執行成功了，這時候其實不需要A發提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務基於消息中間件的兩階段提交往往用在高並發場景下，將一個分布式事務拆成一個消息事務（A系統的本地操作+發消息）+B系統的本地操作，其中B系統的操作由消息驅動，只要消息事務成功，那麼A操作一定成功，消息也一定發出來了，這時候B會收到消息去執行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現了A與B的分布式事務。原理如下：
雖然上面的方案能夠完成A和B的操作，但是A和B並不是嚴格一致的，而是最終一致的，我們在這里犧牲了一致性，換來了性能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。
5.3、TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式並不能很好地被復用。
6、總結
分布式事務，本質上是對多個資料庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是並發量和性能很好，缺點是數據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力
I. 什麼是存儲器的四級存儲結構
CPU一級、二級、三級緩存+外部RAM存儲器總共是四級存儲。
CPU緩存到硬碟，一級比一級快，如果沒CPU緩存、內存，直接讓CPU讀取硬碟的話，CPU會一直等硬碟慢慢地把數據傳過來給它處理，這樣慢死了。所以先把硬碟上准備處理的數據傳到內存等待，最急著處理的就由內存傳到CPU緩存里，CPU可以以最高的速度讀取要處理的數據。
(9)分布式存儲屬於高並發嗎擴展閱讀
目前，快閃記憶體陣列已經逐漸普及，新埠的固態硬碟、NVMe網路架構，使存儲系統的性能有了大幅提升。未來，隨著新技術帶來的存儲效率大幅提升，將有越來越多的企業選擇快閃記憶體陣列來滿足數據實時性應用需求。
高效、易於擴展的分布式平台引領存儲架構新趨勢。分布式存儲系統採用可擴展的架構，不僅能提高存儲的效率和數據的安全性，還可以進行性能和容量的橫向擴展，解決大規模、高並發場景下的存儲訪問問題。
J. 什麼是分布式數據存儲
什麼是分布式存儲
分布式存儲是一種數據存儲技術，它通過網路使用企業中每台機器上的磁碟空間，這些分散的存儲資源構成了虛擬存儲設備，數據分布存儲在企業的各個角落。
分布式存儲系統，可在多個獨立設備上分發數據。傳統的網路存儲系統使用集中存儲伺服器來存儲所有數據。存儲伺服器成為系統性能的瓶頸，也是可靠性和安全性的焦點，無法滿足大規模存儲應用的需求。分布式網路存儲系統採用可擴展的系統結構，使用多個存儲伺服器共享存儲負載，利用位置伺服器定位存儲信息，不僅提高了系統的可靠性，可用性和訪問效率，而且易於擴展。