from：https://www.infoq.cn/article/orvjbfycnrito5qiyfhf
前言

學習一個知識之前，我覺得比較好的方式是先理解它的來龍去脈：即這個知識產生的過程，它解決了什么問題，它是怎么樣解決的，還有它引入了哪些新的問題（沒有銀彈），這樣我們才能比較好的抓到它的脈絡和關鍵點，不會一開始就迷失在細節(jié)中。

所以，在學習分布式系統(tǒng)之前，我們需要解決的第一個問題是：分布式系統(tǒng)解決了什么問題？

分布式系統(tǒng)解決了什么問題？

第一個是單機性能瓶頸導致的成本問題，由于摩爾定律失效，廉價 PC 機性能的瓶頸無法繼續(xù)突破，小型機和大型機能提高更高的單機性能，但是成本太大高，一般的公司很難承受；

第二個是用戶量和數據量爆炸性的增大導致的成本問題，進入互聯(lián)網時代，用戶量爆炸性的增大，用戶產生的數據量也在爆炸性的增大，但是單個用戶或者單條數據的價值其實比軟件時代（比如銀行用戶）的價值是只低不高，所以必須尋找更經濟的方案；

第三個是業(yè)務高可用的要求，對于互聯(lián)網的產品來說，都要求 7 * 24 小時提供服務，無法容忍停止服務等故障，而要提供高可用的服務，唯一的方式就是增加冗余來完成，這樣就算單機系統(tǒng)可以支撐的服務，因為高可用的要求，也會變成一個分布式系統(tǒng)。

基于上面的三個原因可以看出，在互聯(lián)網時代，單機系統(tǒng)是無法解決成本和高可用問題的，但是這兩個問題對幾乎對所有的公司來說都是非常關鍵的問題，所以，從單機系統(tǒng)到分布式系統(tǒng)是無法避免的技術大潮流。

分布式系統(tǒng)是怎么來解決問題的？

那么，分布式系統(tǒng)是怎么來解決單機系統(tǒng)面臨的成本和高可用問題呢？

其實思路很簡單，就是將一些廉價的 PC 機通過網絡連接起來，共同完成工作，并且在系統(tǒng)中提供冗余來解決高可用的問題。

分布式系統(tǒng)引入了哪些新的問題？

我們來看分布式系統(tǒng)的定義：分布式系統(tǒng)是由一組通過網絡進行通信、為了完成共同的任務而協(xié)調工作的計算機節(jié)點組成的系統(tǒng)。在定義中，我們可用看出，分布式系統(tǒng)它通過多工作節(jié)點來解決單機系統(tǒng)面臨的成本和可用性問題，但是它引入了對分布式系統(tǒng)內部工作節(jié)點的協(xié)調問題。

我們經常說掌握一個知識需要理解它的前因后果，對于分布式系統(tǒng)來說，前因是「分布式系統(tǒng)解決了什么問題」，后果是「它是怎么做內部工作節(jié)點的協(xié)調」，所以我們要解決的第二個問題是：分布式系統(tǒng)是怎么做內部工作節(jié)點協(xié)調的？

分布式計算引入了哪些新的問題？

先從簡單的情況入手，對于分布式計算（無狀態(tài)）的情況，系統(tǒng)內部的協(xié)調需要做哪些工作：

1.怎么樣找到服務？

在分布式系統(tǒng)內部，會有不同的服務（角色），服務 A 怎么找到服務 B 是需要解決的問題，一般來說服務注冊與發(fā)現(xiàn)機制是常用的思路，所以可以了解一下服務注冊發(fā)現(xiàn)機制實現(xiàn)原理，并且可以思考服務注冊發(fā)現(xiàn)是選擇做成 AP 還是 CP 系統(tǒng)更合理（嚴格按 CAP 理論說，我們目前使用的大部分系統(tǒng)很難滿足 C 或者 A 的，所以這里只是通常意義上的 AP 或者 CP）；

2.怎么樣找到實例？

找到服務后，當前的請求應該選擇發(fā)往服務的哪一個實例呢？一般來說，如果同一個服務的實例都是完全對等的（無狀態(tài)），那么按負載均衡策略來處理就足夠（輪詢、權重、hash、一致性 hash，fair 等各種策略的適用場景）；如果同一個服務的實例不是對等的（有狀態(tài)），那么需要通過路由服務（元數據服務等）先確定當前要訪問的請求數據做哪一個實例上，然后再進行訪問。

3.怎么樣避免雪崩？

系統(tǒng)雪崩是指故障的由于正反饋循序導致不斷擴大規(guī)則的故障。一次雪崩通常是由于整個系統(tǒng)中一個很小的部分出現(xiàn)故障于引發(fā)，進而導致系統(tǒng)其它部分也出現(xiàn)故障。比如系統(tǒng)中某一個服務的一個實例出現(xiàn)故障，導致負載均衡將該實例摘除而引起其它實例負載升高，最終導致該服務的所有實例像多米諾骨牌一樣一個一個全部出現(xiàn)故障。

避免雪崩總體的策略比較簡單，只要是兩個思路，一個是快速失敗和降級機制（熔斷、降級、限流等），通過快速減少系統(tǒng)負載來避免雪崩的發(fā)生；另一個為彈性擴容機制，通過快速增加系統(tǒng)的服務能力來避免雪崩的發(fā)生。這個根據不同的場景可以做不同的選擇，或者兩個策略都使用。

一般來說，快速失敗會導致部分的請求失敗，如果分布式系統(tǒng)內部對一致性要求很高的話，快速失敗會帶來系統(tǒng)數據不一致的問題，彈性擴容會是一個比較好的選擇，但是彈性擴容的實現(xiàn)成本和響應時間比快速失敗要大得多。

4.怎么樣監(jiān)控告警？

對于一個分布式系統(tǒng)，如果我們不能很清楚地了解內部的狀態(tài)，那么高可用是沒有辦法完全保障的，所以對分布式系統(tǒng)的監(jiān)控（比如接口的時延和可用性等信息），分布式追蹤 Trace，模擬故障的混沌工程，以及相關的告警等機制是一定要完善的；

分布式存儲引入了哪些新的問題？

接下來我們再來看分布式存儲（有狀態(tài)）的內部的協(xié)調是怎么做的，同時，前面介紹的分布式計算的協(xié)調方式在分布式存儲中同樣適用，就不再重復了：

1.分布式系統(tǒng)的理論與衡權

ACID、BASE 和 CAP 理論，了解這三個主題，推薦這一篇文章以及文章后面相關的參考文獻：

英文版本：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

中文版本：https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed/

2.怎么樣做數據分片？

單機的存儲能力是不可能存儲所有的數據的，所以需要解決怎么將數據按一定的規(guī)則分別存儲到不同的機器上，目前使用比較多的方案為：Hash、Consistent Hash 和 Range Based 分片策略，可以了解一下它們的優(yōu)缺點和各自的應用場景；

3.怎么樣做數據復制？

為什么滿足系統(tǒng)的高可用要求，需要對數據做冗余處理，目前的方案主要為：中心化方案（主從復制、一致性協(xié)議比如 Raft 和 Paxos 等）和 去中心化的方案（Quorum 和 Vector Clock）了解一下它們的優(yōu)缺點和各自的應用場景，以及對系統(tǒng)外部表現(xiàn)出來的數據一致性級別（線性一致性、順序一致性、最終一致性等）；

4.怎么樣做分布式事務？

對于分布式系統(tǒng)來說，要實現(xiàn)事務，首先需要有對并發(fā)事務進行排序的能力，這樣在事務沖突的時候，確認哪個事務提供成功，哪個事務提交失敗。對于單機系統(tǒng)來說這個完全不是問題，簡單通過時間戳加序號的方式就可以實現(xiàn)，但是對于分布式系統(tǒng)來說，系統(tǒng)中機器的時間不能完全同步，并且單臺機器序號也沒用全局意義，按上面的方式說行不通的。不過整個系統(tǒng)選一臺機器按單機的模式生產事務 ID 是可以的，同城多中心和短距離的異地多中心都沒有問題，不過想做成全球分布式系統(tǒng)的話，那么每一次事務都要去一個節(jié)點去獲取事務 ID 的成本太高（比如中國杭州到美國東部的 RTT 為 200 + ms ），Google 的 Spanner 是通過 GPS 和原子鐘實現(xiàn) TrueTime API 來解決這個問題從而實現(xiàn)全球分布式數據庫的。

有了事務 ID 后，通過 2PC 或者 3PC 協(xié)議來實現(xiàn)分布式事務的原子性，其他部分和單機事務差別不大，就不再細說來。

進階學習階段

到這里，對分布式系統(tǒng)脈絡上有了基本的概念，接下來開始進入細節(jié)學習階段，這也是非常幸苦的階段，對于分布式系統(tǒng)的理解深入與否，對細節(jié)的深入度是很重要的評價指標，畢竟魔鬼在細節(jié)。這里可以往兩個方面進行系統(tǒng)的學習：

1.從實踐出發(fā)

研究目前比較常用的分布式系統(tǒng)的設計，HDFS 或者 GFS（分布式文件系統(tǒng)）、Kafka 和 Pulsar（分布式消息隊列），Redis Cluster 和 Codis（分布式緩存），MySQL 的分庫分表（傳統(tǒng)關系型數據庫的分布式方案），MongoDB 的 Replica Set 和 Sharing 機制集以及去中心化的 Cassandra（NoSQL 數據庫），中心化的 TiDB 和去中心化的 CockroachDB（NewSQL），以及一些微服務框架等；

2.從理論出發(fā)

從理論出發(fā)，研究分布式相關的論文，這里推薦一本書「Designing Data-Intensive Applications」（中文版本：數據密集型應用系統(tǒng)設計），先整體看書，對比較感興趣的章節(jié)，再讀一讀該章節(jié)中涉及到的相關參考文獻。

總結

本文從分布式系統(tǒng)解決的問題開始，再討論它是怎么樣來解決問題的，最后討論了它引入了哪些新的問題，并且討論這些新問題的解決辦法，這個就是分布式系統(tǒng)大概的知識脈絡。掌握這個知識脈絡后，那么就可以從實踐和理論兩個角度結合起來深入細節(jié)研究分布式系統(tǒng)了。

參考

知乎 | 如何系統(tǒng)性的學習分布式系統(tǒng)

Martin Kleppmann.Designing Data-Intensive Applications

CAP Twelve Years Later: How the “Rules” Have Changed

     摘要: from:https://www.huxiu.com/article/351920.html本文來自微信公眾號： 鮮棗課堂（ID：xzclasscom），作者：小棗君，題圖來自：視覺中國大家好，我是小棗君。今天我們來聊聊基帶和射頻。說起基帶和射頻，相信大家都不陌生。它們是通信行業(yè)里的兩個常見概念，經常出現(xiàn)在我們面前。不過，越是常見的概念，網上的資料就越混亂，錯誤也就越多。這些錯誤給很多初...  閱讀全文

from：https://mp.weixin.qq.com/s/s-AuC_IDS5GEamRwX286MQ

隨著紫光展銳、ASR 等芯片廠商發(fā)布性價比更高的 Cat.1 芯片之后，Cat.1 模組廠商扎堆發(fā)布了自家的模組，
使得市場上的 Cat.1 模組價格已經迅速降至 45-60 元，玩家眾多，競爭慘烈，基本重走 NB-IOT 的老路 —— 量未起，價已跌。

Cat.1 芯片原廠：

• 高通 MDM9207-1(2016 年發(fā)布)

• 紫光展銳春藤 8910DM（28nm工藝，集成藍牙和WiFi 室內定位）

• 翱捷 ASR3601

Cat.1 模組廠商（不完全統(tǒng)計）：

• 中移物聯(lián)網

• 移遠通信

• 合宙電子

• 移柯通信

• 域格信息

• 廣和通

• 芯訊通

• 高新興物聯(lián)

• 美格智能

• 有方科技

• 有人信息

• 信位通訊

• 銳騏(廈門)電子

• 深圳信可通訊

Cat.1 優(yōu)勢

• 相對 NB-IOT，其通信速率優(yōu)勢明顯

• 相對 eMTC，其網絡成本低

• 相對 Cat.4，其具有一定的成本優(yōu)勢

Cat.1 劣勢：

• 現(xiàn)階段芯片廠家少

  國外以高通為主，輔以 Sequans、Altair。

  國內主要是展銳和翱捷。

• 現(xiàn)階段價格偏高

  NB-IoT、Cat.1、Cat.4 模組價格：

  
  

cat1 的主要市場和應用場景：

Cat.1 仍處于商用初期，落地的應用場景和案例還較少，一些明確的場景包括了共享、金融支付、工業(yè)控制、車載支付、公網對講、POS 等等。

總結

工信部辦公廳發(fā)布了《關于深入推進移動物聯(lián)網全面發(fā)展的通知》（以下簡稱《通知》）同時為 NB-IOT 和 Cat.1 站臺，未來 NB-IOT 依舊很香，Cat.1 則前途大好。

隨著新基建的啟動，5G 打頭，未來將是 NB-IOT、4G（包括 Cat.1）、5G 共同承載蜂窩物聯(lián)網的連接，以應對不同層次的物聯(lián)網業(yè)務需求。

from：https://www.cnblogs.com/schips/p/12262587.html

背景

QoS 等級 與 通信的流程有關，直接影響了整個通信。而且篇幅比較長，所以我覺得應該單獨拎出來講一下。

概念

QoS 代表了 服務質量等級。 設置上，由2 位 的二進制控制，且值不允許為 3(0x11)。

要注意的是，QoS 是 Sender 和 Receiver 之間達成的協(xié)議，不是 Publisher 和 Subscriber 之間達成的協(xié)議。

也就是說 Publisher 發(fā)布一條 QoS1 的消息，只能保證 Broker 能至少收到一次這個消息；至于對應的 Subscriber 能否至少收到一次這個消息，還要取決于 Subscriber 在 Subscribe 的時候和 Broker 協(xié)商的 QoS 等級。

這里又牽扯出一個概念："QoS 降級"：在 MQTT 協(xié)議中，從 Broker 到 Subscriber 這段消息傳遞的實際 QoS 等于 "Publisher 發(fā)布消息時指定的 QoS 等級和 Subscriber 在訂閱時與 Broker 協(xié)商的 QoS 等級，這兩個 QoS 等級中的最小那一個。"

QoS 0 的通信時序圖

此時，整個過程中的 Sender 不關心 Receiver 是否收到消息，它"盡力"發(fā)完消息，至于是否有人收到，它不在乎。

QoS1 的通信時序圖

此時，Sender 發(fā)送的一條消息，Receiver 至少能收到一次，也就是說 Sender 向 Receiver 發(fā)送消息，如果發(fā)送失敗，會繼續(xù)重試，直到 Receiver 收到消息為止，但是因為重傳的原因，Receiver 有可能會收到重復的消息；

1）Sender 向 Receiver 發(fā)送一個帶有消息數據的 PUBLISH 包， 并在本地保存這個 PUBLISH 包。

2）Receiver 收到 PUBLISH 包以后，向 Sender 發(fā)送一個 PUBACK 數據包，PUBACK 數據包沒有消息體（Payload），在可變頭中（Variable header）中有一個包標識（Packet Identifier），和它收到的 PUBLISH 包中的 Packet Identifier 一致。

3）Sender 收到 PUBACK 之后，根據 PUBACK 包中的 Packet Identifier 找到本地保存的 PUBLISH 包，然后丟棄掉，一次消息的發(fā)送完成。

4）如果 Sender 在一段時間內沒有收到 PUBLISH 包對應的 PUBACK，它將該 PUBLISH 包的 DUP 標識設為 1（代表是重新發(fā)送的 PUBLISH 包），然后重新發(fā)送該 PUBLISH 包。重復這個流程，直到收到 PUBACK，然后執(zhí)行第 3 步。

QoS 2 的通信時序圖

QoS2 不僅要確保 Receiver 能收到 Sender 發(fā)送的消息，還要保證消息不重復。它的重傳和應答機制就要復雜一些，同時開銷也是最大的。

Sender 發(fā)送的一條消息，Receiver 確保能收到而且只收到一次，也就是說 Sender 盡力向 Receiver 發(fā)送消息，如果發(fā)送失敗，會繼續(xù)重試，直到 Receiver 收到消息為止，同時保證 Receiver 不會因為消息重傳而收到重復的消息。

QoS 使用 2 套請求/應答流程（一個 4 段的握手）來確保 Receiver 收到來自 Sender 的消息，且不重復：

1）Sender 發(fā)送 QoS 為 2 的 PUBLISH 數據包，數據包 Packet Identifier 為 P，并在本地保存該 PUBLISH 包；

2）Receiver 收到 PUBLISH 數據包以后，在本地保存 PUBLISH 包的 Packet Identifier P，并回復 Sender 一個 PUBREC 數據包，PUBREC 數據包可變頭中的 Packet Identifier 為 P，沒有消息體（Payload）；

3）當 Sender 收到 PUBREC，它就可以安全地丟棄掉初始的 Packet Identifier 為 P 的 PUBLISH 數據包，同時保存該 PUBREC 數據包，同時回復 Receiver 一個 PUBREL 數據包，PUBREL 數據包可變頭中的 Packet Identifier 為 P，沒有消息體；如果 Sender 在一定時間內沒有收到 PUBREC，它會把 PUBLISH 包的 DUP 標識設為 1，重新發(fā)送該 PUBLISH 數據包（Payload）；

4）當 Receiver 收到 PUBREL 數據包，它可以丟棄掉保存的 PUBLISH 包的 Packet Identifier P，并回復 Sender 一個 PUBCOMP 數據包，PUBCOMP 數據包可變頭中的 Packet Identifier 為 P，沒有消息體（Payload）；

5）當 Sender 收到 PUBCOMP 包，那么它認為數據包傳輸已完成，它會丟棄掉對應的 PUBREC 包。如果 Sender 在一定時間內沒有收到 PUBCOMP 包，它會重新發(fā)送 PUBREL 數據包。

我們可以看到在 QoS2 中，完成一次消息的傳遞，Sender 和 Reciever 之間至少要發(fā)送四個數據包，QoS2 是最安全也是最慢的一種 QoS 等級了。

QoS 和會話（Session）

客戶端的會話狀態(tài)包括：

• 已經發(fā)送給服務端，但是還沒有完成確認的QoS 1和QoS 2級別的消息
• 已從服務端接收，但是還沒有完成確認的QoS 2級別的消息。

服務端的會話狀態(tài)包括：

• 會話是否存在，即使會話狀態(tài)的其它部分都是空。
• 客戶端的訂閱信息。
• 已經發(fā)送給客戶端，但是還沒有完成確認的QoS 1和QoS 2級別的消息。
• 即將傳輸給客戶端的QoS 1和QoS 2級別的消息。
• 已從客戶端接收，但是還沒有完成確認的QoS 2級別的消息。
• 可選，準備發(fā)送給客戶端的QoS 0級別的消息。

保留消息不是服務端會話狀態(tài)的一部分，會話終止時不能刪除保留消息。

如果 Client 想接收離線消息，必須使用持久化的會話（CONNECT報文中可變頭（byte8[1]）Clean Session = 0）連接到 Broker，這樣 Broker 才會存儲 Client 在離線期間沒有確認接收的 QoS 大于 1 的消息。

QoS 等級的選擇

在以下情況下你可以選擇 QoS0：

• Client 和 Broker 之間的網絡連接非常穩(wěn)定，例如一個通過有線網絡連接到 Broker 的測試用 Client；
• 可以接受丟失部分消息，比如你有一個傳感器以非常短的間隔發(fā)布狀態(tài)數據，所以丟一些也可以接受；
• 你不需要離線消息。

在以下情況下你應該選擇 QoS1：

• 你需要接收所有的消息，而且你的應用可以接受并處理重復的消息；
• 你無法接受 QoS2 帶來的額外開銷，QoS1 發(fā)送消息的速度比 QoS2 快很多。

在以下情況下你應該選擇 QoS2：

• 你的應用必須接收到所有的消息，而且你的應用在重復的消息下無法正常工作，同時你也能接受 QoS2 帶來的額外開銷。

實際上，QoS1 是應用最廣泛的 QoS 等級，QoS1 發(fā)送消息的速度很快，而且能夠保證消息的可靠性。雖然使用 QoS1 可能會收到重復的消息，但是在應用程序里面處理重復消息，通常并不是件難事。