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

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

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

分布式系統解決了什么問題？

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

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

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

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

分布式系統是怎么來解決問題的？

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

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

分布式系統引入了哪些新的問題？

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

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

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

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

1.怎么樣找到服務？

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

2.怎么樣找到實例？

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

3.怎么樣避免雪崩？

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

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

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

4.怎么樣監控告警？

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

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

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

1.分布式系統的理論與衡權

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.怎么樣做數據分片？

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

3.怎么樣做數據復制？

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

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

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

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

進階學習階段

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

1.從實踐出發

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

2.從理論出發

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

總結

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

參考

知乎 | 如何系統性的學習分布式系統

Martin Kleppmann.Designing Data-Intensive Applications

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

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

Cat.1 芯片原廠：

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

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

• 翱捷 ASR3601

Cat.1 模組廠商（不完全統計）：

• 中移物聯網

• 移遠通信

• 合宙電子

• 移柯通信

• 域格信息

• 廣和通

• 芯訊通

• 高新興物聯

• 美格智能

• 有方科技

• 有人信息

• 信位通訊

• 銳騏(廈門)電子

• 深圳信可通訊

Cat.1 優勢

• 相對 NB-IOT，其通信速率優勢明顯

• 相對 eMTC，其網絡成本低

• 相對 Cat.4，其具有一定的成本優勢

Cat.1 劣勢：

• 現階段芯片廠家少

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

  國內主要是展銳和翱捷。

• 現階段價格偏高

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

  
  

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

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

總結

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

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

背景

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

概念

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

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

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

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

QoS 0 的通信時序圖

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

QoS1 的通信時序圖

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

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

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

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

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

QoS 2 的通信時序圖

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

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

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

1）Sender 發送 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，重新發送該 PUBLISH 數據包（Payload）；

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

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

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

QoS 和會話（Session）

客戶端的會話狀態包括：

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

服務端的會話狀態包括：

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

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

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

QoS 等級的選擇

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

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

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

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

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

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

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

摘要： MySQL replace into 錯誤案例 背景 * MySQL5.7 * ROW模式 * 表結構 CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `col_1` varc

* MySQL5.7  * ROW模式   * 表結構 CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   `col_3` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 

mater:lc> REPLACE INTO test (col_1,col_2,col_3) values('a','a','a'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄  master:lc> REPLACE INTO test (col_1,col_2,col_3) values('b','b','b'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄  master:lc> REPLACE INTO test (col_1,col_2,col_3) values('c','c','c'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄   master > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   `col_3` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |   mater > select * from test; +----+-------+-------+-------+ | id | col_1 | col_2 | col_3 | +----+-------+-------+-------+ |  1 | a     | a     | a     | |  2 | b     | b     | b     | |  3 | c     | c     | c     | +----+-------+-------+-------+ 3 rows in set (0.00 sec)  

master:lc> replace into test(col_1,col_2) values('c','cc'); Query OK, 2 rows affected (0.00 sec)  dba:lc> select * from test; +----+-------+-------+-------+ | id | col_1 | col_2 | col_3 | +----+-------+-------+-------+ |  1 | a     | a     | a     | |  2 | b     | b     | b     | |  4 | c     | cc    | NULL  | +----+-------+-------+-------+ 3 rows in set (0.00 sec)  

 mater:lc> REPLACE INTO test (col_1,col_2) values('a','a'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄  master:lc> REPLACE INTO test (col_1,col_2) values('b','b'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄  master:lc> REPLACE INTO test (col_1,col_2) values('c','c'); Query OK, 1 row affected (0.00 sec) --注意，這里是影響了1條記錄   master > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |   slave > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |

* master  mater:lc> REPLACE INTO test (col_1,col_2) values('c','cc'); Query OK, 2 rows affected (0.00 sec)  --注意，這里是影響了兩條記錄  mater:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 |  master:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec)  * slave  slave:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |  slave:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec) 

* 假設有一天，master 掛了， 由slave 提升為 new mater  原slave:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |  原slave:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec)   ===注意==  root:lc> REPLACE INTO test (col_1,col_2) values('d','d'); ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'  

* Row 模式，主從情況下，replace into 和 INSERT INTO … ON DUPLICATE KEY UPDATE 都會導致以上問題的發生 * 解決方案： 最后可以通過alter table auto_increment值解決，但是這樣已經造成mater的表很長時間沒有寫入了。。。

1. 禁止 replace into (錯誤一，錯誤二 都會發生) 2. 禁止 INSERT INTO … ON DUPLICATE KEY UPDATE （錯誤二 會發生）

1. 禁止 replace into (會發生錯誤場景一的案例，丟失部分字段數據) 2. 可以使用INSERT INTO … ON DUPLICATE KEY UPDATE 代替 replace into