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

學(xué)習(xí)一個(gè)知識(shí)之前，我覺(jué)得比較好的方式是先理解它的來(lái)龍去脈：即這個(gè)知識(shí)產(chǎn)生的過(guò)程，它解決了什么問(wèn)題，它是怎么樣解決的，還有它引入了哪些新的問(wèn)題（沒(méi)有銀彈），這樣我們才能比較好的抓到它的脈絡(luò)和關(guān)鍵點(diǎn)，不會(huì)一開(kāi)始就迷失在細(xì)節(jié)中。

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

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

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

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

第三個(gè)是業(yè)務(wù)高可用的要求，對(duì)于互聯(lián)網(wǎng)的產(chǎn)品來(lái)說(shuō)，都要求 7 * 24 小時(shí)提供服務(wù)，無(wú)法容忍停止服務(wù)等故障，而要提供高可用的服務(wù)，唯一的方式就是增加冗余來(lái)完成，這樣就算單機(jī)系統(tǒng)可以支撐的服務(wù)，因?yàn)楦呖捎玫囊螅矔?huì)變成一個(gè)分布式系統(tǒng)。

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

分布式系統(tǒng)是怎么來(lái)解決問(wèn)題的？

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

其實(shí)思路很簡(jiǎn)單，就是將一些廉價(jià)的 PC 機(jī)通過(guò)網(wǎng)絡(luò)連接起來(lái)，共同完成工作，并且在系統(tǒng)中提供冗余來(lái)解決高可用的問(wèn)題。

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

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

我們經(jīng)常說(shuō)掌握一個(gè)知識(shí)需要理解它的前因后果，對(duì)于分布式系統(tǒng)來(lái)說(shuō)，前因是「分布式系統(tǒng)解決了什么問(wèn)題」，后果是「它是怎么做內(nèi)部工作節(jié)點(diǎn)的協(xié)調(diào)」，所以我們要解決的第二個(gè)問(wèn)題是：分布式系統(tǒng)是怎么做內(nèi)部工作節(jié)點(diǎn)協(xié)調(diào)的？

分布式計(jì)算引入了哪些新的問(wèn)題？

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

1.怎么樣找到服務(wù)？

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

2.怎么樣找到實(shí)例？

找到服務(wù)后，當(dāng)前的請(qǐng)求應(yīng)該選擇發(fā)往服務(wù)的哪一個(gè)實(shí)例呢？一般來(lái)說(shuō)，如果同一個(gè)服務(wù)的實(shí)例都是完全對(duì)等的（無(wú)狀態(tài)），那么按負(fù)載均衡策略來(lái)處理就足夠（輪詢、權(quán)重、hash、一致性 hash，fair 等各種策略的適用場(chǎng)景）；如果同一個(gè)服務(wù)的實(shí)例不是對(duì)等的（有狀態(tài)），那么需要通過(guò)路由服務(wù)（元數(shù)據(jù)服務(wù)等）先確定當(dāng)前要訪問(wèn)的請(qǐng)求數(shù)據(jù)做哪一個(gè)實(shí)例上，然后再進(jìn)行訪問(wèn)。

3.怎么樣避免雪崩？

系統(tǒng)雪崩是指故障的由于正反饋循序?qū)е虏粩鄶U(kuò)大規(guī)則的故障。一次雪崩通常是由于整個(gè)系統(tǒng)中一個(gè)很小的部分出現(xiàn)故障于引發(fā)，進(jìn)而導(dǎo)致系統(tǒng)其它部分也出現(xiàn)故障。比如系統(tǒng)中某一個(gè)服務(wù)的一個(gè)實(shí)例出現(xiàn)故障，導(dǎo)致負(fù)載均衡將該實(shí)例摘除而引起其它實(shí)例負(fù)載升高，最終導(dǎo)致該服務(wù)的所有實(shí)例像多米諾骨牌一樣一個(gè)一個(gè)全部出現(xiàn)故障。

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

一般來(lái)說(shuō)，快速失敗會(huì)導(dǎo)致部分的請(qǐng)求失敗，如果分布式系統(tǒng)內(nèi)部對(duì)一致性要求很高的話，快速失敗會(huì)帶來(lái)系統(tǒng)數(shù)據(jù)不一致的問(wèn)題，彈性擴(kuò)容會(huì)是一個(gè)比較好的選擇，但是彈性擴(kuò)容的實(shí)現(xiàn)成本和響應(yīng)時(shí)間比快速失敗要大得多。

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

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

分布式存儲(chǔ)引入了哪些新的問(wèn)題？

接下來(lái)我們?cè)賮?lái)看分布式存儲(chǔ)（有狀態(tài)）的內(nèi)部的協(xié)調(diào)是怎么做的，同時(shí)，前面介紹的分布式計(jì)算的協(xié)調(diào)方式在分布式存儲(chǔ)中同樣適用，就不再重復(fù)了：

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

ACID、BASE 和 CAP 理論，了解這三個(gè)主題，推薦這一篇文章以及文章后面相關(guān)的參考文獻(xiàn)：

英文版本：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.怎么樣做數(shù)據(jù)分片？

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

3.怎么樣做數(shù)據(jù)復(fù)制？

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

4.怎么樣做分布式事務(wù)？

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

有了事務(wù) ID 后，通過(guò) 2PC 或者 3PC 協(xié)議來(lái)實(shí)現(xiàn)分布式事務(wù)的原子性，其他部分和單機(jī)事務(wù)差別不大，就不再細(xì)說(shuō)來(lái)。

進(jìn)階學(xué)習(xí)階段

到這里，對(duì)分布式系統(tǒng)脈絡(luò)上有了基本的概念，接下來(lái)開(kāi)始進(jìn)入細(xì)節(jié)學(xué)習(xí)階段，這也是非常幸苦的階段，對(duì)于分布式系統(tǒng)的理解深入與否，對(duì)細(xì)節(jié)的深入度是很重要的評(píng)價(jià)指標(biāo)，畢竟魔鬼在細(xì)節(jié)。這里可以往兩個(gè)方面進(jìn)行系統(tǒng)的學(xué)習(xí)：

1.從實(shí)踐出發(fā)

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

2.從理論出發(fā)

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

總結(jié)

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

參考

知乎 | 如何系統(tǒng)性的學(xué)習(xí)分布式系統(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本文來(lái)自微信公眾號(hào)： 鮮棗課堂（ID：xzclasscom），作者：小棗君，題圖來(lái)自：視覺(jué)中國(guó)大家好，我是小棗君。今天我們來(lái)聊聊基帶和射頻。說(shuō)起基帶和射頻，相信大家都不陌生。它們是通信行業(yè)里的兩個(gè)常見(jiàn)概念，經(jīng)常出現(xiàn)在我們面前。不過(guò)，越是常見(jiàn)的概念，網(wǎng)上的資料就越混亂，錯(cuò)誤也就越多。這些錯(cuò)誤給很多初...  閱讀全文

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

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

Cat.1 芯片原廠：

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

• 紫光展銳春藤 8910DM（28nm工藝，集成藍(lán)牙和WiFi 室內(nèi)定位）

• 翱捷 ASR3601

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

• 中移物聯(lián)網(wǎng)

• 移遠(yuǎn)通信

• 合宙電子

• 移柯通信

• 域格信息

• 廣和通

• 芯訊通

• 高新興物聯(lián)

• 美格智能

• 有方科技

• 有人信息

• 信位通訊

• 銳騏(廈門)電子

• 深圳信可通訊

Cat.1 優(yōu)勢(shì)

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

• 相對(duì) eMTC，其網(wǎng)絡(luò)成本低

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

Cat.1 劣勢(shì)：

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

  國(guó)外以高通為主，輔以 Sequans、Altair。

  國(guó)內(nèi)主要是展銳和翱捷。

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

  NB-IoT、Cat.1、Cat.4 模組價(jià)格：

  
  

cat1 的主要市場(chǎng)和應(yīng)用場(chǎng)景：

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

總結(jié)

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

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

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

背景

QoS 等級(jí) 與 通信的流程有關(guān)，直接影響了整個(gè)通信。而且篇幅比較長(zhǎng)，所以我覺(jué)得應(yīng)該單獨(dú)拎出來(lái)講一下。

概念

QoS 代表了 服務(wù)質(zhì)量等級(jí)。 設(shè)置上，由2 位 的二進(jìn)制控制，且值不允許為 3(0x11)。

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

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

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

QoS 0 的通信時(shí)序圖

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

QoS1 的通信時(shí)序圖

此時(shí)，Sender 發(fā)送的一條消息，Receiver 至少能收到一次，也就是說(shuō) Sender 向 Receiver 發(fā)送消息，如果發(fā)送失敗，會(huì)繼續(xù)重試，直到 Receiver 收到消息為止，但是因?yàn)橹貍鞯脑颍?code style="-webkit-tap-highlight-color: transparent; box-sizing: border-box; font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace !important; font-size: 12px !important; line-height: 1.8; margin: 0px 4px !important; vertical-align: middle; display: inline; overflow-x: auto; background-color: rgba(27, 31, 35, 0.05) !important; border: none !important; padding: 0.2em 0.4em !important; border-radius: 3px !important;">Receiver 有可能會(huì)收到重復(fù)的消息；

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

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

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

4）如果 Sender 在一段時(shí)間內(nèi)沒(méi)有收到 PUBLISH 包對(duì)應(yīng)的 PUBACK，它將該 PUBLISH 包的 DUP 標(biāo)識(shí)設(shè)為 1（代表是重新發(fā)送的 PUBLISH 包），然后重新發(fā)送該 PUBLISH 包。重復(fù)這個(gè)流程，直到收到 PUBACK，然后執(zhí)行第 3 步。

QoS 2 的通信時(shí)序圖

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

Sender 發(fā)送的一條消息，Receiver 確保能收到而且只收到一次，也就是說(shuō) Sender 盡力向 Receiver 發(fā)送消息，如果發(fā)送失敗，會(huì)繼續(xù)重試，直到 Receiver 收到消息為止，同時(shí)保證 Receiver 不會(huì)因?yàn)橄⒅貍鞫盏街貜?fù)的消息。

QoS 使用 2 套請(qǐng)求/應(yīng)答流程（一個(gè) 4 段的握手）來(lái)確保 Receiver 收到來(lái)自 Sender 的消息，且不重復(fù)：

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

2）Receiver 收到 PUBLISH 數(shù)據(jù)包以后，在本地保存 PUBLISH 包的 Packet Identifier P，并回復(fù) Sender 一個(gè) PUBREC 數(shù)據(jù)包，PUBREC 數(shù)據(jù)包可變頭中的 Packet Identifier 為 P，沒(méi)有消息體（Payload）；

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

4）當(dāng) Receiver 收到 PUBREL 數(shù)據(jù)包，它可以丟棄掉保存的 PUBLISH 包的 Packet Identifier P，并回復(fù) Sender 一個(gè) PUBCOMP 數(shù)據(jù)包，PUBCOMP 數(shù)據(jù)包可變頭中的 Packet Identifier 為 P，沒(méi)有消息體（Payload）；

5）當(dāng) Sender 收到 PUBCOMP 包，那么它認(rèn)為數(shù)據(jù)包傳輸已完成，它會(huì)丟棄掉對(duì)應(yīng)的 PUBREC 包。如果 Sender 在一定時(shí)間內(nèi)沒(méi)有收到 PUBCOMP 包，它會(huì)重新發(fā)送 PUBREL 數(shù)據(jù)包。

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

QoS 和會(huì)話（Session）

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

• 已經(jīng)發(fā)送給服務(wù)端，但是還沒(méi)有完成確認(rèn)的QoS 1和QoS 2級(jí)別的消息
• 已從服務(wù)端接收，但是還沒(méi)有完成確認(rèn)的QoS 2級(jí)別的消息。

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

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

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

如果 Client 想接收離線消息，必須使用持久化的會(huì)話（CONNECT報(bào)文中可變頭（byte8[1]）Clean Session = 0）連接到 Broker，這樣 Broker 才會(huì)存儲(chǔ) Client 在離線期間沒(méi)有確認(rèn)接收的 QoS 大于 1 的消息。

QoS 等級(jí)的選擇

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

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

在以下情況下你應(yīng)該選擇 QoS1：

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

在以下情況下你應(yīng)該選擇 QoS2：

• 你的應(yīng)用必須接收到所有的消息，而且你的應(yīng)用在重復(fù)的消息下無(wú)法正常工作，同時(shí)你也能接受 QoS2 帶來(lái)的額外開(kāi)銷。

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

from:http://zhulongchao.com/blog/performance-trace.html

1.網(wǎng)速測(cè)試

安裝iperf

yum install epel-release 從epel源中安裝 yum install -y  iperf 

帶寬檢測(cè)

iperf -s 開(kāi)啟服務(wù)端  iperf -c ip 

丟包問(wèn)題

tcpdump進(jìn)行抓包  tcpdump -i eth0 -s 3000 port 8080 -w /home/tomcat.pcap  對(duì)于抓包文件采用wireshark進(jìn)行分析  丟包(TCP DUP ACK) 重傳(retransmission)，超時(shí)重傳， 

2.cdn性能測(cè)試

cdn 緩存，回源問(wèn)題    304請(qǐng)求，瀏覽器是否使用本地緩存。比較last_modified 和if_modified_since  通過(guò)實(shí)踐戳來(lái)判斷，瀏覽器緩存和cdn緩存 

3.DNS基礎(chǔ)

路由解析

泛域名解析

4.分布式服務(wù)鏈路追蹤

http入口產(chǎn)生一個(gè)traceId  分發(fā)到rpc調(diào)用，cache，db，jms調(diào)用鏈路中  google的著名論文dapper和zipkin  日志聚合，綁定鏈路日志和業(yè)務(wù)日志  采樣采集，慢請(qǐng)求，異常服務(wù)。  日志量大。日志異步寫入，環(huán)狀數(shù)組，日志組件自研  共享信息放在ThreadLocal中。比如traceId 

5.網(wǎng)卡性能問(wèn)題定位

tsar -l  -i 1 --traffic 查看網(wǎng)卡的進(jìn)出流量 

6.CPU性能問(wèn)題定位

tsar -l  -i 1 --cpu  軟件問(wèn)題定位，perf 采樣所有進(jìn)程數(shù)據(jù)  perf record -F 99 -a -g -- sleep 30  java進(jìn)程的函數(shù)map：java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar net.virtualvoid.perf.AttachOnce PID  輸出函數(shù)和地址的map  輸出火焰圖 perf script | stackcollapse-perf.pl | flamegraph.pl --color=java --hash > flamegraph.svg 

7.內(nèi)存性能問(wèn)題定位

-堆內(nèi)內(nèi)存問(wèn)題，

采用jmap dump內(nèi)存，采用離線工具分析  jprofile、mat 

-堆外內(nèi)存問(wèn)題

a.google-perftools

yum install -y google-perftools graphviz  export LD_PRELOAD=/usr/lib64/libtcmalloc.so.4  export HEAPPROFILE=/home/testGperf.prof  執(zhí)行程序，結(jié)束程序，生成prof  分析prof  生成svg, pdf,text pprof --svg $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.svg  pprof --pdf $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.pdf  pprof --text $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.txt 

b.jemalloc定位（優(yōu)勢(shì)，適合長(zhǎng)時(shí)間trace）

sudo apt-get install graphviz 編譯安裝 ./configure –enable-prof –enable-stats –enable-debug –enable-fill make make install

運(yùn)行配置 export MALLOC_CONF=”prof:true,prof_gdump:true,prof_prefix:/home/jedump/jez,lg_prof_interval:30,lg_prof_sample:17”

export LD_PRELOAD=/usr/local/lib/libjemalloc.so.2 運(yùn)行 java -jar target/spring-boot-jemalloc-example-0.0.1-SNAPSHOT.jar

jeprof –show_bytes –svg jez.*.heap > app-profiling.svg

注明：如果在docker容器中，推薦用pprof，jemalloc只顯示函數(shù)地址，不顯示函數(shù)名

8.機(jī)器資源配額問(wèn)題

/etc/security/limits.conf

• soft nofile 65536
• hard nofile 65536

控制該用戶文件句柄數(shù)

9.磁盤性能問(wèn)題定位

tsar -l -i 1 –io