作者 | Draveness

**導讀**：本文作者寫這篇文章前前後後大概 2 個月的時間，全文大概 2w 字，建議收藏後閱讀或者透過電腦閱讀。

排程是一個非常廣泛的概念，很多領域都會使用排程這個術語，在電腦科學中，[排程](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)就是一種將任務（Work）分配給資源的方法。任務可能是虛擬的計算任務，例如執行緒、程式或者資料流，這些任務會被排程到硬體資源上執行，例如：處理器 CPU 等裝置。

![·1.png](https://ucc.alicdn.com/pic/developer-ecology/b40e96deed144ac8bc739e2d76462cae.png)

圖 1 - 排程系統設計精要

本文會介紹排程系統的常見場景以及設計過程中的一些關鍵問題，排程器的設計最終都會歸結到一個問題上 — 如何對資源高效的分配和排程以達到我們的目的，可能包括對資源的合理利用、最小化成本、快速匹配供給和需求。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/af4b3c59ee1542c288cd071d6f7861bd.png)

圖 2 - 文章脈絡和內容

除了介紹排程系統設計時會遇到的常見問題之外，本文還會深入分析幾種常見的排程器的設計、演進與實現原理，包括作業系統的程式排程器，Go 語言的執行時排程器以及 Kubernetes 的工作負載排程器，幫助我們理解排程器設計的核心原理。

# 設計原理

排程系統其實就是排程器（Scheduler），我們在很多系統中都能見到排程器的身影，就像我們在上面說的，不止作業系統中存在排程器，程式語言、容器編排以及很多業務系統中都會存在排程系統或者排程模組。

這些排程模組的核心作用就是對有限的資源進行分配，以實現最大化資源的利用率或者降低系統的尾延遲，排程系統面對的就是資源的需求和供給不平衡的問題。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/cb5c4a31a9c749d2835094dc3230f2c0.png)

圖 3 - 排程器的任務和資源

我們在這一節中將從多個方面介紹排程系統設計時需要重點考慮的問題，其中包括排程系統的需求調研、排程原理以及架構設計。

## 1. 需求調研

在著手構建排程系統之前，首要的工作就是進行詳細的需求調研和分析，在這個過程中需要完成以下兩件事：

- 調研排程系統的應用場景，深入研究場景中待執行的任務（Work）和能用來執行任務的資源（Resource）的特性；
- 分析排程系統的目的，可能是成本優先、質量優先、最大化資源的利用率等，排程目的一般都是動態的，會隨著需求的變化而轉變；

### 應用場景

排程系統應用的場景是我們首先需要考慮的問題，對應用場景的分析至關重要，我們需要深入瞭解當前場景下待執行任務和能用來執行任務的資源的特點。我們需要分析待執行任務的以下特徵：

- 任務是否有截止日期，必須在某個時間點之前完成；
- 任務是否支援搶佔，搶佔的具體規則是什麼；
- 任務是否包含前置的依賴條件；
- 任務是否只能在指定的資源上執行；
- ...

而用於執行任務的資源也可能存在資源不平衡，不同資源處理任務的速度不一致的問題。

資源和任務特點的多樣性決定了排程系統的設計，我們在這裡舉幾個簡單的例子幫助各位讀者理解排程系統需求分析的過程。

![4.jpeg](https://ucc.alicdn.com/pic/developer-ecology/f9fdce40b48d42b2bfce2b892cb6697c.jpeg)

圖 4 - Linux 作業系統

在作業系統的程式排程器中，待排程的任務就是執行緒，這些任務一般只會處於正在執行或者未執行（等待或者終止）的狀態；而用於處理這些任務的 CPU 往往都是不可再分的，同一個 CPU 在同一時間只能執行一個任務，這是物理上的限制。簡單總結一下，作業系統排程器的任務和資源有以下特性：

- 任務 —— Thread。狀態簡單：只會處於正在執行或者未被執行兩種狀態；優先順序不同：待執行的任務可能有不同的優先順序，在考慮優先順序的情況下，需要保證不同任務的公平性；
- 資源 —— CPU 時間。資源不可再分：同一時間只能執行一個任務；

在上述場景中，待執行的任務是作業系統排程的基本單位 —— 執行緒，而可分配的資源是 CPU 的時間。Go 語言的排程器與作業系統的排程器面對的是幾乎相同的場景，其中的任務是 Goroutine，可以分配的資源是在 CPU 上執行的執行緒。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/fbfe0960be9043db9de95909a324e6cf.png)

圖 5 - 容器編排系統 Kubernetes

除了作業系統和程式語言這種較為底層的排程器之外，容器和計算任務排程在今天也很常見，Kubernetes 作為容器編排系統會負責調取叢集中的容器，對它稍有了解的人都知道，Kubernetes 中排程的基本單元是 Pod，這些 Pod 會被排程到節點 Node 上執行：

- 任務 —— Pod。優先順序不同：Pod 的優先順序可能不同，高優先順序的系統 Pod 可以搶佔低優先順序 Pod 的資源；有狀態：Pod 可以分為無狀態和有狀態，有狀態的 Pod 需要依賴持久儲存卷；

- 資源 —— Node。型別不同：不同節點上的資源型別不同，包括 CPU、GPU 和記憶體等，這些資源可以被拆分但是都屬於當前節點；不穩定：節點可能由於突發原因不可用，例如：無網路連線、磁碟損壞等；

排程系統在生活和工作中都很常見，除了上述的兩個場景之外，其他需要排程系統的場景包括 CDN 的資源排程、訂單排程以及離線任務排程系統等。在不同場景中，我們都需要深入思考任務和資源的特性，它們對系統的設計起者指導作用。

### 排程目的

在深入分析排程場景後，我們需要理解排程的目的。我們可以將排程目的理解成機器學習中的成本函式（Cost function），確定排程目的就是確定成本函式的定義，排程理論一書中曾經介紹過常見的[排程目的](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)，包含以下內容：

- 完成跨度（Makesapan） — 第一個到最後一個任務完成排程的時間跨度；
- 最大延遲（Maximum Lateness） — 超過截止時間最長的任務；
- 加權完成時間的和（Total weighted completion time）— 權重乘完成時間的總和；
- ...

這些都是偏理論的排程的目的，多數業務排程系統的排程目的都是最佳化與業務聯絡緊密的指標 — 成本和質量。如何在成本和質量之間達到平衡是需要仔細思考和設計的，由於篇幅所限以及業務場景的複雜，本文不會分析如何權衡成本和質量，這往往都是需要結合業務考慮的事情，不具有足夠的相似性。

## 2. 排程原理

效能優異的排程器是實現特定排程目的前提，我們在討論排程場景和目的時往往都會忽略排程的額外開銷，然而排程器執行時的延時和吞吐量等指標在排程負載較重時是不可忽視的。本節會分析與排程器實現相關的一些重要概念，這些概念能夠幫助我們實現高效能的排程器：

- 協作式排程與搶佔式排程；
- 單排程器與多排程器；
- 任務分享與任務竊取；

### 協作式與搶佔式
 
協作式（Cooperative）與搶佔式（Preemptive）排程是作業系統中常見的多工執行策略。這兩種排程方法的定義完全不同：

- 協作式排程允許任務執行任意長的時間，直到任務主動通知排程器讓出資源；
- 搶佔式排程允許任務在執行過程中被排程器掛起，排程器會重新決定下一個執行的任務；

![6.png](https://ucc.alicdn.com/pic/developer-ecology/6d319036b1fa465a89a74de79e4dda95.png)

圖 6 - 協作式排程與搶佔式排程

任務的執行時間和任務上下文切換的額外開銷決定了哪種排程方式會帶來更好的效能。如下圖所示，圖 7 展示了一個協作式排程器排程任務的過程，排程器一旦為某個任務分配了資源，它就會等待該任務主動釋放資源，圖中 4 個任務儘管執行時間不同，但是它們都會在任務執行完成後釋放資源，整個過程也只需要 4 次上下文的切換。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d4cb5c8237cf40e3b03eca82419c3aab.png)

圖 7 - 協作式排程

圖 8 展示了搶佔式排程的過程，由於排程器不知道所有任務的執行時間，所以它為每一個任務分配了一段時間切片。任務 1 和任務 4 由於執行時間較短，所以在第一次被排程時就完成了任務；但是任務 2 和任務 3 因為執行時間較長，超過了排程器分配的上限，所以為了保證公平性會觸發搶佔，等待佇列中的其他任務會獲得資源。在整個排程過程中，一共發生了 6 次上下文切換。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/94e16652b3754409a4424d0a8d5306c9.png)

圖 8 - 搶佔式排程

如果部分任務的執行時間很長，協作式的任務排程會使部分執行時間長的任務餓死其他任務；不過如果待執行的任務執行時間較短並且幾乎相同，那麼使用協作式的任務排程能減少任務中斷帶來的額外開銷，從而帶來更好的排程效能。

因為多數情況下任務執行的時間都不確定，在協作式排程中一旦任務沒有主動讓出資源，那麼就會導致其它任務等待和阻塞，所以排程系統一般都會以搶佔式的任務排程為主，同時支援任務的協作式排程。

### 單排程器與多排程器
 
使用單個排程器還是多個排程器也是設計排程系統時需要仔細考慮的，多個排程器並不一定意味著多個程式，也有可能是一個程式中的多個排程執行緒，它們既可以選擇在多核上並行排程、在單核上併發排程，也可以同時利用並行和併發提高效能。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/5c50bc21db554e6eab3d61a7912ccc71.png)

圖 9 - 單排程器排程任務和資源

不過對於排程系統來說，因為它做出的決策會改變資源的狀態和系統的上下文進而影響後續的排程決策，所以單排程器的序列排程是能夠精準排程資源的唯一方法。單個排程器利用不同渠道收集排程需要的上下文，並在收到排程請求後會根據任務和資源情況做出當下最優的決策。

隨著排程器的不斷演變，單排程器的效能和吞吐量可能會受到限制，我們還是需要引入並行或者併發排程來解決效能上的瓶頸，這時我們需要將待排程的資源分割槽，讓多個排程器分別負責排程不同區域中的資源。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/7e23924b8e434c6bac911e1a4a2e8f8c.png)

圖 10 - 多排程器與資源分割槽

多排程器的併發排程能夠極大提升排程器的整體效能，例如 Go 語言的排程器。Go 語言執行時會將多個 CPU 交給不同的處理器分別排程，這樣透過並行排程能夠提升排程器的效能。

上面介紹的兩種排程方法都建立在需要精準排程的前提下，多排程器中的每一個排程器都會面對無關的資源，所以對於同一個分割槽的資源，排程還是序列的。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/1dd30992cee04f8baeb2c55c946c35d8.png)

圖 11 - 多排程器粗粒度排程

使用多個排程器同時排程多個資源也是可行的，只是可能需要犧牲排程的精確性 — 不同的排程器可能會在不同時間接收到狀態的更新，這就會導致不同排程器做出不同的決策。負載均衡就可以看做是多執行緒和多程式的排程器，因為對任務和資源掌控的資訊有限，這種粗粒度排程的結果很可能就是不同機器的負載會有較大差異，所以無論是小規模叢集還是大規模叢集都很有可能導致某些例項的負載過高。

### 工作分享與工作竊取

這一小節將繼續介紹在多個排程器間重新分配任務的[兩個排程正規化](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) — 工作分享（Work Sharing）和工作竊取（Work Stealing）。獨立的排程器可以同時處理所有的任務和資源，所以它不會遇到多排程器的任務和資源的不平衡問題。在多數的排程場景中，任務的執行時間都是不確定的，假設多個排程器分別排程相同的資源，由於任務的執行時間不確定，多個排程器中等待排程的任務佇列最終會發生差異 — 部分佇列中包含大量任務，而另外一些佇列不包含任務，這時就需要引入任務再分配策略。

工作分享和工作竊取是完全不同的兩種再分配策略。在工作分享中，當排程器建立了新任務時，它會將一部分任務分給其他排程器；而在工作竊取中，當排程器的資源沒有被充分利用時，它會從其他排程器中竊取一些待分配的任務，如下圖所示：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/214c5285d07d4cd4ab76b1c67d9c5bcf.png)

圖 12 - 工作竊取排程器

這兩種任務再分配的策略都為系統增加了額外的開銷，與工作分享相比，工作竊取只會在當前排程器的資源沒有被充分利用時才會觸發，所以工作竊取引入的額外開銷更小。工作竊取在生產環境中更加常用，Linux 作業系統和 Go 語言都選擇了工作竊取策略。

## 3. 架構設計

本節將從排程器內部和外部兩個角度分析排程器的架構設計，前者分析排程器內部多個元件的關係和做出排程決策的過程；後者分析多個排程器應該如何協作，是否有其他的外部服務可以輔助排程器做出更合理的排程決策。

### 排程器內部

當排程器收到待排程任務時，會根據採集到的狀態和待排程任務的規格（Spec）做出合理的排程決策，我們可以從下圖中瞭解常見排程系統的內部邏輯。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/f5046792c08f416bb2d233d778af7c2e.png)

圖 13 - 排程器做出排程決策

常見的排程器一般由兩部分組成 — 用於收集狀態的狀態模組和負責做決策的決策模組。

- 狀態模組

狀態模組會從不同途徑收集儘可能多的資訊為排程提供豐富的上下文，其中可能包括資源的屬性、利用率和可用性等資訊。根據場景的不同，上下文可能需要儲存在 MySQL 等持久儲存中，一般也會在記憶體中快取一份以減少排程器訪問上下文的開銷。

- 決策模組

決策模組會根據狀態模組收集的上下文和任務的規格做出排程決策，需要注意的是做出的排程決策只是在當下有效，在未來某個時間點，狀態的改變可能會導致之前做的決策不符合任務的需求，例如：當我們使用 Kubernetes 排程器將工作負載排程到某些節點上，這些節點可能由於網路問題突然不可用，該節點上的工作負載也就不能正常工作，即排程決策失效。

排程器在排程時都會透過以下的三個步驟為任務排程合適的資源：

1. 透過優先順序、任務建立時間等資訊確定不同任務的排程順序；
1. 透過過濾和打分兩個階段為任務選擇合適的資源；
1. 不存在滿足條件的資源時，選擇犧牲的搶佔物件。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/141ec7c9ab6548a19835bd09af781e5d.png)

圖 14 - 排程框架

上圖展示了常見排程器決策模組執行的幾個步驟，確定優先順序、對閒置資源進行打分、確定搶佔資源的犧牲者，上述三個步驟中的最後一個往往都是可選的，部分排程系統不需要支援搶佔式排程的功能。

### 排程器外部

如果我們將排程器看成一個整體，從排程器外部看架構設計就會得到完全不同的角度 — 如何利用外部系統增強排程器的功能。在這裡我們將介紹兩種排程器外部的設計，分別是多排程器和反排程器（Descheduler）。

- 多排程器

序列排程與並行排程一節已經分析了多排程器的設計，我們可以將待排程的資源進行分割槽，讓多個排程器執行緒或者程式分別負責各個區域中資源的排程，充分利用多和 CPU 的並行能力。

- 反排程器

反排程器是一個比較有趣的概念，它能夠移除決策不再正確的排程，降低系統中的熵，讓排程器根據當前的狀態重新決策。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/77b0d17becb940058d65e448964c3143.png)

圖 15 - 排程器與反排程器

反排程器的引入使得整個排程系統變得更加健壯。排程器負責根據當前的狀態做出正確的排程決策，反排程器根據當前的狀態移除錯誤的排程決策，它們的作用看起來相反，但是目的都是為任務排程更合適的資源。

反排程器的使用沒有那麼廣泛，實際的應用場景也比較有限。作者第一次發現這個概念是在 Kubernetes 孵化的[descheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 專案中，不過因為反排程器移除排程關係可能會影響正在執行的線上服務，所以 Kubernetes 也只會在特定場景下使用。

# 作業系統

排程器是作業系統中的重要元件，作業系統中有程式排程器、網路排程器和 I/O 排程器等元件，本節介紹的是作業系統中的程式排程器。

有一些讀者可能會感到困惑，作業系統排程的最小單位不是執行緒麼，為什麼這裡使用的是程式排程。在 Linux 作業系統中，排程器排程的不是程式也不是執行緒，它排程的是 task_struct 結構體，該結構體既可以表示執行緒，也可以表示程式，而排程器會將程式和執行緒都看成任務，我們在這裡先[說明](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)這一問題，避免讀者感到困惑。我們會使用程式排程器這個術語，但是一定要注意 Linux 排程器中並不區分執行緒和程式。

> Linux incorporates process and thread scheduling by treating them as one in the same. A process can be viewed as a single thread, but a process can contain multiple threads that share some number of resources (code and/or data).

接下來，本節會研究作業系統中排程系統的型別以及 Linux 程式排程器的演進過程。

## 1. 排程系統型別

作業系統會將程式排程器分成三種不同的型別，即長期排程器、中期排程器和短期排程器。這三種不同型別的排程器分別提供了不同的功能，我們將在這一節中依次介紹它們。

### 長期排程器

長期排程器（Long-Term Scheduler）也被稱作任務排程器（Job Scheduler），它能夠決定哪些任務會進入排程器的準備佇列。當我們嘗試執行新的程式時，長期排程器會負責授權或者延遲該程式的執行。長期排程器的作用是平衡同時正在執行的 I/O 密集型或者 CPU 密集型程式的任務數量：

- 如果 I/O 密集型任務過多，就緒佇列中就不存在待排程的任務，短期排程器不需要執行排程，CPU 資源就會面臨閒置；
- 如果 CPU 密集型任務過多，I/O 等待佇列中就不存在待排程的任務，I/O 裝置就會面臨閒置；

長期排程器能平衡同時正在執行的 I/O 密集型和 CPU 密集型任務，最大化的利用作業系統的 I/O 和 CPU 資源。

### 中期排程器

中期排程器會將不活躍的、低優先順序的、發生大量頁錯誤的或者佔用大量記憶體的程式從記憶體中移除，為其他的程式釋放資源。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/b4c1fb299f6048518c29332e2273d846.png)

圖 16 - 中期排程器

當正在執行的程式陷入 I/O 操作時，該程式只會佔用計算資源，在這種情況下，中期排程器就會將它從記憶體中移除等待 I/O 操作完成後，該程式會重新加入就緒佇列並等待短期排程器的排程。

### 短期排程器

短期排程器應該是我們最熟悉的排程器，它會從就緒佇列中選出一個程式執行。程式的選擇會使用特定的排程演算法，它會同時考慮程式的優先順序、入隊時間等特徵。因為每個程式能夠得到的執行時間有限，所以短期排程器的執行十分頻繁。

## 2. 設計與演進

本節將重點介紹 Linux 的 CPU 排程器，也就是短期排程器。Linux 的 CPU 排程器並不是從設計之初就是像今天這樣複雜的，在很長的一段時間裡（v0.01 ~ v2.4），Linux 的程式排程都由幾十行的簡單函式負責，我們先了解一下不同版本排程器的歷史：

- 初始排程器 · v0.01 ~ v2.4。由幾十行程式碼實現，功能非常簡陋；同時最多處理 64 個任務；

- 排程器 · v2.4 ~ v2.6。排程時需要遍歷全部任務當待執行的任務較多時，同一個任務兩次執行的間隔很長，會有比較嚴重的飢餓問題；

- 排程器 · v2.6.0 ~ v2.6.22。透過引入執行佇列和優先陣列實現  的時間複雜度；使用本地執行佇列替代全域性執行佇列增強在對稱多處理器的擴充套件性；引入工作竊取保證多個執行佇列中任務的平衡；

- 完全公平排程器 · v2.6.23 ~ 至今。引入紅黑樹和執行時間保證排程的公平性；引入排程類實現不同任務型別的不同排程策略；

這裡會詳細介紹從最初的排程器到今天覆雜的完全公平排程器（Completely Fair Scheduler，CFS）的演變過程。

### 初始排程器

Linux 最初的程式排程器僅由 sched.h 和 sched.c 兩個檔案構成。你可能很難想象 Linux 早期版本使用只有幾十行的 schedule 函式負責了[作業系統程式的排程](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)：

```
void schedule(void) {
    int i,next,c;
    struct task_struct ** p;
    for(p = &LAST_TASK ; p > &FIRST_TASK ; --p) {
       ...
    }
    while (1) {
        c = -1;
        next = 0;
        i = NR_TASKS;
        p = &task[NR_TASKS];
        while (--i) {
            if (!*--p) continue;
            if ((*p)->state == TASK_RUNNING && (*p)->counter > c)
                c = (*p)->counter, next = i;
        }
        if (c) break;
        for(p = &LAST_TASK ; p > &FIRST_TASK ; --p)
            if (*p)
                (*p)->counter = ((*p)->counter >> 1) + (*p)->priority;
    }
    switch_to(next);
}
```

無論是程式還是執行緒，在 Linux 中都被看做是 task_struct 結構體，所有的排程程式都儲存在上限僅為 64 的陣列中，排程器能夠處理的程式上限也只有 64 個。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/c47665c2f1ea497bac718d0ad32cdcad.png)

圖 17 - 最初的程式排程器

上述函式會先喚醒獲得訊號的可中斷程式，然後從佇列倒序查詢計數器 counter 最大的可執行程式，counter 是程式能夠佔用的時間切片數量，該函式會根據時間切片的值執行不同的邏輯：

- 如果最大的 counter 時間切片大於 0，呼叫匯編語言的實現的 switch_to 切換程式；
- 如果最大的 counter 時間切片等於 0，意味著所有程式的可執行時間都為 0，那麼所有程式都會獲得新的時間切片；

Linux 作業系統的計時器會每隔 10ms 觸發一次 do_timer 將當前正在執行程式的 counter 減一，當前程式的計數器歸零時就會重新觸發排程。

### O(n)排程器

排程器是 Linux 在 v2.4 ~ v2.6 版本使用的排程器，由於該調取器在最壞的情況下會遍歷所有的任務，所以它排程任務的時間複雜度就是 。Linux 排程演算法將 CPU 時間分割成了不同的時期（Epoch），也就是每個任務能夠使用的時間切片。

我們可以在 sched.h 和 sched.c 兩個檔案中找到排程器的原始碼。與上一個版本的排程器相比， 排程器的實現複雜了很多，該排程器會在 schedule 函式中[遍歷](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)執行佇列中的所有任務並呼叫 goodness 函式分別計算它們的權重獲得下一個執行的程式：

```
asmlinkage void schedule(void){
    ...
still_running_back:
    list_for_each(tmp, &runqueue_head) {
        p = list_entry(tmp, struct task_struct, run_list);
        if (can_schedule(p, this_cpu)) {
            int weight = goodness(p, this_cpu, prev->active_mm);
            if (weight > c)
                c = weight, next = p;
        }
    }
    ...
}
```

在每個時期開始時，上述程式碼都會為所有的任務計算時間切片，因為需要執行 n 次，所以排程器被稱作  排程器。在預設情況下，每個任務在一個週期都會分配到 200ms 左右的時間切片，然而這種排程和分配的方式是  排程器的最大問題：

- 每輪排程完成之後就會陷入沒有任務需要排程的情況，需要提升互動效能的場景會受到嚴重影響，例如：在桌面拖動滑鼠會感覺到明顯的卡頓；
- 每次查詢權重最高的任務都需要遍歷陣列中的全部任務；
- 排程器[分配](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)的平均時間片大小為 210ms，當程式中包含 100 個程式時，同一個程式被執行兩次的間隔是 21s，這嚴重影響了作業系統的可用性.

正是因為排程器存在了上述的問題，所以 Linux 核心在兩個版本後使用新的  排程器替換該實現。

### O(1)排程器

排程器在 v2.6.0 到 v2.6.22 的 Linux 核心中使用了四年的時間，它能夠在常數時間內完成程式排程，你可以在sched.h 和 sched.c 中檢視  排程器的原始碼。因為實現和功能複雜性的增加，排程器的程式碼行數從  的 2100 行增加到 5000 行，它在排程器的基礎上進行了如下的[改進](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)：

- 排程器支援了  時間複雜度的排程；
- 排程器支援了對稱多處理（Symmetric multiprocessing，SMP）的擴充套件性；
- 排程器最佳化了對稱多處理的親和性。

### 資料結構

排程器透過執行佇列 runqueue 和優先陣列 prio_array 兩個重要的資料結構實現了  的時間複雜度。每一個執行佇列都持有兩個優先陣列，分別儲存活躍的和過期的程式陣列：

```
struct runqueue {
    ...
    prio_array_t *active, *expired, arrays[2];
    ...
}
struct prio_array {
    unsignedint nr_active;
    unsignedlong bitmap[BITMAP_SIZE];
    struct list_head queue[MAX_PRIO];
};
```

優先陣列中的 nr_active 表示活躍的程式數，而 bitmap 和 list_head 共同組成了如下圖所示的資料結構：

![18.png](https://ucc.alicdn.com/pic/developer-ecology/2bbaf17676374ebfa3b23a7420b7a680.png)

圖 18 - 優先陣列

優先陣列的 bitmap 總共包含 140 位，每一位都表示對應優先順序的程式是否存在。圖 17 中的優先陣列包含 3 個優先順序為 2 的程式和 1 個優先順序為 5 的程式。每一個優先順序的標誌位都對應一個 list_head 陣列中的連結串列。 排程器使用上述的資料結構進行如下所示的排程：

- 呼叫 sched_find_first_bit 按照優先順序分配 CPU 資源；
- 呼叫 schedule 從連結串列頭選擇程式執行；
- 透過 schedule 輪訓排程同一優先順序的程式，該函式在每次選中待執行的程式後，將程式新增到佇列的末尾，這樣可以保證同一優先順序的程式會依次執行（Round-Robin）；
- 計時器每隔 1ms 會觸發一次 scheduler_tick 函式，如果當前程式的執行時間已經耗盡，就會將其移入過期陣列；
- 當活躍佇列中不存在待執行的程式時，schedule 會交換活躍優先陣列和過期優先陣列；

上述的這些規則是  排程器執行遵守的主要規則，除了上述規則之外，排程器還需要支援搶佔、CPU 親和等功能，不過在這裡就不展開介紹了。

### 本地執行佇列

全域性的執行佇列是  排程器難以在對稱多處理器架構上擴充套件的主要原因。為了保證執行佇列的一致性，排程器在排程時需要獲取執行佇列的全域性鎖，隨著處理器數量的增加，多個處理器在排程時會導致更多的鎖競爭，嚴重影響排程效能。 排程器透過引入本地執行佇列解決這個問題，不同的 CPU 可以透過 this_rq 獲取繫結在當前 CPU 上的執行佇列，降低了鎖的粒度和衝突的可能性。

```
#define this_rq()        (&__get_cpu_var(runqueues))
```

![19.png](https://ucc.alicdn.com/pic/developer-ecology/239f2ef89a2b46f2b99b3bc42931a51e.png)

圖 19 - 全域性執行佇列和本地執行佇列

多個處理器由於不再需要共享全域性的執行佇列，所以增強了在對稱對處理器架構上的擴充套件性，當我們增加新的處理器時，只需要增加新的執行佇列，這種方式不會引入更多的鎖衝突。

### 優先順序和時間切片

排程器中包含兩種不同的優先順序計算方式，一種是靜態任務優先順序，另一種是動態任務優先順序。在預設情況下，任務的靜態任務優先順序都是 0，不過我們可以透過系統呼叫 nice 改變任務的優先順序； 排程器會獎勵 I/O 密集型任務並懲罰 CPU 密集型任務，它會透過改變任務的靜態優先順序來完成優先順序的動態調整，因為與使用者互動的程式時 I/O 密集型的程式，這些程式由於排程器的動態策略會提高自身的優先順序，從而提升使用者體驗。

### 完全公平排程器

完全公平排程器（Completely Fair Scheduler，CFS）是 v2.6.23 版本被合入核心的排程器，也是核心的預設程式排程器，它的目的是最大化 CPU 利用率和互動的[效能](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)。Linux 核心版本 v2.6.23 中的 CFS 由以下的多個檔案組成：

- include/linux/sched.h
- kernel/sched_stats.h
- kernel/sched.c
- kernel/sched_fair.c
- kernel/sched_idletask.c
- kernel/sched_rt.c

透過 CFS 的名字我們就能發現，該排程器的能為不同的程式提供完全公平性。一旦某些程式受到了不公平的待遇，排程器就會執行這些程式，從而維持所有程式執行時間的公平性。這種保證公平性的方式與『水多了加面，面多了加水』有一些相似：

- 排程器會查詢執行佇列中受到最不公平待遇的程式，併為程式分配計算資源，分配的計算資源是與其他資源執行時間的差值加上最小能夠執行的時間單位；
- 程式執行結束之後發現執行佇列中又有了其他的程式受到了最不公平的待遇，排程器又會執行新的程式；
- ...

排程器演算法不斷計算各個程式的執行時間並依次排程佇列中的受到最不公平對待的程式，保證各個程式的執行時間差不會大於最小執行的時間單位。

### 資料結構

雖然我們還是會延用執行佇列這一術語，但是 CFS 的內部已經不再使用佇列來儲存程式了，cfs_rq 是用來管理待執行程式的新結構體，該結構體會使用紅黑樹（Red-black tree）替代連結串列：

```
struct cfs_rq {
    struct load_weight load;
    unsignedlong nr_running;
    s64 fair_clock;
    u64 exec_clock;
    s64 wait_runtime;
    u64 sleeper_bonus;
    unsignedlong wait_runtime_overruns, wait_runtime_underruns;
    struct rb_root tasks_timeline;
    struct rb_node *rb_leftmost;
    struct rb_node *rb_load_balance_curr;
    struct sched_entity *curr;
    struct rq *rq;
    struct list_head leaf_cfs_rq_list;
};
```

紅黑樹（Red-black tree）是平衡的[二叉搜尋樹](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)，紅黑樹的增刪改查操作的最壞時間複雜度為 ，也就是樹的高度，樹中最左側的節點 rb_leftmost 執行的時間最短，也是下一個待執行的程式。

> 注：在最新版本的 CFS 實現中，核心使用虛擬執行時間 vruntime 替代了等待時間，但是基本的排程原理和排序方式沒有太多變化。

### 排程過程

CFS 的排程過程還是由 schedule 函式完成的，該函式的執行過程可以分成以下幾個步驟：

- 關閉當前 CPU 的搶佔功能；
- 如果當前 CPU 的執行佇列中不存在任務，呼叫 idle_balance 從其他 CPU 的執行佇列中取一部分執行；
- 呼叫 pick_next_task 選擇紅黑樹中優先順序最高的任務；
- 呼叫 context_switch 切換執行的上下文，包括暫存器的狀態和堆疊；
- 重新開啟當前 CPU 的搶佔功能。

CFS 的排程過程與  排程器十分類似，當前排程器與前者的區別只是增加了可選的工作竊取機制並改變了底層的資料結構。

### 排程類

CFS 中的排程類是比較有趣的概念，排程類可以決定程式的排程策略。每個排程類都包含一組負責排程的函式，排程類由如下所示的 sched_class 結構體表示：

```
struct sched_class {
    struct sched_class *next;
    void (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
    void (*dequeue_task) (struct rq *rq, struct task_struct *p, int sleep);
    void (*yield_task) (struct rq *rq, struct task_struct *p);
    void (*check_preempt_curr) (struct rq *rq, struct task_struct *p);
    struct task_struct * (*pick_next_task) (struct rq *rq);
    void (*put_prev_task) (struct rq *rq, struct task_struct *p);
    unsigned long (*load_balance) (struct rq *this_rq, int this_cpu,
            struct rq *busiest,
            unsigned long max_nr_move, unsigned long max_load_move,
            struct sched_domain *sd, enum cpu_idle_type idle,
            int *all_pinned, int *this_best_prio);
    void (*set_curr_task) (struct rq *rq);
    void (*task_tick) (struct rq *rq, struct task_struct *p);
    void (*task_new) (struct rq *rq, struct task_struct *p);
};
```

排程類中包含任務的初始化、入隊和出隊等函式，這裡的設計與物件導向中的設計稍微有些相似。核心中包含 SCHED_NORMAL、SCHED_BATCH、SCHED_IDLE、SCHED_FIFO 和 SCHED_RR 排程類，這些不同的排程類分別實現了 sched_class 中的函式以提供不同的排程行為。

## 3. 小結

本節介紹了作業系統排程器的設計原理以及演進的歷史，從 2007 年合入 CFS 到現在已經過去了很長時間，目前的[排程器](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)也變得更加複雜，社群也在不斷改進程式排程器。

我們可以從 Linux 排程器的演進的過程看到主流系統架構的變化，最初幾十行程式碼的排程器就能完成基本的排程功能，而現在要使用幾萬行程式碼來完成複雜的排程，保證系統的低延時和高吞吐量。

由於篇幅有限，我們很難對作業系統的排程器進行面面俱到的分析，你可以在 這裡 找到作者使用的 Linux 原始碼，親自動手分析不同版本的程式排程器。

## 4. 延伸閱讀

- [Understanding the Linux 2.6.8.1 CPU Scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [CFS Scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [Inside the Linux 2.6 Completely Fair Scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [The Linux desktop may soon be a lot faster](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [Modular Scheduler Core and Completely Fair Scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [The Linux Scheduler: A Decade of Wasted Cores](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)

# Go 語言

Go 語言是誕生自 2009 年的程式語言，相信很多人對 Go 語言的印象都是語法簡單，能夠支撐高併發的服務。語法簡單是程式語言的頂層設計哲學，而語言的高併發支援依靠的是執行時的排程器，這也是本節將要研究的內容。

對 Go 語言稍微有了解的人都知道，[通訊順序程式](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)（Communicating sequential processes，CSP）影響著 Go 語言的併發模型，其中的 Goroutine 和 Channel 分別表示實體和用於通訊的媒介。

![20.png](https://ucc.alicdn.com/pic/developer-ecology/549ac3f59479458d84ddd4dc73e45275.png)

圖 20 - Go 和 Erlang 的併發模型

『不要透過共享記憶體來通訊，我們應該使用通訊來共享記憶體』不只是 Go 語言鼓勵的設計哲學，更為古老的 Erlang 語言其實也遵循了同樣的設計，但是 Erlang 選擇使用了[Actor 模型](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)，我們在這裡就不介紹 CSP 和 Actor 的區別和聯絡的，感興趣的讀者可以在推薦閱讀和應引用中找到相關資源。

## 1. 設計與演進

今天的 Go 語言排程器有著非常優異的效能，但是如果我們回過頭重新看 Go 語言的 v0.x 版本的排程器就會發現最初的排程器非常簡陋，也無法支撐高併發的服務。整個排程器經過幾個大版本的迭代才有了今天的優異效能。

- 單執行緒排程器 · 0.x - 原始碼。只包含 40 多行程式碼；只能單執行緒排程，由 G-M 模型組成；
- 多執行緒排程器 · 1.0 - 原始碼。引入了多執行緒排程；全域性鎖導致競爭嚴重；
- 任務竊取排程器 · 1.1 - 原始碼。引入了處理器 P，構成了目前的 G-M-P 模型；在處理器 P 的基礎上實現了基於工作竊取的排程器；在某些情況下，Goroutine 不會讓出執行緒造成飢餓問題；時間過長的程式暫停（Stop-the-world，STW）會導致程式無法工作；
- 搶佔式排程器 · 1.2 ~ 至今 - 原始碼。實現基於訊號的真搶佔式排程；垃圾回收對棧進行掃描時會觸發搶佔排程；搶佔的時間點不夠多，還不能覆蓋全部的邊緣情況；透過編譯器在函式呼叫時插入檢查指令，實現基於協作的搶佔式排程；GC 和迴圈可能會導致 Goroutine 長時間佔用資源導致程式暫停；協作的搶佔式排程器 - 1.2 ~ 1.13；搶佔式排程器 - 1.14 ~ 至今；
- 非均勻儲存訪問排程器 · 提案。對執行時中的各種資源進行分割槽；實現非常複雜，到今天還沒有提上日程；

除了多執行緒、任務竊取和搶佔式排程器之外，Go 語言社群目前還有一個非均勻儲存訪問（Non-uniform memory access，NUMA）排程器的提案，將來有一天可能 Go 語言會實現這個排程器。在這一節中，我們將依次介紹不同版本排程器的實現以及未來可能會實現的排程器提案。

### 單執行緒排程器

Go 語言在 0.x 版本排程器中只包含表示 Goroutine 的 G 和表示執行緒的 M 兩種結構體，全域性也只有一個執行緒。我們可以在 clean up scheduler 提交中找到單執行緒排程器的原始碼，在這時 Go 語言的 排程器 還是由 C 語言實現的，排程函式 schedule 中也只包含 40 多行程式碼 ：

```
static void scheduler(void) {
    G* gp;
    lock(&sched);
    if(gosave(&m->sched)){
        lock(&sched);
        gp = m->curg;
        switch(gp->status){
        case Grunnable:
        case Grunning:
            gp->status = Grunnable;
            gput(gp);
            break;
        ...
        }
        notewakeup(&gp->stopped);
    }
    gp = nextgandunlock();
    noteclear(&gp->stopped);
    gp->status = Grunning;
    m->curg = gp;
    g = gp;
    gogo(&gp->sched);
}
```

該函式會遵循如下所示的過程執行：

- 獲取排程器的全域性鎖；
- 呼叫 gosave 儲存棧暫存器和程式計數器；
- 呼叫 nextgandunlock 獲取下一個執行緒 M 需要執行的 Goroutine 並解鎖排程器；
- 修改全域性執行緒 m 上要執行的 Goroutine；
- 呼叫 gogo 函式執行最新的 Goroutine。

這個單執行緒排程器的唯一優點就是能跑，不過從這次提交中我們能看到 G 和 M 兩個重要的資料結構，它建立了 Go 語言排程器的框架。

### 多執行緒排程器

Go 語言 1.0 版本在正式釋出時就支援了多執行緒的排程器，與上一個版本完全不可用的排程器相比，Go 語言團隊在這一階段完成了從不可用到可用。我們可以在 proc.c 中找到 1.0.1 版本的排程器，多執行緒版本的排程函式 schedule 包含 70 多行程式碼，我們在這裡保留了其中的核心邏輯：

```
static void schedule(G *gp) {
 schedlock();
 if(gp != nil) {
 gp->m = nil;
 uint32 v = runtime·xadd(&runtime·sched.atomic, -1<<mcpushift if=""> maxgomaxprocs)
 runtime·throw("negative mcpu in scheduler");
 switch(gp->status){
 case Grunning:
 gp->status = Grunnable;
 gput(gp);
 break;
 case ...:
 }
 } else {
 ...
 }
 gp = nextgandunlock();
 gp->status = Grunning;
 m->curg = gp;
 gp->m = m;
 runtime·gogo(&gp->sched, 0);
}
```

整體的邏輯與單執行緒排程器沒有太多區別，多執行緒排程器引入了 GOMAXPROCS 變數幫助我們控制程式中的最大執行緒數，這樣我們的程式中就可能同時存在多個活躍執行緒。

多執行緒排程器的主要問題是排程時的鎖競爭，Scalable Go Scheduler Design Doc 中對排程器做的[效能測試](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)發現 14% 的時間都花費在 runtime.futex 函式上，目前的排程器實現有以下問題需要解決：

- 全域性唯一的排程器和全域性鎖，所有的排程狀態都是中心化儲存的，帶來了鎖競爭；
- 執行緒需要經常互相傳遞可執行的 Goroutine，引入了大量的延遲和額外開銷；
- 每個執行緒都需要處理記憶體快取，導致大量的記憶體佔用並影響資料區域性性（Data locality）；
- 系統呼叫頻繁阻塞和解除阻塞正在執行的執行緒，增加了額外開銷。

這裡的全域性鎖問題和 Linux 作業系統排程器在早期遇到的問題比較相似，解決方案也都大同小異。

### 任務竊取排程器

2012 年 Google 的工程師 Dmitry Vyukov 在 Scalable Go Scheduler Design Doc 中指出了現有多執行緒排程器的問題並在多執行緒排程器上提出了兩個改進的手段：

- 在當前的 G-M 模型中引入了處理器 P；
- 在處理器 P 的基礎上實現基於工作竊取的排程器。

基於任務竊取的 Go 語言排程器使用了沿用至今的 G-M-P 模型，我們能在 runtime: improved scheduler 提交中找到任務竊取排程器剛被實現時的原始碼，排程器的 schedule 函式到現在反而更簡單了：

```
static void schedule(void) {
    G *gp;
 top:
    if(runtime·gcwaiting) {
        gcstopm();
        goto top;
    }
    gp = runqget(m->p);
    if(gp == nil)
        gp = findrunnable();
    ...
    execute(gp);
}
```

- 如果當前執行時在等待垃圾回收，呼叫 gcstopm 函式；
- 呼叫 runqget 和 findrunnable 從本地的或者全域性的執行佇列中獲取待執行的 Goroutine；
- 呼叫 execute 函式在當前執行緒 M 上執行 Goroutine。

當前處理器本地的執行佇列中不包含 Goroutine 時，呼叫 findrunnable 函式會觸發工作竊取，從其他的處理器的佇列中隨機獲取一些 Goroutine。

執行時 G-M-P 模型中引入的處理器 P 是執行緒 M 和 Goroutine 之間的中間層，我們從它的結構體中就能看到 P 與 M 和 G 的關係：

```
struct P {
    Lock;
    uint32  status;  // one of Pidle/Prunning/...
    P*  link;
    uint32  tick;   // incremented on every scheduler or system call
    M*  m;  // back-link to associated M (nil if idle)
    MCache* mcache;
    G** runq;
    int32   runqhead;
    int32   runqtail;
    int32   runqsize;
    G*  gfree;
    int32   gfreecnt;
};
```

處理器 P 持有一個執行佇列 runq，這是由可執行的 Goroutine 組成的陣列，它還反向持有一個執行緒 M 的指標。排程器在排程時會從處理器的佇列中選擇佇列頭的 Goroutine 放到執行緒 M 上執行。如下所示的圖片展示了 Go 語言中的執行緒 M、處理器 P 和 Goroutine 的關係。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/c0782b3a9bcd4cb48253942750d10987.png)

圖 21 - G-M-P 模型

基於工作竊取的多執行緒排程器將每一個執行緒繫結到了獨立的 CPU 上並透過不同處理器分別管理，不同處理器中透過工作竊取對任務進行再分配，提升了排程器和 Go 語言程式的整體效能，今天所有的 Go 語言服務的高效能都受益於這一改動。

### 搶佔式排程器

對 Go 語言併發模型的修改提升了排程器的效能，但是在 1.1 版本中的排程器仍然不支援搶佔式排程，程式只能依靠 Goroutine 主動讓出 CPU 資源。Go 語言的排程器在[1.2 版本](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)中引入了基於協作的搶佔式排程解決下面的[問題](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)：

- 單獨的 Goroutine 可以一直佔用執行緒執行，不會切換到其他的 Goroutine，造成飢餓問題；
- 垃圾回收需要暫停整個程式（Stop-the-world，STW），如果沒有[搶佔](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)可能需要等待幾分鐘的時間，導致整個程式無法工作。

然而 1.2 版本中實現的搶佔式排程是基於協作的，在很長的一段時間裡 Go 語言的排程器都包含一些無法被搶佔的邊緣情況，直到 1.14 才實現了基於訊號的真搶佔式排程解決部分問題。

### 基於協作的搶佔式排程

我們可以在 proc.c 檔案中找到引入搶佔式排程後的排程器實現。Go 語言會在當前的分段棧機制上實現搶佔式的排程，所有的 Goroutine 在函式呼叫時都有機會進入執行時檢查是否需要執行搶佔。基於協作的搶佔是透過以下的多個提交實現的：

- runtime: mark runtime.goexit as nosplit
- runtime: add stackguard0 to G。為 Goroutine 引入 stackguard0 欄位，當該欄位被設定成 StackPreempt 時，Goroutine 會被搶佔；
- runtime: introduce preemption function (not used for now)。引入搶佔函式 preemptone 和 preemptall，這兩個函式會設定 Goroutine 的 StackPreempt；引入搶佔請求 StackPreempt；
- runtime: preempt goroutines for GC。在垃圾回收呼叫的 runtime·stoptheworld 中呼叫 preemptall 函式設定所有處理器上 Goroutine 的 StackPreempt；在 runtime·newstack 函式中增加搶佔的程式碼，當 stackguard0 等於 StackPreempt 時觸發排程器的搶佔；
- runtime: preempt long-running goroutines。在系統監控中，如果一個 Goroutine 的執行時間超過 10ms，就會呼叫 retake 和 preemptone；
- runtime: more reliable preemption。修復 Goroutine 因為週期性執行非阻塞的 CGO 或者系統呼叫不會被搶佔的問題。

從上述一系列的提交中，我們會發現 Go 語言執行時會在垃圾回收暫停程式、系統監控發現 Goroutine 執行超過 10ms 時提出搶佔請求 StackPreempt；因為編譯器會在函式呼叫中插入 runtime.newstack，所以函式呼叫時會透過 runtime.newstack 檢查 Goroutine 的 stackguard0 是否為 StackPreempt 進而觸發搶佔讓出當前執行緒。

這種做法沒有帶來執行時的過多額外開銷，實現也相對比較簡單，不過增加了執行時的複雜度，總體來看還是一種比較成功的實現。因為上述的搶佔是透過編譯器在特定時機插入函式實現的，還是需要函式呼叫作為入口才能觸發搶佔，所以這是一種協作式的搶佔式排程。

### 基於訊號的搶佔式排程

協作的搶佔式排程實現雖然巧妙，但是留下了很多的邊緣情況，我們能在 runtime: non-cooperative goroutine preemption 中找到一些遺留問題：

- runtime: tight loops should be preemptible #10958
- An empty for{} will block large slice allocation in another goroutine, even with GOMAXPROCS > 1 ? #17174
- runtime: tight loop hangs process completely after some time #15442
- ...

Go 語言在 1.14 版本中實現了非協作的搶佔式排程，在實現的過程中我們對已有的邏輯進行重構併為 Goroutine 增加新的狀態和欄位來支援搶佔。Go 團隊透過下面提交的實現了這一功能，我們可以順著提交的順序理解其實現原理：

- runtime: add general suspendG/resumeG。掛起 Goroutine 的過程是在棧掃描時完成的，我們透過 runtime.suspendG 和 runtime.resumeG 兩個函式重構棧掃描這一過程；呼叫 runtime.suspendG 函式時會將執行狀態的 Goroutine 的 preemptStop 標記成 true；呼叫 runtime.preemptPark 函式可以掛起當前 Goroutine、將其狀態更新成 _Gpreempted 並觸發排程器的重新排程，該函式能夠交出執行緒控制權；
- runtime: asynchronous preemption function for x86。在 x86 架構上增加非同步搶佔的函式 runtime.asyncPreempt 和 runtime.asyncPreempt2；
- runtime: use signals to preempt Gs for suspendG。支援透過向執行緒傳送訊號的方式暫停執行的 Goroutine；在 runtime.sighandler 函式中註冊了 SIGURG 訊號的處理函式 runtime.doSigPreempt；runtime.preemptM 函式可以向執行緒傳送搶佔請求；
- runtime: implement async scheduler preemption。修改 runtime.preemptone 函式的實現，加入非同步搶佔的邏輯。

目前的搶佔式排程也只會在垃圾回收掃描任務時觸發，我們可以梳理一下觸發搶佔式排程的過程：

- 程式啟動時，在 runtime.sighandler 函式中註冊了 SIGURG 訊號的處理函式 runtime.doSigPreempt；
- 在觸發垃圾回收的棧掃描時會呼叫 runtime.suspendG 函式掛起 Goroutine。將 _Grunning 狀態的 Goroutine 標記成可以被搶佔，即 preemptStop 設定成 true；呼叫 runtime.preemptM 函式觸發搶佔；
- runtime.preemptM 函式會呼叫 runtime.signalM 向執行緒傳送訊號 SIGURG；
- 作業系統會中斷正在執行的執行緒並執行預先註冊的訊號處理函式 runtime.doSigPreempt；
- runtime.doSigPreempt 函式會處理搶佔訊號，獲取當前的 SP 和 PC 暫存器並呼叫 runtime.sigctxt.pushCall；
- runtime.sigctxt.pushCall 會修改暫存器並在程式回到使用者態時從 runtime.asyncPreempt 開始執行；
- 彙編指令 runtime.asyncPreempt 會呼叫執行時函式 runtime.asyncPreempt2；
- runtime.asyncPreempt2 會呼叫 runtime.preemptPark 函式；
- runtime.preemptPark 會修改當前 Goroutine 的狀態到 _Gpreempted 並呼叫 runtime.schedule 讓當前函式陷入休眠並讓出執行緒，排程器會選擇其他的 Goroutine 繼續執行；

上述 9 個步驟展示了基於訊號的搶佔式排程的執行過程。我們還需要討論一下該過程中訊號的選擇，提案根據以下的四個原因選擇 SIGURG 作為觸發非同步搶佔的[訊號](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)：

- 該訊號需要被偵錯程式透傳；
- 該訊號不會被內部的 libc 庫使用並攔截；
- 該訊號可以隨意出現並且不觸發任何後果；
- 我們需要處理多個平臺上的不同訊號。

目前的搶佔式排程也沒有解決所有潛在的問題，因為 STW 和棧掃描時更可能出現問題，也是一個可以搶佔的安全點（Safe-points），所以我們會在這裡先加入[搶佔功能](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)，在未來可能會加入更多搶佔時間點。

### 非均勻記憶體訪問排程器

非均勻記憶體訪問（Non-uniform memory access，NUMA）排程器目前只是 Go 語言的[提案](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)，因為該提案過於複雜，而目前的排程器的效能已經足夠優異，所以暫時沒有實現該提案。該提案的原理就是透過拆分全域性資源，讓各個處理器能夠就近獲取本地資源，減少鎖競爭並增加資料區域性性。

在目前的執行時中，執行緒、處理器、網路輪訓器、執行佇列、全域性記憶體分配器狀態、記憶體分配快取和垃圾收集器都是全域性的資源。執行時沒有保證本地化，也不清楚系統的拓撲結構，部分結構可以提供一定的區域性性，但是從全域性來看沒有這種保證。

![22.png](https://ucc.alicdn.com/pic/developer-ecology/bb4baef99bf24dfdbeaba49e0a8cd719.png)

圖 22 - Go 語言 NUMA 排程器

如上圖所示，堆疊、全域性執行佇列和執行緒池會按照 NUMA 節點進行分割槽，網路輪訓器和計時器會由單獨的處理器持有。這種方式雖然能夠利用區域性性提高排程器的效能，但是本身的實現過於複雜，所以 Go 語言團隊還沒有著手實現這一提案。

## 2. 小結

Go 語言的排程器在最初的幾個版本中迅速迭代，但是從 1.2 版本之後排程器就沒有太多的變化，直到 1.14 版本引入了真正的搶佔式排程解決了自 1.2 以來一直存在的問題。在可預見的未來，Go 語言的排程器還會進一步演進，增加搶佔式排程的時間點減少存在的邊緣情況。

> 本節內容選擇《Go 語言設計與實現》一書中的 Go 語言排程器實現原理，你可以點選連結瞭解更多與 Go 語言設計與實現原理相關的內容。

## 3. 延伸閱讀

- [How Erlang does scheduling](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [Analysis of the Go runtime scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [Go's work-stealing scheduler](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [runtime: clean up async preemption loose ends](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [The Go netpoller](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [System Calls Make the World Go Round](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN) 
- [Linux Syscall Reference](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)

# Kubernetes

Kubernetes 是生產級別的容器排程和管理系統，在過去的一段時間中，Kubernetes 迅速佔領市場，成為容器編排領域的實施標準。

![23.png](https://ucc.alicdn.com/pic/developer-ecology/bb75513df2d546aa8a70aceb55233a4c.png)

圖 23 - 容器編排系統演進

Kubernetes 是希臘語『舵手』的意思，它最開始由 Google 的幾位軟體工程師創立，深受公司內部[Borg 和 Omega 專案](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)的影響，很多設計都是從 Borg 中借鑑的，同時也對 Borg 的缺陷進行了改進，Kubernetes 目前是 Cloud Native Computing Foundation (CNCF) 的專案，也是很多公司管理分散式系統的[解決方案](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489112&idx=1&sn=1838004b319e343ce6b3c92f62b22a08&chksm=fae51d97cd929481f320d9ec89d4afa0c5245996049e7225b77317b192518a6fb870bf8b0140&token=493285469&lang=zh_CN)。

排程器是 Kubernetes 的核心元件，它的主要功能是為待執行的工作負載 Pod 繫結執行的節點 Node。與其他排程場景不同，雖然資源利用率在 Kubernetes 中也非常重要，但是這只是 Kubernetes 關注的一個因素，它需要在容器編排這個場景中支援非常多並且複雜的業務需求，除了考慮 CPU 和記憶體是否充足，還需要考慮其他的領域特定場景，例如：兩個服務不能佔用同一臺機器的相同埠、幾個服務要執行在同一臺機器上，根據節點的型別排程資源等。

這些複雜的業務場景和排程需求使 Kubernetes 排程器的內部設計與其他排程器完全不同，但是作為使用者應用層的排程器，我們卻能從中學到很多有用的模式和設計。接下來，本節將介紹 Kubernetes 中排程器的設計以及演變。

## 1. 設計與演進

Kubernetes 排程器的演變過程比較簡單，我們可以將它的演進過程分成以下的兩個階段：

- 基於謂詞和優先順序的排程器 · v1.0.0 ~ v1.14.0
- 基於排程框架的排程器 · v1.15.0 ~ 至今

Kubernetes 從 v1.0.0 版本釋出到 v1.14.0，總共 15 個版本一直都在使用謂詞和優先順序來管理不同的排程演算法，知道 v1.15.0 開始引入排程框架（Alpha 功能）來重構現有的排程器。我們在這裡將以 v1.14.0 版本的謂詞和優先順序和 v1.17.0 版本的排程框架分析排程器的演進過程。

### 謂詞和優先順序演算法

謂詞（Predicates）和優先順序（Priorities）排程器是從 Kubernetes v1.0.0 釋出時就存在的模式，v1.14.0 的最後實現與最開始的設計也沒有太多區別。然而從 v1.0.0 到 v1.14.0 期間也引入了很多改進：

- 排程器擴充套件 · v1.2.0 - Scheduler extension。透過呼叫外部排程器擴充套件的方式改變排程器的決策；

- Map-Reduce 優先順序演算法 · v1.5.0 - MapReduce-like scheduler priority functions。為排程器的優先順序演算法支援 Map-Reduce 的計算方式，透過引入可並行的 Map 階段最佳化排程器的計算效能；

- 排程器遷移 · v1.10.0 - Move scheduler code out of plugin directory。從 plugin/pkg/scheduler 移到 pkg/scheduler；kube-scheduler 成為對外直接提供的可執行檔案；

謂詞和優先順序都是 Kubernetes 在排程系統中提供的兩個抽象，謂詞演算法使用 FitPredicate 型別，而優先順序演算法使用 PriorityMapFunction 和 PriorityReduceFunction 兩個型別：

```
type FitPredicate func(pod *v1.Pod, meta PredicateMetadata, nodeInfo *schedulernodeinfo.NodeInfo) (bool, []PredicateFailureReason, error)
type PriorityMapFunction func(pod *v1.Pod, meta interface{}, nodeInfo *schedulernodeinfo.NodeInfo) (schedulerapi.HostPriority, error)
type PriorityReduceFunction func(pod *v1.Pod, meta interface{}, nodeNameToInfo map[string]*schedulernodeinfo.NodeInfo, result schedulerapi.HostPriorityList) error
```

因為 v1.14.0 也是作者剛開始參與 Kubernetes 開發的第一個版本，所以對當時的設計印象也非常深刻，v1.14.0 的 Kubernetes 排程器會使用 PriorityMapFunction 和 PriorityReduceFunction 這種 Map-Reduce 的方式計算所有節點的分數並從其中選擇分數最高的節點。下圖展示了，v1.14.0 版本中排程器的執行過程：

![24.png](https://ucc.alicdn.com/pic/developer-ecology/a7812e0ac23b43139e88c041cbd10107.png)

圖 24 - 謂詞和優先順序演算法

如上圖所示，我們假設排程器中存在一個謂詞演算法和一個 Map-Reduce 優先順序演算法，當我們為一個 Pod 在 6 個節點中選擇最合適的一個時，6 個節點會先經過謂詞的篩選，圖中的謂詞演算法會過濾掉一半的節點，剩餘的 3 個節點經過 Map 和 Reduce 兩個過程分</mcpushift>

排程系統設計精要

相關文章