redis啟動流程（一）

閱讀思路

閱讀原始碼的時候應該抓住主幹，然後再去各個分支詳細分析（個人鄙見）。所以我個人認為redis的啟動流程應該是這套原始碼的主幹，所以我先從啟動流程下手。對於分析我大致講個原理，具體詳細註釋請參照我提交的註釋版redis,我在文章中就不再貼原始碼逐行解釋了。

從自己的知識積累出發，先自己預想了下，作為一個服務該有的啟動流程。

讀取配置->初始化引數->開始網路監聽->不斷處理網路任務

原始碼分析

首先查詢redis的main函式，不難查詢，我們在redis.c這個檔案中找到了main函式。

我們這裡列出main函式裡面主要的幾個函式，以下所列函式是按它們在main函式裡面的執行順序。（我們主要分析的是普通節點，哨兵節點的邏輯不在範圍內）

//--打散argv和environ所儲存內容的空間
spt_init(argc, argv);
//--主要在初始化全域性的server物件中的各個資料成員
initServerConfig();
//--繼續初始化全域性的server物件，並在裡面初始化了全域性的shared物件
//--監聽埠和uinx socket檔案
//--啟動bio執行緒
//--lua環境
initServer();
//--檢查系統的THP和overcommit_memory
linuxMemoryWarnings();
//--檢查tcp_backlog和系統的somaxconn引數值
checkTcpBacklogSettings();
//--根據RDB或者AOF檔案載入舊資料，優先AOF檔案
loadDataFromDisk();
//--進入事件迴圈處理
aeMain(server.el);

函式分析

• spt_init()

  redis一開始就把agrv所儲存的物件都打散開，是為了後面修改程式名字做鋪墊，那為什麼改個程式名要這 樣大費周折呢，那是因為agrv是連續儲存的。具體一些知識點我網上找了個資料可以參考下。

  http://blog.csdn.net/hengshan/article/details/7835981

• linuxMemoryWarnings()

  redis啟動前檢測當前系統環境對於記憶體申請的策略，主要是檢查系統裡面的/proc/sys/vm/overcommit_memory的檔案內容，裡面的取值

  0 -> 申請的虛擬記憶體大小大於現有的實體記憶體時，返回失敗

  1 -> 忽視現有的實體記憶體，立即分配虛擬記憶體，當觸發缺頁而實體記憶體不足時可能會被oom程式殺死

  2 -> 每次申請都根據現有的實體記憶體計算出一個閾值，然後跟這個閾值做比較來判斷是否允許本次申請

  參考資料：http://blog.chinaunix.net/uid-20671208-id-4440244.html

  當取到的值為0時，redis會打出警告資訊。

• checkTcpBacklogSettings()

  redis啟動前進行埠的監聽佇列的長度檢查，通過檢查系統的/proc/sys/net/core/somaxconn檔案的內容，對於監聽佇列的長度redis預設是511,由這個值REDIS_TCP_BACKLOG來定義。當取到的值小於server.tcp_backlog，redis會列印出警告資訊。

  參考資料：http://blog.csdn.net/taolinke/article/details/6800979

以上幾個函式我覺得有一些系統知識點的我羅列出來，具體邏輯還是要詳見文章開頭的原始碼，後面重點講講 initServer()和aeMain()這兩個函式，我認為是整個啟動流程的重點。