• 不要讓內核去做所有繁重的處理。把數(shù)據(jù)包處理，內存管理以及處理器調度從內核移到可以讓他更高效執(zhí)行的應用程序中去。讓Linux去處理控制層，數(shù)據(jù)層由應用程序來處理。

  
  

  
  

C10K的問題——過去十年

Apache的問題

• 內核中的兩個基本問題：

  
  

• 連接數(shù) = 線程數(shù)/進程數(shù)。當一個包（數(shù)據(jù)包）來臨時，它（內核）會遍歷所有的10,000個進程以決定由哪個進程處理這個包。

  
  

• 連接數(shù)= 選擇數(shù)/輪詢次數(shù)（單線程情況下）。同樣的擴展性問題。每個包不得不遍歷一遍列表中的socket。

  
  

• 解決方法：修正內核在規(guī)定的時間內進行查找

  
  

• 不管有多少線程，線程切換的時間都是恒定的。

  
  

• 使用一個新的可擴展的epoll()/IOCompletionPort在規(guī)定的時間內做socket查詢。

  
  

C10M問題 —— 下一個十年

我們學的是Unix而不是網(wǎng)絡編程（Network Programming）

• 一代代的程序員通過W. Richard Stevens所著的《Unix網(wǎng)絡編程》（Unix Networking Programming）學習網(wǎng)絡編程技術。問題是，這本書是關于Unix的，并不是網(wǎng)絡編程。它講述的是，你僅需要寫一個很小的輕量級的服務器就可以讓Unix做一切繁復的工作。然而內核并不是規(guī)模的（規(guī)模不足）。解決方案是，將這些繁復的工作轉移到內核之外，自已處理。

  
  

  
  

• 一個頗具影響的例子，就是在考慮到Apache的線程每個連接模型（is to consider Apache’s thread per connection model）。這就意味著線程調度器根據(jù)到來的數(shù)據(jù)（on which data arrives）決定調用哪一個（不同的）read()函數(shù)（方法）。把線程調度系統(tǒng)當做（數(shù)據(jù)）包調度系統(tǒng)來使用（我非常喜歡這一點，之前從來沒聽說過類似的觀點）。

  
  

• Nginx宣稱，它并不把線程調度當作（數(shù)據(jù)）包調度來用使用，它自已做（進行）包調度。使用select來查找socket，我們知道數(shù)據(jù)來了，于是就可以立即讀取并處理它，數(shù)據(jù)也不會堵塞。

  
  

  
  

• 經(jīng)驗：讓Unix/Linux處理網(wǎng)絡堆棧，之后的事情就由你自已來處理。

  
  

你怎么編寫軟件使其可伸縮？

1. 包的可擴展性

   
   

2. 多核的可擴展性

   
   

3. 內存的可擴展性

   
   

精簡包-編寫自己的定制驅動來繞過內核堆棧

• 數(shù)據(jù)包的存在的問題是它們要通過Unix的內核。網(wǎng)絡堆棧復雜又慢。你的應用程序需要的數(shù)據(jù)包的路徑要更加直接。不要讓操作系統(tǒng)來處理數(shù)據(jù)包。

  
  

  
  

• 做到這一點的方法是編寫自己的驅動程序。所有驅動程序要做到是發(fā)送數(shù)據(jù)包到你的應用程序而不是通過內核協(xié)議棧。你可以找得到驅動有：PF_RING,Netmap,Interl DPDK(數(shù)據(jù)層開發(fā)套件)。

  
  

  
  

• 有多快呢？Inter有一個基準是在一個輕量級的服務器上每秒可以處理8000萬的數(shù)據(jù)包（每個數(shù)據(jù)包200個時鐘周期）。這也是通過用戶模式。數(shù)據(jù)包通過用戶模式后再向下傳遞。當Linux獲得UDP數(shù)據(jù)包后通過用戶模式在向下傳遞時，它每秒處理的數(shù)據(jù)包不會超過100萬個?？蛻趄寗訉inux來說性能比是80:1。

  
  

  
  

• 如果用200個時間周期來每秒獲得1000萬個數(shù)據(jù)包，那么可以剩下1400個時鐘周期來實現(xiàn)一個類似DNS/IDS的功能。

  
  

  
  

• 用PF_RING/DPDK來獲得原始的數(shù)據(jù)包的話，你必須自己去做TCP協(xié)議棧。人們正在做用戶模式的堆棧。對于Inter來講已有一個提供真正可擴展性能的可用的TCP堆棧。

  
  

多核的可擴展性

多線程編程不是多核編程

• 每個CPU有多個線程
• 鎖來協(xié)調線程（通過系統(tǒng)調用）
• 每個線程有不同的任務

• 每個CPU核心一個線程
• 當兩個核心中的兩個不同線程訪問同一數(shù)據(jù)時，它們不用停止來相互等待
• 所有線程是同一任務的一部分

• 保持每一個核心的數(shù)據(jù)結構，然后聚集起來讀取所有的組件。

  
  

• 原子性. CPU支持的指令集可以被C調用。保證原子性且沒有沖突是非常昂貴的，所以不要期望所有的事情都使用指令。

  
  

• 無鎖的數(shù)據(jù)結構。線程間訪問不用相互等待。不要自己來做，在不同架構上來實現(xiàn)這個是一個非常復雜的工作。

  
  

• 線程模型。線性線程模型與輔助線程模型。問題不僅僅是同步。而是怎么架構你的線程。

  
  

• 處理器族。告訴操作系統(tǒng)使用前兩個核心。之后設置你的線程運行在那個核心上。你也可以使用中斷來做同樣的事兒。所以你有多核心的CPU，但這不關Linux事。

  
  

內存的可擴展性

• 提高緩存效率，不要使用指針在整個內存中隨便亂放數(shù)據(jù)。每次你跟蹤一個指針都會造成一次高速緩存缺失：[hash pointer] -> [Task Control Block] -> [Socket] -> [App]。這造成了4次高速緩存缺失。將所有的數(shù)據(jù)保持在一個內存塊中：[TCB | Socket | App]. 為每個內存塊預分配內存。這樣會將高速緩存缺失從4降低到1。

  
  




• 分頁，32G的數(shù)據(jù)需要占用64M的分頁表，不適合都放在高速緩存上。所以造成2個高速緩存缺失，一個是分頁表另一個是它指向的數(shù)據(jù)。這些細節(jié)在開發(fā)可擴展軟件時是不可忽略的。解決：壓縮數(shù)據(jù)，使用有很多內存訪問的高速架構，而不是二叉搜索樹。NUMA加倍了主內存的訪問時間。內存有可能不在本地，而在其它地方

  
  




• 內存池 ， 在啟動時立即分配所有的內存。在對象（object）、線程（thread）和socket的基礎上分配（內存）。

  
  




• 超線程，提高CPU使用率，減少延遲，比如當在內存訪問中一個線程等待另一個全速線程，這種情況，超線程CPU可以并行執(zhí)行，不用等待。

  
  




• 大內存頁, 減小頁表的大小。從一開始就預留內存，并且讓應用程序管理內存。

  
  

  
  

F-Stack 架構