CTO偷偷傳我的系統效能最佳化十大絕招（萬字乾貨）

　　 上篇

　　引言：取與舍

　　軟體設計開發某種意義上是“取”與“舍”的藝術。

　　關於效能方面，就像建築設計成抗震9度需要額外的成本一樣，高效能軟體系統也意味著更高的實現成本，有時候與其他質量屬性甚至會衝突，比如安全性、可擴充套件性、可觀測性等等。

　　大部分時候我們需要的是：在業務遇到瓶頸之前，利用常見的技術手段將系統最佳化到預期水平。

　　那麼，效能最佳化有哪些技術方向和手段呢？

　　效能最佳化通常是“時間”與“空間”的互換與取捨。

　　本篇分兩個部分，在上篇，講解六種通用的“時間”與“空間”互換取捨的手段：

　　索引術

　　壓縮術

　　快取術

　　預取術

　　削峰填谷術

　　批次處理術

　　在下篇，介紹四種進階性的內容，大多與提升並行能力有關：

　　八門遁甲 —— 榨乾計算資源

　　影分身術 —— 水平擴容

　　奧義 —— 分片術

　　秘術 —— 無鎖術

　　1、索引術

　　索引的原理是拿額外的儲存空間換取查詢時間，增加了寫入資料的開銷，但使讀取資料的時間複雜度一般從O(n)降低到O(logn)甚至O(1)。

　　索引不僅在資料庫中廣泛使用，前後端的開發中也在不知不覺運用。

　　在資料集比較大時，不用索引就像從一本沒有目錄而且內容亂序的新華字典查一個字，得一頁一頁全翻一遍才能找到；

　　用索引之後，就像用拼音先在目錄中先找到要查到字在哪一頁，直接翻過去就行了。

　　書籍的目錄是典型的樹狀結構，那麼軟體世界常見的索引有哪些資料結構，分別在什麼場景使用呢？

　　雜湊表（Hash Table）：雜湊表的原理可以類比銀行辦業務取號，給每個人一個號（計算出的Hash值），叫某個號直接對應了某個人，索引效率是最高的O(1)，消耗的儲存空間也相對更大。K-V儲存元件以及各種程式語言提供的Map/Dict等資料結構，多數底層實現是用的雜湊表。

　　二叉搜尋樹（Binary Search Tree）：有序儲存的二叉樹結構，在程式語言中廣泛使用的紅黑樹屬於二叉搜尋樹，確切的說是“不完全平衡的”二叉搜尋樹。從C++、Java的TreeSet、TreeMap，到Linux的CPU排程，都能看到紅黑樹的影子。Java的HashMap在發現某個Hash槽的連結串列長度大於8時也會將連結串列升級為紅黑樹，而相比於紅黑樹“更加平衡”的AVL樹反而實際用的更少。

　　平衡多路搜尋樹（B-Tree）：這裡的B指的是Balance而不是Binary，二叉樹在大量資料場景會導致查詢深度很深，解決辦法就是變成多叉樹，MongoDB的索引用的就是B-Tree。

　　葉節點相連的平衡多路搜尋樹（B+ Tree）：B+ Tree是B-Tree的變體，只有葉子節點存資料，葉子與相鄰葉子相連，MySQL的索引用的就是B+樹，Linux的一些檔案系統也使用的B+樹索引inode。其實B+樹還有一種在枝椏上再加連結串列的變體：B*樹，暫時沒想到實際應用。

　　日誌結構合併樹（LSM Tree）：Log Structured Merge Tree，簡單理解就是像日誌一樣順序寫下去，多層多塊的結構，上層寫滿壓縮合併到下層。LSM Tree其實本身是為了最佳化寫效能犧牲讀效能的資料結構，並不能算是索引，但在大資料儲存和一些NoSQL資料庫中用的很廣泛，因此這裡也列進去了。

　　字典樹（Trie Tree）：又叫字首樹，從樹根串到樹葉就是資料本身，因此樹根到枝椏就是字首，枝椏下面的所有資料都是匹配該字首的。這種結構能非常方便的做字首查詢或詞頻統計，典型的應用有：自動補全、URL路由。其變體基數樹（Radix Tree）在Nginx的Geo模組處理子網掩碼字首用了；Redis的Stream、Cluster等功能的實現也用到了基數樹（Redis中叫Rax）。

　　跳錶（Skip List）：是一種多層結構的有序連結串列，插入一個值時有一定機率“晉升”到上層形成間接的索引。跳錶更適合大量併發寫的場景，不存在紅黑樹的再平衡問題，Redis強大的ZSet底層資料結構就是雜湊加跳錶。

　　倒排索引（Inverted index）：這樣翻譯不太直觀，可以叫“關鍵詞索引”，比如書籍末頁列出的術語表就是倒排索引，標識出了每個術語出現在哪些頁，這樣我們要查某個術語在哪用的，從術語表一查，翻到所在的頁數即可。倒排索引在全文索引儲存中經常用到，比如ElasticSearch非常核心的機制就是倒排索引；Prometheus的時序資料庫按標籤查詢也是在用倒排索引。

　　資料庫主鍵之爭：自增長 vs UUID。主鍵是很多資料庫非常重要的索引，尤其是MySQL這樣的RDBMS會經常面臨這個難題：是用自增長的ID還是隨機的UUID做主鍵？

　　自增長ID的效能最高，但不好做分庫分表後的全域性唯一ID，自增長的規律可能洩露業務資訊；而UUID不具有可讀性且太佔儲存空間。

　　爭執的結果就是找一個兼具二者的優點的折衷方案：

　　用雪花演算法生成分散式環境全域性唯一的ID作為業務表主鍵，效能尚可、不那麼佔儲存、又能保證全域性單調遞增，但引入了額外的複雜性，再次體現了取捨之道。

　　再回到資料庫中的索引，建索引要注意哪些點呢？

　　定義好主鍵並儘量使用主鍵，多數資料庫中，主鍵是效率最高的聚簇索引；

　　在Where或Group By、Order By、Join On條件中用到的欄位也要按需建索引或聯合索引，MySQL中搭配explain命令可以查詢DML是否利用了索引；

　　類似列舉值這樣重複度太高的欄位不適合建索引（如果有點陣圖索引可以建），頻繁更新的列不太適合建索引；

　　單列索引可以根據實際查詢的欄位升級為聯合索引，透過部分冗餘達到索引覆蓋，以避免回表的開銷；

　　儘量減少索引冗餘，比如建A、B、C三個欄位的聯合索引，Where條件查詢A、A and B、A and B and C

　　都可以利用該聯合索引，就無需再給A單獨建索引了；根據資料庫特有的索引特性選擇適合的方案，比如像MongoDB，還可以建自動刪除資料的TTL索引、不索引空值的稀疏索引、地理位置資訊的Geo索引等等。

　　資料庫之外，在程式碼中也能應用索引的思維，比如對於集合中大量資料的查詢，使用Set、Map、Tree這樣的資料結構，其實也是在用雜湊索引或樹狀索引，比直接遍歷列表或陣列查詢的效能高很多。

　　2、快取術

　　快取最佳化效能的原理和索引一樣，是拿額外的儲存空間換取查詢時間。快取無處不在，設想一下我們在瀏覽器開啟這篇文章，會有多少層快取呢？

　　首先解析DNS時，瀏覽器一層DNS快取、作業系統一層DNS快取、DNS伺服器鏈上層層快取；

　　傳送一個GET請求這篇文章，服務端很可能早已將其快取在KV儲存元件中了；

　　即使沒有擊中快取，資料庫伺服器記憶體中也快取了最近查詢的資料；

　　即使沒有擊中資料庫伺服器的快取，資料庫從索引檔案中讀取，作業系統已經把熱點檔案的內容放置在Page Cache中了；

　　即使沒有擊中作業系統的檔案快取，直接讀取檔案，大部分固態硬碟或者磁碟本身也自帶快取；

　　資料取到之後伺服器用模板引擎渲染出HTML，模板引擎早已解析好快取在服務端記憶體中了；

　　歷經數十毫秒之後，終於伺服器返回了一個渲染後的HTML，瀏覽器端解析DOM樹，傳送請求來載入靜態資源；

　　需要載入的靜態資源可能因Cache-Control在瀏覽器本地磁碟和記憶體中已經快取了；

　　即使本地快取到期，也可能因Etag沒變伺服器告訴瀏覽器304 Not Modified繼續快取；

　　即使Etag變了，靜態資源伺服器也因其他使用者訪問過早已將檔案快取在記憶體中了；

　　載入的JS檔案會丟到JS引擎執行，其中可能涉及的種種快取就不再展開了；

　　整個過程中鏈條上涉及的所有的計算機和網路裝置，執行的熱點程式碼和資料很可能會載入CPU的多級快取記憶體。

　　這裡列舉的僅僅是一部分常見的快取，就有多種多樣的形式：從廉價的磁碟到昂貴的CPU快取記憶體，最終目的都是用來換取寶貴的時間。

　　既然快取那麼好，那麼問題就來了：快取是“銀彈”嗎？

　　不，Phil Karlton 曾說過：

　　There are only two hard things in Computer Science: cache invalidation and naming things.

　　電腦科學中只有兩件困難的事情：快取失效和命名規範。

　　快取的使用除了帶來額外的複雜度以外，還面臨如何處理快取失效的問題。

　　多執行緒併發程式設計需要用各種手段（比如Java中的synchronized volatile）防止併發更新資料，一部分原因就是防止執行緒本地快取的不一致；

　　快取失效衍生的問題還有：快取穿透、快取擊穿、快取雪崩。解決用不存在的Key來穿透攻擊，需要用空值快取或布隆過濾器；解決單個快取過期後，瞬間被大量惡意查詢擊穿的問題需要做查詢互斥；解決某個時間點大量快取同時過期的雪崩問題需要新增隨機TTL；

　　熱點資料如果是多級快取，在發生修改時需要清除或修改各級快取，這些操作往往不是原子操作，又會涉及各種不一致問題。

　　除了通常意義上的快取外，物件重用的池化技術，也可以看作是一種快取的變體。

　　常見的諸如JVM，V8這類執行時的常量池、資料庫連線池、HTTP連線池、執行緒池、Golang的sync.Pool物件池等等。

　　在需要某個資源時從現有的池子裡直接拿一個，稍作修改或直接用於另外的用途，池化重用也是效能最佳化常見手段。

　　3、壓縮術

　　說完了兩個“空間換時間”的，我們再看一個“時間換空間”的辦法——壓縮。

　　壓縮的原理消耗計算的時間，換一種更緊湊的編碼方式來表示資料。

　　為什麼要拿時間換空間？時間不是最寶貴的資源嗎？

　　舉一個影片網站的例子，如果不對影片做任何壓縮編碼，因為頻寬有限，巨大的資料量在網路傳輸的耗時會比編碼壓縮的耗時多得多。

　　對資料的壓縮雖然消耗了時間來換取更小的空間儲存，但更小的儲存空間會在另一個維度帶來更大的時間收益。

　　這個例子本質上是“作業系統核心與網路裝置處理負擔 vs 壓縮解壓的CPU/GPU負擔”的權衡和取捨。

　　我們在程式碼中通常用的是無失真壓縮，比如下面這些場景：

　　HTTP協議中Accept-Encoding新增Gzip/deflate，服務端對接受壓縮的文字（JS/CSS/HTML）請求做壓縮，大部分圖片格式本身已經是壓縮的無需壓縮；

　　HTTP2協議的頭部HPACK壓縮；

　　JS/CSS檔案的混淆和壓縮（Uglify/Minify）；

　　一些RPC協議和訊息佇列傳輸的訊息中，採用二進位制編碼和壓縮（Gzip、Snappy、LZ4等等）；

　　快取服務存過大的資料，通常也會事先壓縮一下再存，取的時候解壓；

　　一些大檔案的儲存，或者不常用的歷史資料儲存，採用更高壓縮比的演算法儲存；

　　JVM的物件指標壓縮，JVM在32G以下的堆記憶體情況下預設開啟“UseCompressedOops”，用4個byte就可以表示一個物件的指標，這也是JVM儘量不要把堆記憶體設定到32G以上的原因；

　　MongoDB的二進位制儲存的BSON相對於純文字的JSON也是一種壓縮，或者說更緊湊的編碼。但更緊湊的編碼也意味著更差的可讀性，這一點也是需要取捨的。純文字的JSON比二進位制編碼要更佔儲存空間但卻是REST API的主流，因為資料交換的場景下的可讀性是非常重要的。

　　資訊理論告訴我們，無失真壓縮的極限是資訊熵。進一步減小體積只能以損失部分資訊為代價，也就是有失真壓縮。　　

　　那麼，有失真壓縮有哪些應用呢？

　　預覽和縮圖，低速網路下影片降幀、降清晰度，都是對資訊的有失真壓縮；

　　音影片等多媒體資料的取樣和編碼大多是有損的，比如MP3是利用傅立葉變換，有損地儲存音訊檔案；jpeg等圖片編碼也是有損的。雖然有像WAV/PCM這類無損的音訊編碼方式，但多媒體資料的取樣本身就是有損的，相當於只擷取了真實世界的極小一部分資料；

　　雜湊化，比如K-V儲存時Key過長，先對Key執行一次“傻”系列（SHA-1、SHA-256）雜湊演算法變成固定長度的短Key。另外，雜湊化在檔案和資料驗證（MD5、CRC、HMAC）場景用的也非常多，無需耗費大量算力對比完整的資料。

　　除了有損/無失真壓縮，但還有一個辦法，就是壓縮的極端——從根本上減少資料或徹底刪除。

　　能減少的就減少：

　　JS打包過程“搖樹”，去掉沒有使用的檔案、函式、變數；

　　開啟HTTP/2和高版本的TLS，減少了Round Trip，節省了TCP連線，自帶大量效能最佳化；

　　減少不必要的資訊，比如Cookie的數量，去掉不必要的HTTP請求頭；

　　更新採用增量更新，比如HTTP的PATCH，只傳輸變化的屬性而不是整條資料；

　　縮短單行日誌的長度、縮短URL、在具有可讀性情況下用短的屬性名等等；

　　使用點陣圖和位操作，用風騷的位操作最小化存取的資料。典型的例子有：用Redis的點陣圖來記錄統計海量使用者登入狀態；布隆過濾器用點陣圖排除不可能存在的資料；大量開關型的設定的儲存等等。

　　能刪除的就刪除：

　　刪掉不用的資料；

　　刪掉不用的索引；

　　刪掉不該打的日誌；

　　刪掉不必要的通訊程式碼，不去發不必要的HTTP、RPC請求或呼叫，輪詢改釋出訂閱；

　　終極方案：砍掉整個功能。

　　畢竟有位叫做 Kelsey Hightower 的大佬曾經說過：

　　No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere

　　不寫程式碼，是編寫安全可靠的應用程式的更優方式。什麼都不寫；哪裡都不部署。

　　4、預取術

　　預取通常搭配快取一起用，其原理是在快取空間換時間基礎上更進一步，再加上一次“時間換時間”，也就是：用事先預取的耗時，換取第一次載入的時間。

　　當可以猜測出以後的某個時間很有可能會用到某種資料時，把資料預先取到需要用的地方，能大幅度提升使用者體驗或服務端響應速度。

　　是否用預取模式就像自助餐餐廳與廚師現做的區別，在自助餐餐廳可以直接拿做好的菜品，一般餐廳需要坐下來等菜品現做。

　　那麼，預取在哪些實際場景會用呢？

　　影片或直播類網站，在播放前先緩衝一小段時間，就是預取資料。有的在播放時不僅預取這一條資料，甚至還會預測下一個要看的其他內容，提前把資料取到本地；

　　HTTP/2 Server Push，在瀏覽器請求某個資源時，伺服器順帶把其他相關的資源一起推回去，HTML/JS/CSS幾乎同時到達瀏覽器端，相當於瀏覽器被動預取了資源；

　　一些客戶端軟體會用常駐程式的形式，提前預取資料或執行一些程式碼，這樣可以大大提高第一次使用的開啟速度；

　　服務端同樣也會用一些預熱機制，一方面熱點資料預取到記憶體提前形成多級快取；另一方面也是對執行環境的預熱，載入CPU快取記憶體、熱點函式JIT編譯成機器碼等等；

　　熱點資源提前預分配到各個例項，比如：秒殺、售票的庫存性質的資料；分散式唯一ID等等

　　天上不會掉餡餅，預取也是有副作用的。

　　正如烤箱預熱需要消耗時間和額外的電費，在軟體程式碼中做預取/預熱的副作用通常是啟動慢一些、佔用一些閒時的計算資源、可能取到的不一定是後面需要的。

　　5、削峰填谷術

　　削峰填谷的原理也是“時間換時間”，谷時換峰時。

　　削峰填谷與預取是反過來的：預取是事先花時間做，削峰填谷是事後花時間做。就像三峽大壩可以抗住短期巨量洪水，事後雨停再慢慢開閘防水。軟體世界的“削峰填谷”是類似的，只是不是用三峽大壩實現，而是用訊息佇列、非同步化等方式。

　　常見的有這幾類問題，我們分別來看每種對應的解決方案：

　　針對前端、客戶端的啟動最佳化或首屏最佳化：程式碼和資料等資源的延時載入、分批載入、後臺非同步載入、或按需懶載入等等。

　　背壓控制 - 限流、節流、去抖等等。一夫當關，萬夫莫開，從入口處削峰，防止一些惡意重複請求以及請求過於頻繁的爬蟲，甚至是一些DDoS攻擊。簡單做法有閘道器層根據單個IP或使用者用漏桶控制請求速率和上限；前端做按鈕的節流去抖防止重複點選；網路層開啟TCP SYN Cookie防止惡意的SYN洪水攻擊等等。徹底杜絕爬蟲、駭客手段的惡意洪水攻擊是很難的，DDoS這類屬於網路安全範疇了。

　　針對正常的業務請求洪峰，用訊息佇列暫存再非同步化處理：常見的後端訊息佇列Kafka、RocketMQ甚至Redis等等都可以做緩衝層，第一層業務處理直接校驗後丟到訊息佇列中，在洪峰過去後慢慢消費訊息佇列中的訊息，執行具體的業務。另外執行過程中的耗時和耗計算資源的操作，也可以丟到訊息佇列或資料庫中，等到谷時處理。

　　捋平毛刺：有時候洪峰不一定來自外界，如果系統內部大量定時任務在同一時間執行，或與業務高峰期重合，很容易在監控中看到“毛刺”——短時間負載極高。一般解決方案就是錯峰執行定時任務，或者分配到其他非核心業務系統中，把“毛刺”攤平。比如很多資料分析型任務都放在業務低谷期去執行，大量定時任務在建立時儘量加一些隨機性來分散執行時間。

　　避免錯誤風暴帶來的次生洪峰：有時候網路抖動或短暫當機，業務會出現各種異常或錯誤。這時處理不好很容易帶來次生災害，比如：很多程式碼都會做錯誤重試，不加控制的大量重試甚至會導致網路抖動恢復後的瞬間，積壓的大量請求再次沖垮整個系統；還有一些程式碼沒有做超時、降級等處理，可能導致大量的等待耗盡TCP連線，進而導致整個系統被沖垮。解決之道就是做限定次數、間隔指數級增長的Back-Off重試，設定超時、降級策略。

　　6、批次處理術

　　批次處理同樣可以看成“時間換時間”，其原理是減少了重複的事情，是一種對執行流程的壓縮。以個別批次操作更長的耗時為代價，在整體上換取了更多的時間。

　　批次處理的應用也非常廣泛，我們還是從前端開始講：

　　打包合併的JS檔案、雪碧圖等等，將一批資源集中到一起，一次性傳輸；

　　前端動畫使用requestAnimationFrame在UI渲染時批次處理積壓的變化，而不是有變化立刻更新，在遊戲開發中也有類似的應用；

　　前後端中使用佇列暫存臨時產生的資料，積壓到一定數量再批次處理；在不影響可擴充套件性情況下，一個介面傳輸多種需要的資料，減少大量ajax呼叫（GraphQL在這一點就做到了極致）；

　　系統間通訊儘量傳送整批資料，比如訊息佇列的釋出訂閱、存取快取服務的資料、RPC呼叫、插入或更新資料庫等等，能批次做盡可能批次做，因為這些系統間通訊的I/O時間開銷已經很昂貴了；

　　資料積壓到一定程度再落盤，作業系統本身的寫檔案就是這麼做的，Linux的fwrite只是寫入緩衝區暫存，積壓到一定程度再fsync刷盤。在應用層，很多高效能的資料庫和K-V儲存的實現都體現了這一點：一些NoSQL的LSM Tree的第一層就是在記憶體中先積壓到一定大小再往下層合併；Redis的RDB結合AOF的落盤機制；Linux系統呼叫也提供了批次讀寫多個緩衝區檔案的系統呼叫：readv/writev；

　　延遲地批次回收資源，比如JVM的Survivor Space的S0和S1區互換、Redis的Key過期的清除策略。

　　批次處理如此好用，那麼問題來了，每一批放多大最合適呢？

　　這個問題其實沒有定論，有一些個人經驗可以分享。

　　前端把所有檔案打包成單個JS，大部分時候並不是優解。Webpack提供了很多分塊的機制，CSS和JS分開、JS按業務分更小的Chunk結合懶載入、一些體積大又不用在首屏用的第三方庫設定external或單獨分塊，可能整體效能更高。不一定要一批搞定所有事情，分幾個小批次反而使用者體驗的效能更好。

　　Redis的MGET、MSET來批次存取資料時，每批大小不宜過大，因為Redis主執行緒只有一個，如果一批太大執行期間會讓其他命令無法響應。經驗上一批50-100個Key效能是不錯的，但最好在真實環境下用真實大小的資料量化度量一下，做Benchmark測試才能確定一批大小的最優值。

　　MySQL、Oracle這類RDBMS，最優的批次Insert的大小也視資料行的特性而定。我之前在2U8G的Oracle上用一些普遍的業務資料做過測試，批次插入時每批5000-10000條資料效能是最高的，每批過大會導致DML的解析耗時過長，甚至單個SQL語句體積超限，單批太多反而得不償失。

　　訊息佇列的釋出訂閱，每批的訊息長度儘量控制在1MB以內，有些雲服務商提供的訊息佇列限制了最大長度，那這個長度可能就是效能拐點，比如AWS的SQS服務對單條訊息的限制是256KB。

　　總之，多大一批可以確保單批響應時間不太長的同時讓整體效能最高，是需要在實際情況下做基準測試的，不能一概而論。而批次處理的副作用在於：處理邏輯會更加複雜，尤其是一些涉及事務、併發的問題；需要用陣列或佇列用來存放緩衝一批資料，消耗了額外的儲存空間。

　　 中篇

　　引言

　　前面我們總結了六種普適的效能最佳化方法，包括索引、壓縮、快取、預取、削峰填谷、批次處理，簡單講解了每種技術手段的原理和實際應用。

　　在開啟最後一篇前，我們先需要搞清楚：

　　在程式執行期間，時間和空間都耗在哪裡了？

　　時間都去哪兒了？

　　人眨一次眼大約100毫秒，而現代1核CPU在一眨眼的功夫就可以執行數億條指令。

　　現代的CPU已經非常厲害了，頻率已經達到了GHz級別，也就是每秒數十億個指令週期。

　　即使一些CPU指令需要多個時鐘週期，但由於有流水線機制的存在，平均下來大約每個時鐘週期能執行1條指令，比如一個3GHz頻率的CPU核心，每秒大概可以執行20億到40億左右的指令數量。

　　程式執行還需要RAM，也可能用到持久化儲存，網路等等。隨著新的技術和工藝的出現，這些硬體也越來越厲害，比如CPU快取記憶體的提升、NVMe固態硬碟相對SATA盤讀寫速率和延遲的飛躍等等。這些硬體具體有多強呢？

　　有一個非常棒的網站“Latency Numbers Every Programmer Should Know”，可以直觀地檢視從1990年到現在，快取記憶體、記憶體、硬碟、網路時間開銷的具體數值。

　　

　　下圖是2020年的截圖，的確是“每個開發者應該知道的數字”。　　

　　

　　這裡有幾個非常關鍵的資料：

　　存取一次CPU多級快取記憶體的時間大約1-10納秒級別；

　　存取一次主存(RAM)的時間大概在100納秒級別；

　　固態硬碟的一次隨機讀寫大約在10微秒到1毫秒這個數量級；

　　網路包在區域網傳輸一個來回大約是0.5毫秒。

　　看到不同硬體之間數量級的差距，就很容易理解效能最佳化的一些技術手段了。

　　比如一次網路傳輸的時間，是主存訪問的5000倍，明白這點就不難理解寫for迴圈發HTTP請求，為什麼會被扣工資了。

　　放大到我們容易感知的時間範圍，來理解5000倍的差距：如果一次主存訪問是1天的話，一趟區域網資料傳輸就要13.7年。

　　如果要傳輸更多網路資料，每兩個網路幀之間還有固定的間隔（Interpacket Gap），在間隔期間傳輸Idle訊號，資料鏈路層以此來區分兩個資料包，具體數值在連結Wiki中有，這裡擷取幾個我們熟悉的網路來感受一下：

　　百兆乙太網: 0.96 µs

　　千兆乙太網：96 ns

　　萬兆乙太網：9.6 ns

　　不過，單純看硬體的上限意義不大，從程式碼到機器指令中間有許多層抽象，僅僅是在TCP連線上發一個位元組的資料包，從作業系統核心到網線，涉及到的基礎設施級別的軟硬體不計其數。到了應用層，單次操作耗時雖然沒有非常精確的數字，但經驗上的範圍也值得參考：

　　用Memcached/Redis存取快取資料：1-5 ms

　　執行一條簡單的資料庫查詢或更新操作：5-50ms

　　在區域網中的TCP連線上收發一趟資料包：1-10ms；廣域網中大約10-200ms，視傳輸距離和網路節點的裝置而定

　　從使用者態切換到核心態，完成一次系統呼叫：100ns - 1 μs，視不同的系統呼叫函式和硬體水平而定，少數系統呼叫可能遠超此範圍。

　　空間都去哪兒了？

　　在計算機歷史上，非易失儲存技術的發展速度超過了摩爾定律。除了嵌入式裝置、資料庫系統等等，現在大部分場景已經不太需要最佳化持久化儲存的空間佔用了，這裡主要講的是另一個相對稀缺的儲存形式 —— RAM，或者說主存/記憶體。

　　以JVM為例，在堆裡面有很多我們建立的物件（Object）。

　　每個Object都有一個包含Mark和型別指標的Header，佔12個位元組

　　每個成員變數，根據資料型別的不同佔不同的位元組數，如果是另一個物件，其物件指標佔4個位元組

　　陣列會根據宣告的大小，佔用N倍於其型別Size的位元組數

　　成員變數之間需要對齊到4位元組，每個物件之間需要對齊到8位元組

　　如果在32G以上記憶體的機器上，禁用了物件指標壓縮，物件指標會變成8位元組，包括Header中的Klass指標，這也就不難理解為什麼堆記憶體超過32G，JVM的效能直線下降了。

　　舉個例子，一個有8個int型別成員的物件，需要佔用48個位元組（12+32+4），如果有十萬個這樣的Object，就需要佔用4.58MB的記憶體了。這個數字似乎看起來不大，而實際上一個Java服務的堆記憶體裡面，各種各樣的物件佔用的記憶體通常比這個數字多得多，大部分記憶體耗在char[]這類陣列或集合型資料型別上。

　　舉個例子，一個有8個int型別成員的物件，需要佔用48個位元組（12+32+4），如果有十萬個這樣的Object，就需要佔用4.58MB的記憶體了。這個數字似乎看起來不大，而實際上一個Java服務的堆記憶體裡面，各種各樣的物件佔用的記憶體通常比這個數字多得多，大部分記憶體耗在char[]這類陣列或集合型資料型別上。

　　堆記憶體之外，又是另一個世界了。

　　從作業系統程式的角度去看，也有不少耗記憶體的大戶，不管什麼Runtime都逃不開這些空間開銷：每個執行緒需要分配MB級別的執行緒棧，執行的程式和資料會快取下來，用到的輸入輸出裝置需要緩衝區……

　　程式碼“寫出來”的記憶體佔用，僅僅是冰山之上的部分，真正的記憶體佔用比“寫出來”的要更多，到處都存在空間利用率的問題。

　　比如，即使我們在Java程式碼中只是寫了 response.getWriter().print(“OK”)，給瀏覽器返回2位元組，網路協議棧的層層封裝，協議頭部不斷增加的額外資料，讓最終返回給瀏覽器的位元組數遠超原始的2位元組，像IP協議的報頭部就至少有20個位元組，而資料鏈路層的一個乙太網幀頭部至少有18位元組。

　　如果傳輸的資料過大，各層協議還有最大傳輸單元MTU的限制，IPv4一個報文最大隻能有64K位元，超過此值需要分拆傳送並在接收端組合，更多額外的報頭導致空間利用率降低（IPv6則提供了Jumbogram機制，最大單包4G位元，“浪費”就減少了）。

　　這部分的“浪費”有多大呢？下面的連結有個表格，傳輸1460個位元組的載荷，經過有線到無線網路的轉換，至少再添120個位元組，**空間利用率<92.4%**。

　　

　　這種現象非常普遍，使用抽象層級越高的技術平臺，平臺提供高階能力的同時，其底層實現的“資訊密度”通常越低。

　　像Java的Object Header就是使用JVM的代價，而更進一步使用動態型別語言，要為靈活性付出空間的代價則更大。雜湊表的自動擴容，強大的反射能力等等，背後也付出了空間的代價。

　　再比如，二進位制資料交換協議通常比純文字協議更加節約空間。但多數廠家我們仍然用JSON、XML等純文字協議，用資訊的冗餘來換取可讀性。即便是二進位制的資料互動格式，也會存在資訊冗餘，只能透過更好的協議和壓縮演算法，儘量去逼近壓縮的極限 —— 資訊熵。

　　小結

　　理解了時間和空間的消耗在哪後，還不能完全解釋軟體為何傾向於耗盡硬體資源。有一條定律可以解釋，正是它錘爆了摩爾定律。

　　它就是安迪-比爾定律。

　　“安迪給什麼，比爾拿走什麼”。

　　安迪指的是Intel前CEO安迪·葛洛夫，比爾指的是比爾·蓋茨。

　　這句話的意思就是：軟體發展比硬體還快，總能吃得下硬體。

　　20年前，在最強的計算機也不見得可以玩賽車遊戲；

　　10年前，個人電腦已經可以玩畫質還可以的3D賽車遊戲了；

　　現在，自動駕駛+5G雲駕駛已經快成為現實。

　　在這背後，是無數的硬體技術飛躍，以及吃掉了這些硬體的各類軟體。　　

　　因此，即使現代的硬體水平已經強悍到如此境地，效能最佳化仍然是有必要的。

　　軟體日益複雜，抽象層級越來越高，就越需要底層基礎設施被充分最佳化。

　　對於大部分開發者而言，高層程式碼逐步走向低程式碼化、視覺化，“一行程式碼”能產生的影響也越來越大，寫出低效程式碼則會吃掉更多的硬體資源。

　　 下篇

　　引言

　　本篇也是本系列最硬核的一篇，本人技術水平有限，可能存在疏漏或錯誤之處，望斧正。仍然選取了《火影忍者》的配圖和命名方式幫助理解：

　　八門遁甲 —— 榨乾計算資源

　　影分身術 —— 水平擴容

　　奧義 —— 分片術

　　秘術 —— 無鎖術

　　（注：這些“中二”的字首僅是用《火影》中的一些術語，形象地描述技術方案）

　　7、八門遁甲 —— 榨乾計算資源

　　讓硬體資源都在處理真正有用的邏輯計算，而不是做無關的事情或空轉。

　　從電晶體到積體電路、驅動程式、作業系統、直到高階程式語言的層層抽象，每一層抽象帶來的更強的通用性、更高的開發效率，多是以損失執行效率為代價的。

　　但我們可以在用高階程式語言寫程式碼的時候，在保障可讀性、可維護性基礎上用執行效率更高、更適合執行時環境的方式去寫，減少額外的效能損耗《Effective XXX》、《More Effective XXX》、《高效能XXX》這類書籍所傳遞的知識和思想。

　　落到技術細節，下面用四個小節來說明如何減少“無用功”、避免空轉、榨乾硬體。

　　1）聚焦

　　減少系統呼叫與上下文切換，讓CPU聚焦。

　　可以看看兩個 stackoverflow 上的帖子：

　　

　　

　　大部分網際網路應用服務，耗時的部分不是計算，而是I/O。

　　減少I/O wait， 各司其職，專心幹I/O，專心幹計算，epoll批次撈任務，（refer: event driven）

　　利用DMA減少CPU負擔 - 零複製 NewI/O Redis SingleThread (even 6.0), Node.js

　　避免不必要的排程 - Context Switch

　　CPU親和性，讓CPU更加聚焦

　　2）蛻變

　　用更高效的資料結構、演算法、第三方元件，讓程式本身蛻變。

　　從邏輯短路、Map代替List遍歷、減少鎖範圍、這樣的編碼技巧，到應用FisherYates、Dijkstra這些經典演算法，注意每一行程式碼細節，量變會發生質變。更何況某個演算法就足以讓系統效能產生一兩個數量級的提升。

　　3）適應

　　因地制宜，適應特定的執行環境

　　在瀏覽器中主要是最佳化方向是I/O、UI渲染引擎、JS執行引擎三個方面。

　　I/O越少越好，能用WebSocket的地方就不用Ajax，能用Ajax的地方就不要刷整個頁面；

　　UI渲染方面，減少重排和重繪，比如Vue、React等MVVM框架的虛擬DOM用額外的計算換取最精簡的DOM操作；

　　JS執行引擎方面，少用動態性極高的寫法，比如eval、隨意修改物件或物件原型的屬性。

　　前端的最佳化有個神器：Light House，在新版本Chrome已經嵌到開發者工具中了，可以一鍵生成效能最佳化報告，按照最佳化建議改就完了。

　　與瀏覽器環境頗為相似的Node.js環境：

　　

　　Java

　　C1 C2 JIT編譯器

　　棧上分配

　　Linux

　　各種引數最佳化

　　記憶體分配和GC策略

　　Linux核心引數 Brendan Gregg

　　記憶體區塊配置（DB，JVM，V8，etc.）

　　利用語言特性和執行時環境 - 比如寫出利於JIT的程式碼

　　多靜態少動態 - 捨棄動態特性的靈活性 - hardcode/if-else，強型別，弱型別語言避免型別轉換 AOT/JIT vs 直譯器， 彙編，機器碼 GraalVM

　　減少記憶體的分配和回收，少對列表做增加或刪除

　　對於RAM有限的嵌入式環境，有時候時間不是問題，反而要拿時間換空間，以節約RAM的使用。

　　4）運籌

　　把眼界放寬，跳出程式和執行環境本身，從整體上進行系統性分析最高價效比的最佳化方案，分析潛在的最佳化切入點，以及能夠調配的資源和技術，運籌帷幄。

　　其中最簡單易行的幾個辦法，就是花錢，買更好或更多的硬體基礎設施，這往往是開發人員容易忽視的，這裡提供一些妙招：

　　伺服器方面，雲服務廠商提供各種型別的例項，每種型別有不同的屬性側重，頻寬、CP、磁碟的I/O能力，選適合的而不是更貴的

　　捨棄虛擬機器 - Bare Mental，比如神龍伺服器

　　用ARM架構CPU的伺服器，同等價格可以買到更多的伺服器，對於多數可以跨平臺執行的服務端系統來說與x86區別並不大，ARM伺服器的資料中心也是技術發展趨勢使然

　　如果必須用x86系列的伺服器，AMD也Intel的價效比更高。

　　第一點非常重要，軟體效能遵循木桶原理，一定要找到瓶頸在哪個硬體資源，把錢花在刀刃上。

　　如果是服務端頻寬瓶頸導致的效能問題，升級再多核CPU也是沒有用的。

　　我有一次效能最佳化案例：把一個跑複雜業務的Node.js伺服器從AWS的m4型別換成c4型別，記憶體只有原來的一半，但CPU使用率反而下降了20%，同時價格還比之前更便宜，一石二鳥。

　　這是因為Node.js主執行緒的計算任務只有一個CPU核心在幹，透過CPU Profile的火焰圖，可以定位到該業務的瓶頸在主執行緒的計算任務上，因此提高單核頻率的作用是立竿見影的。而該業務對記憶體的消耗並不多，套用一些定製v8引擎記憶體引數的方案，起不了任何作用。

　　畢竟這樣的例子不多，大部分時候還是要多花錢買更高配的伺服器的，除了這條花錢能直接解決問題的辦法，剩下的辦法難度就大了：

　　利用更底層的特性實現功能，比如FFI WebAssembly呼叫其他語言，Java Agent Instrument，位元組碼生成（BeanCopier, Json Lib），甚至彙編等等

　　使用硬體提供的更高效的指令

　　各種提升TLB命中率的機制，減少記憶體的大頁表

　　魔改Runtime，Facebook的PHP，阿里騰訊定製的JDK

　　網路裝置引數，MTU

　　專用硬體：GPU加速（cuda）、AES硬體卡和高階指令加速加解密過程，比如TLS

　　可程式設計硬體：地獄級難度，FPGA硬體裝置加速特定業務

　　NUMA

　　更宏觀的排程，VM層面的共享vCPU，K8S叢集排程，總體上的最佳化

　　5）小結

　　有些手段，是憑空換出來更多的空間和時間了嗎？

　　天下沒有免費的午餐，即使那些看起來空手套白狼的最佳化技術，也需要額外的人力成本來做，副作用可能就是專家級的髮際線吧。還好很多複雜的效能最佳化技術我也不會，所以我本人髮際線還可以。

　　這一小節總結了一些方向，有些技術細節非常深，這裡也無力展開。不過，即使榨乾了單機效能，也可能不足以支撐業務，這時候就需要分散式叢集出場了，因此後面介紹的3個技術方向，都與並行化有關。

　　8、影分身術 —— 水平擴容

　　本節的水平擴容以及下面一節的分片，可以算整體的效能提升而不是單點的效能最佳化，會因為引入額外元件反而降低了處理單個請求的效能。

　　但當業務規模大到一定程度時，再好的單機硬體也無法承受流量的洪峰，就得水平擴容了，畢竟”眾人拾柴火焰高”。

　　在這背後的理論基礎是，矽基半導體已經接近物理極限，隨著摩爾定律的減弱，阿姆達爾定律的作用顯現出來：

　　%27s_law

　　水平擴容必然引入負載均衡

　　多副本

　　水平擴容的前提是無狀態

　　讀>>寫， 多個讀例項副本 （CDN）

　　自動擴縮容，根據常用的或自定義的metrics，判定擴縮容的條件，或根據CRON

　　負載均衡策略的選擇

　　9、奧義 —— 分片術

　　水平擴容針對無狀態元件，分片針對有狀態元件。二者原理都是提升並行度，但分片的難度更大。

　　負載均衡也不再是簡單的加權輪詢了，而是進化成了各個分片的協調器

　　Java1.7的及之前的 ConcurrentHashMap分段鎖

　　有狀態資料的分片

　　如何選擇Partition/Sharding Key

　　負載均衡難題

　　熱點資料，增強快取等級，解決分散的快取帶來的一致性難題

　　資料冷熱分離，SSD - HDD

　　分開容易合併難

　　區塊鏈的最佳化，分割槽域

　　10、秘術 —— 無鎖術

　　有些業務場景，比如庫存業務，按照正常的邏輯去實現，水平擴容帶來的提升非常有限，因為需要鎖住庫存，扣減，再解鎖庫存。

　　票務系統也類似，為了避免超賣，需要有一把鎖禁錮了橫向擴充套件的能力。

　　不管是單機還是分散式微服務，鎖都是制約並行度的一大因素。比如上篇提到的秒殺場景，庫存就那麼多，系統超賣了可能導致非常大的經濟損失，但用分散式鎖會導致即使服務擴容了成千上萬個例項，最終無數請求仍然阻塞在分散式鎖這個序列元件上了，再多水平擴充套件的例項也無用武之地。

　　避免競爭Race Condition 是最完美的解決辦法。

　　上篇說的應對秒殺場景，預取庫存就是減輕競態條件的例子，雖然取到伺服器記憶體之後仍然有多執行緒的鎖，但鎖的粒度更細了，併發度也就提高了。

　　執行緒同步鎖

　　分散式鎖

　　資料庫鎖 update select子句

　　事務鎖

　　順序與亂序

　　樂觀鎖/無鎖 CAS Java 1.8之後的ConcurrentHashMap

　　pipeline技術 - CPU流水線 Redis Pipeline 大資料分析 平行計算

　　TCP的緩衝區排頭阻塞 QUIC HTTP3.0

　　總結

　　以ROI的視角看軟體開發，初期人力成本的投入，後期的維護成本，計算資源的費用等等，選一個合適的方案而不是一個效能最高的方案。

　　本篇結合個人經驗總結了常見的效能最佳化手段，這些手段只是冰山一角。在初期就設計實現出一個完美的高效能系統是不可能的，隨著軟體的迭代和體量的增大，利用壓測，各種工具（profiling，vmstat，iostat，netstat），以及監控手段，逐步找到系統的瓶頸，因地制宜地選擇最佳化手段才是正道。

　　有利必有弊，得到一些必然會失去一些，有一些手段要慎用。Linux效能最佳化大師Brendan Gregg一再強調的就是：切忌過早最佳化、過度最佳化。

　　持續觀測，做80%高投入產出比的最佳化。

　　除了這些設計和實現時可能用到的手段，在技術選型時選擇高效能的框架和元件也非常重要。

　　另外，部署基礎設施的硬體效能也同樣，合適的伺服器和網路等基礎設施往往會事半功倍，比如雲服務廠商提供的各種字母開頭的instance，網路裝置頻寬的速度和穩定性，磁碟的I/O能力等等。

　　多數時候我們應當使用更高效能的方案，但有時候甚至要故意去違背它們。最後，以《Effective Java》第一章的一句話結束本文吧。

　　首先要學會基本的規則，然後才能知道什麼時候可以打破規則。