Redis訊號處理

2021-09-20 22:01:29 字數 995 閱讀 4292

本文件提供的資訊是有關redis是如何應對不同posix系統下產生的訊號異常,比如sigterm,sigse**等等。

本文件中的資訊只適用於redis2.6或更高版本

sigterm訊號會讓redis安全的關閉。redis收到訊號時並不立即退出,而是開啟乙個定時任務,這個任務就類似執行一次shutdown命令的。 這個定時關閉任務會在當前執行命令終止後立即施行,因此通常有有0.1秒或更少時間延遲。

萬一server被乙個耗時的lua指令碼阻塞,如果這個指令碼可以被script kill命令終止,那麼定時執行任務就會在指令碼被終止後立即執行,否則直接執行。

這種情況下的shutdown過程也會同時包含以下的操作:

萬一rdb檔案儲存失敗,shutdown失敗,server則會繼續執行以保證沒有資料丟失。自從redis2.6.11之後,redis不會再次主動shutdown,除非它接收到了另乙個sigterm訊號或者另外乙個shutdown命令

redis接收到以下幾種訊號時會崩潰:

如果以上訊號**獲,redis會終止所有正在進行的操作,並進行以下操作:

當乙個正在進行aof重寫的子程序被訊號終止,redis會把它當成乙個錯誤並丟棄這個aof檔案(可能是部分或者完全損壞)。aof重寫過程會在以後被重新觸發。

當乙個正在執行rdb檔案儲存的子程序被終止redis會把它當做乙個嚴重的錯誤,因為aof重寫只會導致aof檔案冗餘,但是rdb檔案儲存失敗會導致redis不可用。

如果乙個正在儲存rdb檔案的子程序被訊號終止或者自身出現了錯誤(非0退出碼),redis會進入一種特殊的錯誤狀態,不允許任何寫操作。

此錯誤狀態只需被清楚一次就可以進行成功建立資料庫檔案。

但是有時使用者希望可以在不觸發錯誤的情況下終止儲存rdb檔案的子程序。自從redis2.6.10之後就可以使用訊號sigusr1,這個訊號會被特殊處理:它會像其他訊號一樣終止子程序,但是父程序不會檢測到這個嚴重的錯誤,照常接收所有的使用者寫請求。

訊號處理,訊號佇列

最近幾天在看訊號,對實時訊號的實時性不是很理解,今天看了下 dequeue signal 差不多理解了,乙個實時訊號可以有多個實時佇列,在signal集合裡乙個signal可能有多個signal佇列。訊號,有訊號佇列,有訊號集 sigpending是訊號pending的結構體,裡面有sigqueue...

Linux程序訊號 訊號處理

一 訊號相關概念 1.實際執行訊號的處理動作稱為訊號遞達 delivery 2.訊號從產生到遞達之間的狀態稱為訊號未決 pending 不一定會立即delivery 3.程序可以選擇阻塞 block 某個訊號。不會遞達 4.被阻塞的訊號產生時將保持在未決狀態,知道程序解除對此訊號 的阻塞,才會執行遞...

訊號 訊號處理函式(捕捉)

要明白訊號處理函式的使用,就要先知道訊號的捕捉設定,什麼時候會呼叫訊號處理函式和其執行的流程是什麼,下圖完整的展示了訊號捕捉的設定,以及訊號處理函式的觸發機制 所以,從上圖可以知道,只有當程式中斷,異常或系統呼叫,才會進入核心態,也只有進入了核心態才能處理訊號,在這裡初學者常常有乙個誤區,他們會覺得...