[[399386]]

本文轉載自微信公眾號「小菜學編程」，作者 fasionchan。轉載本文請聯(lián)系小菜學編程公眾號。

C10K問題

在互聯(lián)網(wǎng)尚未普及的早期，一臺服務器同時在線 100 個用戶已經(jīng)算是非常大型的應用了，工程上沒有什么挑戰(zhàn)。

隨著 Web 2.0 時代的到來，用戶群體成幾何倍數(shù)增長，服務器需要更強的并發(fā)處理能力才能承載海量的用戶。這時，著名的 C10K 問題誕生了——如何讓單臺服務器同時支撐 1 萬個客戶端連接?

最初的服務器應用編程模型，是基于進程/線程的：當一個新的客戶端連接上來，服務器就分配一個進程或線程，來處理這個新連接。這意味著，想要解決 C10K 問題，操作系統(tǒng)需要同時運行 1 萬個進程或線程。

進程和線程是操作系統(tǒng)中，開銷最大的資源之一。每個新連接都新開進程/線程，將造成極大的資源浪費。況且，受硬件資源制約，系統(tǒng)同一時間能運行的進程/線程數(shù)存在上限。

換句話講，在進程/線程模型中，每臺服務器能處理的客戶端連接數(shù)是非常有限的。為支持海量的業(yè)務，只能通過堆服務器這種簡單粗暴的方式來實現(xiàn)。但這樣的人海戰(zhàn)術，既不穩(wěn)定，也不經(jīng)濟。

為了在單個進程/線程中同時處理多個網(wǎng)絡連接，select 、 poll 、epoll 等 IO多路復用 技術應運而生。在IO多路復用模型，進程/線程不再阻塞在某個連接上，而是同時監(jiān)控多個連接，只處理那些有新數(shù)據(jù)達到的活躍連接。

為什么需要協(xié)程

單純的IO多路復用編程模型，不像阻塞式編程模型那樣直觀，這為工程項目帶來諸多不便。最典型的像 JavaScript 中的回調式編程模型，程序中各種 callback 函數(shù)滿天飛，這不是一種直觀的思維方式。

為實現(xiàn)阻塞式那樣直觀的編程模型，協(xié)程(用戶態(tài)線程)的概念被提出來。協(xié)程在進程/線程基礎之上，實現(xiàn)多個執(zhí)行上下文。由 epoll 等IO多路復用技術實現(xiàn)的事件循環(huán)，則負責驅動協(xié)程的調度、執(zhí)行。

協(xié)程可以看做是IO多路復用技術更高層次的封裝。雖然與原始IO多路復用相比有一定的性能開銷，但與進程/線程模型相比卻非常突出。協(xié)程占用資源比進程/線程少，而且切換成本比較低。因此，協(xié)程在高并發(fā)應用領域潛力無限。

然而，協(xié)程獨特的運行機制，讓初學者吃了不少虧，錯漏百出。

接下來，我們通過若干簡單例子，探索協(xié)程應用之道，從中體會協(xié)程的作用，并揭示高并發(fā)應用設計、部署中存在的常見誤區(qū)。由于 asyncio 是 Python 協(xié)程發(fā)展的主要趨勢，例子便以 asyncio 為講解對象。

第一個協(xié)程應用

協(xié)程應用由事件循環(huán)驅動，套接字必須是非阻塞模式，否則會阻塞事件循環(huán)。因此，一旦使用協(xié)程，就要跟很多類庫說拜拜了。以 MySQL 數(shù)據(jù)庫操作為例，如果我們使用 asyncio ，就要用 aiomysql 包來連數(shù)據(jù)庫。

而想要開發(fā) Web 應用，則可以用 aiohttp 包，它可以通過 pip 命令安裝：

$ pip install aiohttp 

這個例子實現(xiàn)一個完整 Web 服務器，雖然它只有返回當前時間的功能：

from aiohttp import web 
from datetime import datetime 
 
async def handle(request): 
    return web.Response(text=datetime.now().strftime('%Y-%m-%d %H:%M:%S')) 
 
app = web.Application() 
app.add_routes([ 
    web.get('/', handle), 
]) 
 
if __name__ == '__main__': 
    web.run_app(app) 

第 4 行，實現(xiàn)處理函數(shù)，獲取當前時間并返回;

第 7 行，創(chuàng)建應用對象，并將處理函數(shù)注冊到路由中;

第 13 行，將 Web 應用跑起來，默認端口是 8080 ;

當一個新的請求到達時，aiohttp 將創(chuàng)建一個新協(xié)程來處理該請求，它將負責執(zhí)行對應的處理函數(shù)。因此，處理函數(shù)必須是合法的協(xié)程函數(shù)，以 async 關鍵字開頭。

將程序跑起來后，我們就可以通過它獲悉當前時間。在命令行中，可以用 curl 命令來發(fā)起請求：

$ curl http://127.0.0.1:8080/ 
2020-08-06 15:50:34 

壓力測試

研發(fā)高并發(fā)應用，需要評估應用的處理能力。我們可以在短時間內發(fā)起大量的請求，并測算應用的吞吐能力。然而，就算你手再快，一秒鐘也只能發(fā)起若干個請求呀。怎么辦呢?

我們需要借助一些壓力測試工具，例如 Apache 工具集中的 ab 。如何安裝使用 ab 不在本文的討論范圍，請參考這篇文章：Web壓力測試(https://network.fasionchan.com/zh_CN/latest/performance/web-pressure-test.html) 。

事不宜遲，我們先以 100 為并發(fā)數(shù)，壓 10000 個請求看看結果：

$ ab -n 10000 -c 100 http://127.0.0.1:8080/ 
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 
 
Benchmarking 127.0.0.1 (be patient) 
Completed 1000 requests 
Completed 2000 requests 
Completed 3000 requests 
Completed 4000 requests 
Completed 5000 requests 
Completed 6000 requests 
Completed 7000 requests 
Completed 8000 requests 
Completed 9000 requests 
Completed 10000 requests 
Finished 10000 requests 
 
 
Server Software:        Python/3.8 
Server Hostname:        127.0.0.1 
Server Port:            8080 
 
Document Path:          / 
Document Length:        19 bytes 
 
Concurrency Level:      100 
Time taken for tests:   5.972 seconds 
Complete requests:      10000 
Failed requests:        0 
Total transferred:      1700000 bytes 
HTML transferred:       190000 bytes 
Requests per second:    1674.43 [#/sec] (mean) 
Time per request:       59.722 [ms] (mean) 
Time per request:       0.597 [ms] (mean, across all concurrent requests) 
Transfer rate:          277.98 [Kbytes/sec] received 
 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:        0    2   1.5      1      15 
Processing:    43   58   5.0     57      89 
Waiting:       29   47   6.3     47      85 
Total:         43   60   4.8     58      90 
 
Percentage of the requests served within a certain time (ms) 
  50%     58 
  66%     59 
  75%     60 
  80%     61 
  90%     65 
  95%     69 
  98%     72 
  99%     85 
 100%     90 (longest request) 

-n 選項，指定總請求數(shù)，即總共發(fā)多少個請求;

-c 選項，指定并發(fā)數(shù)，即同時發(fā)多少個請求;

從 ab 輸出的報告中可以獲悉，10000 個請求全部成功，總共耗時 5.972 秒，處理速度可以達到 1674.43 個每秒。

現(xiàn)在，我們嘗試提供并發(fā)數(shù)，看處理速度有沒有提升：

$ ab -n 10000 -c 100 http://127.0.0.1:8080/ 

在 1000 并發(fā)數(shù)下，10000 個請求在 5.771 秒內完成，處理速度是 1732.87 ，略有提升但很不明顯。這一點也不意外，例子中的處理邏輯絕大部分都是計算型，虛增并發(fā)數(shù)幾乎沒有任何意義。

協(xié)程擅長做什么

協(xié)程擅長處理 IO 型的應用邏輯，舉個例子，當某個協(xié)程在等待數(shù)據(jù)庫響應時，事件循環(huán)將喚醒另一個就緒協(xié)程來執(zhí)行，以此提高吞吐。為降低復雜性，我們通過在程序中睡眠來模擬等待數(shù)據(jù)庫的效果。

import asyncio 
 
from aiohttp import web 
from datetime import datetime 
 
async def handle(request): 
    # 睡眠一秒鐘 
    asyncio.sleep(1) 
    return web.Response(text=datetime.now().strftime('%Y-%m-%d %H:%M:%S')) 
 
app = web.Application() 
app.add_routes([ 
    web.get('/', handle), 
]) 
 
if __name__ == '__main__': 
    web.run_app(app) 

可以看到，隨著并發(fā)數(shù)的增加，處理速度也有明顯的提升，趨勢接近線性。