memcached源碼閱讀筆記
閱讀 memcached ***有 libevent 基礎，memcached 是基于libevent 構建起來的。通由 libevent 提供的事件驅動機制觸發(fā) memcached 中的 IO 事件。
個人認為，閱讀源碼的起初最忌鉆牛角尖，如頭文件里天花亂墜的結構體到底有什么用。源文件里稀里嘩啦的函數(shù)是做什么的。剛開始并沒必要事無巨細弄清楚頭文件每個類型定義的具體用途；很可能那些是不緊要的工具函數(shù)，知道他的功能和用法就沒他事了。
來看 memcached 內部做了什么事情。memcached 是用 c 語言實現(xiàn)，必須有一個入口函數(shù)main()，memcached 的生命從這里開始。
初始化過程
建立并初始化 main_base，即主線程的事件中心，這是 libevent 里面的概念，可以把它理解為事件分發(fā)中心。
建立并初始化 memcached 內部容器數(shù)據結構。
建立并初始化空閑連接結構體數(shù)組。
建立并初始化線程結構數(shù)組，指定每個線程的入口函數(shù)是worker_libevent()，并創(chuàng)建工作線程。從worder_libevent()的實現(xiàn)來看，工作線程都會調用event_base_loop()進入自己的事件循環(huán)。
根據 memcached 配置，開啟以下兩種服務模式中的一種:
以 UNIX 域套接字的方式接受客戶的請求
以 TCP/UDP 套接字的方式接受客戶的請求
memcached 有可配置的兩種模式: UNIX 域套接字和 TCP/UDP，允許客戶端以兩種方式向 memcached 發(fā)起請求?？蛻舳撕头掌髟谕粋€主機上的情況下可以用 UNIX 域套接字，否則可以采用 TCP/UDP 的模式。兩種模式是不兼容的。特別的，如果是 UNIX 域套接字或者 TCP 模式，需要建立監(jiān)聽套接字，并在事件中心注冊了讀事件，回調函數(shù)是event_handler()，我們會看到所有的連接都會被注冊回調函數(shù)是 event_handler()。
調用event_base_loop()開啟 libevent 的事件循環(huán)。到此，memcached 服務器的工作正式進入了工作。如果遇到致命錯誤或者客戶明令結束 memcached，那么才會進入接下來的清理工作。
UNIX 域套接字和 UDP/TCP 工作模式
在初始化過程中介紹了這兩種模式，memcached 這么做為的是讓其能更加可配置。TCP/UDP 自不用說，UNIX 域套接字有獨特的優(yōu)勢:
在同一臺主機上進行通信時，是不同主機間通信的兩倍
UNIX 域套接口可以在同一臺主機上，不同進程之間傳遞套接字描述符
UNIX 域套接字可以向服務器提供客戶的憑證（用戶id或者用戶組id）
其他關于 UNIX 域套接字優(yōu)缺點的請參看: https://pangea.stanford.edu/computing/UNIX/overview/advantages.php
工作線程管理和線程調配方式
在thread_init(),setup_thread()函數(shù)的實現(xiàn)中，memcached 的意圖是很清楚的。每個線程都有自己獨有的連接隊列，即 CQ，注意這個連接隊列中的對象并不是一個或者多個 memcached 命令，它對應一個客戶! 一旦一個客戶交給了一個線程，它的余生就屬于這個線程了! 線程只要被喚醒就立即進入工作狀態(tài)，將自己 CQ 隊列的任務所有完完成。當然，每一個工作線程都有自己的 libevent 事件中心。
很關鍵的線索是thread_init()的實現(xiàn)中，每個工作線程都創(chuàng)建了讀寫管道，所能給我們的提示是: 只要利用 libevent 在工作線程的事件中心注冊讀管道的讀事件，就可以按需喚醒線程，完成工作，很有意思，而setup_thread()的工作正是讀管道的讀事件被注冊到線 程的事件中心，回調函數(shù)是thread_libevent_process().thread_libevent_process()的工作就是從工作線 程自己的 CQ 隊列中取出任務執(zhí)行，而往工作線程工作隊列中添加任務的是dispatch_conn_new()，此函數(shù)一般由主線程調用。下面是主線程和工作線程的工 作流程:
前幾天在微博上，看到 @高端小混混 的微博，轉發(fā)了:
“多任務并行處理的兩種方式，一種是將所有的任務用隊列存儲起來，每個工作者依次去 拿一個來處理，直到做完所有的>任務為止。另一種是將任務平均分給工作者，先做完任務的工作者就去別的工作者那里拿一些任務來做，同樣直到所有任務 做完為止。兩種方式的結果如何？根據自己的場景寫碼驗證。”
memcached 所采用的模式就是這里所說的第二種! memcached 的線程分配模式是：一個主線程和多個工作線程。主線程負責初始化和將接收的請求分派給工作線程，工作線程負責接收客戶的命令請求和回復客戶。
#p#
存儲容器
memcached 是做緩存用的，內部肯定有一個容器?；氐絤ain()中，調用assoc_init()初始化了容器–hashtable，采用頭插法插入新數(shù)據，因為頭 插法是最快的。memcached 只做了一級的索引，即 hash; 接下來的就靠 memcmp() 在鏈表中找數(shù)據所在的位置。memcached 容器管理的接口主要在 item.h .c 中.
連接管理
每個連接都會建立一個連接結構體與之對應。main()中會調用conn_init()建立連接結構體數(shù)組。連接結構體 struct conn 記錄了連接套接字，讀取的數(shù)據，將要寫入的數(shù)據，libevent event 結構體以及所屬的線程信息。
當有新的連接時，主線程會被喚醒，主線程選定一個工作線程 thread0，在 thread0 的寫管道中寫入數(shù)據，特別的如果是接受新的連接而不是接受新的數(shù)據，寫入管道的數(shù)據是字符 ‘c’。工作線程因管道中有數(shù)據可讀被喚醒,thread_libevent_process()被調用，新連接套接字被注冊了 event_handler()回調函數(shù)，這些工作在conn_new()中完成。因此，客戶端有命令請求的時候(譬如發(fā)起 get key 命令)，工作線程都會被觸發(fā)調用event_handler()。
當出現(xiàn)致命錯誤或者客戶命令結束服務(quit 命令)，關于此連接的結構體內部的數(shù)據會被釋放(譬如曾經讀取的數(shù)據)，但結構體本身不釋放，等待下一次使用。如果有需要，連接結構體數(shù)組會指數(shù)自增。
一個請求的工作流程
memcached 服務一個客戶的時候，是怎么一個過程，試著去調試模擬一下。當一個客戶向 memcached 發(fā)起請求時，主線程會被喚醒，接受請求。接下來的工作在連接管理中有說到。
客戶已經與 memcached 服務器建立了連接，客戶在終端(黑框框)敲擊 get key + 回車鍵，一個請求包就發(fā)出去了。從連接管理中已經了解到所有連接套接字都會被注冊回調函數(shù)為event_handler()，因此 event_handler()會被觸發(fā)調用。
- void event_handler(const int fd，const short which，void *arg) {
- conn *c;
- c = (conn *)arg;
- assert(c != NULL);
- c->whichwhich = which;
- /* sanity */
- if (fd != c->sfd) {
- if (settings.verbose > 0)
- fprintf(stderr，"Catastrophic: event fd doesn't match conn fd!\n");
- conn_close(c);
- return;
- }
- drive_machine(c);
- /* wait for next event */
- return;
- }
event_handler()調用了drive_machine().drive_machine()是請求處理的開端，特別的當有新的連接 時，listen socket 也是有請求的，所以建立新的連接也會調用drive_machine()，這在連接管理有提到過。下面是drive_machine()函數(shù)的骨架：
- // 請求的開端。當有新的連接的時候 event_handler() 會調用此函數(shù)。
- static void drive_machine(conn *c) {
- bool stop = false;
- int sfd，flags = 1;
- socklen_t addrlen;
- struct sockaddr_storage addr;
- int nreqs = settings.reqs_per_event;
- int res;
- const char *str;
- assert(c != NULL);
- while (!stop) {
- // while 能保證一個命令被執(zhí)行完成或者異常中斷(譬如 IO 操作次數(shù)超出了一定的限制)
- switch(c->state) {
- // 正在連接，還沒有 accept
- case conn_listening:
- // 等待新的命令請求
- case conn_waiting:
- // 讀取數(shù)據
- case conn_read:
- // 嘗試解析命令
- case conn_parse_cmd :
- // 新的命令請求，只是負責轉變 conn 的狀態(tài)
- case conn_new_cmd:
- // 真正執(zhí)行命令的地方
- case conn_nread:
- // 讀取所有的數(shù)據，拋棄!!! 一般出錯的情況下會轉換到此狀態(tài)
- case conn_swallow:
- // 數(shù)據回復
- case conn_write:
- case conn_mwrite:
- // 連接結束。一般出錯或者客戶顯示結束服務的情況下回轉換到此狀態(tài)
- case conn_closing:
- }
- }
- return;
- }
通過修改連接結構體狀態(tài) struct conn.state 執(zhí)行相應的操作，從而完成一個請求，完成后 stop 會被設置為 true，一個命令只有執(zhí)行結束(無論結果如何)才會跳出這個循環(huán)。我們看到 struct conn 有好多種狀態(tài)，一個正常執(zhí)行的命令狀態(tài)的轉換是：
- conn_new_cmd->conn_waiting->conn_read->conn_parse_cmd->conn_nread->conn_mwrite->conn_close
這個過程任何一個環(huán)節(jié)出了問題都會導致狀態(tài)轉變?yōu)?conn_close。帶著剛開始的問題把從客戶連接到一個命令執(zhí)行結束的過程是怎么樣的:
客戶connect()后，memcached 服務器主線程被喚醒，接下來的調用鏈是event_handler()->drive_machine()被調用,此時主線程對應 conn 狀態(tài)為 conn_listining,接受請求
- dispatch_conn_new(sfd，conn_new_cmd，EV_READ | EV_PERSIST,DATA_BUFFER_SIZE，tcp_transport);
dispatch_conn_new()的工作是往工作線程工作隊列中添加任務(前面已經提到過)，所以其中一個沉睡的工作線程會被喚醒,thread_libevent_process()會被工作線程調用，注意這些機制都是由 libevent 提供的。
thread_libevent_process()調用conn_new()新建 struct conn 結構體，且狀態(tài)為 conn_new_cmd，其對應的就是剛才accept()的連接套接字.conn_new()最關鍵的任務是將剛才接受的套接字在 libevent 中注冊一個事件，回調函數(shù)是event_handler()。循環(huán)繼續(xù)，狀態(tài) conn_new_cmd 下的操作只是只是將 conn 的狀態(tài)轉換為 conn_waiting;
循環(huán)繼續(xù)，conn_waiting 狀態(tài)下的操作只是將 conn 狀態(tài)轉換為 conn_read，循環(huán)退出。
此后，如果客戶端不請求服務，那么主線程和工作線程都會沉睡，注意這些機制都是由 libevent 提供的。
客戶敲擊命令「get key」后，工作線程會被喚醒,event_handler()被調用了?？? 又被調用了.event_handler()->drive_machine()，此時 conn 的狀態(tài)為 conn_read。conn_read 下的操作就是讀數(shù)據了，如果讀取成功，conn 狀態(tài)被轉換為 conn_parse_cmd。
循環(huán)繼續(xù)，conn_parse_cmd 狀態(tài)下的操作就是嘗試解析命令: 可能是較為簡單的命令，就直接回復，狀態(tài)轉換為 conn_close，循環(huán)接下去就結束了; 涉及存取操作的請求會導致 conn_parse_cmd 狀態(tài)轉換為 conn_nread。
循環(huán)繼續(xù)，conn_nread 狀態(tài)下的操作是真正執(zhí)行存取命令的地方。里面的操作無非是在內存尋找數(shù)據項，返回數(shù)據。所以接下來的狀態(tài) conn_mwrite，它的操作是為客戶端回復數(shù)據。
狀態(tài)又回到了 conn_new_cmd 迎接新的請求，直到客戶命令結束服務或者發(fā)生致命錯誤。大概就是這么個過程。
#p#
memcached 的分布式
memcached 的服務器沒有向其他 memcached 服務器收發(fā)數(shù)據的功能，意即就算部署多個 memcached 服務器，他們之間也沒有任何的通信。memcached 所謂的分布式部署也是并非平時所說的分布式。所說的「分布式」是通過創(chuàng)建多個 memcached 服務器節(jié)點，在客戶端添加緩存請求分發(fā)器來實現(xiàn)的。memcached 的更多的時候限制是來自網絡 I/O，所以應該盡量減少網絡 I/O。
我在 github 上分享了 memcached 的源碼剖析注釋: 這里
