第五章事件與事務-有解無憂

　　1. 事件

　　Redis服務器是一個事件驅動程式，服務器處理以下兩類事件：

檔案事件（file event）：Redis服務器通過套接字與客戶端（或其他Redis服務器）進行連接，而檔案事件就是服務器對套接字操作的抽象，服務器與客戶端（或其他服務器）的通信會產生相應的檔案事件，而服務器則通過監聽并處理這些事件來完成一系列網路通信操作，
時間事件（time event）：Redis服務器中的一些操作（比如serverCron函式）需要在給定的時間點執行，而時間事件就是服務器對這類定時操作的抽象

　　1.1 檔案事件

　　Redis基于Reactor模式開發自己的網路事件處理器：即檔案事件處理器：

檔案事件處理器使用I/O多路復用程式來同時監聽多個套接字，并根據套接字目前執行的任務來為套接字關聯不同的事件處理器
當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時，與操作相對應的檔案事件就會產生，這時，檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件，

　　1.1.1 檔案事件處理器的構成

　　檔案事件處理器由四部分組成：

套接字
I/O多路復用程式監聽多個套接字，并向檔案事件分派器傳送那些產生了事件的套接字，盡管多個檔案事件可能會并發地出現，但I/O多路復用程式總會將所有產生事件的套接字都放到一個佇列里面，以每次一個套接字的方式向檔案事件分派器傳送套接字
檔案事件分派器接收I/O多路復用程式傳來的套接字，并根據套接字產生的事件的型別，呼叫相應的事件處理器
事件處理器服務器會為執行不同任務的套接字關聯不同的事件處理器，這些處理器是一個個函式，定義了某個事件發生時，服務器應該執行的動作

　　1.1.2 I/O 多路復用程式的實作

　　Redis在I/O多路復用程式的實作原始碼中用#include宏定義了相應的規則，程式會在編譯時自動選擇系統中性能最高的I/O多路復用函式庫來作為Redis的I/O多路復用程式的底層實作，

　　1.1.3 事件的型別

　　I/O多路復用程式可以監聽多個套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件

當套接字變得可讀時（客戶端對套接字執行write操作，或者執行close操作），或者有新的可應答（acceptable）套接字出現時（客戶端對服務器的監聽套接字執行connect操作），套接字產生AE_READABLE事件
當套接字變得可寫時（客戶端對套接字執行read操作），套接字產生AE_WRITABLE事件

　　1.1.4 API

　　ae.c/aeCreateFileEvent函式接受一個套接字描述符、一個事件型別，以及一個事件處理器作為引數，將給定套接字的給定事件加入到I/O多路復用程式的監聽范圍之內，并對事件和事件處理器進行關聯

　　ae.c/aeWait函式接受一個套接字描述符、一個事件型別和一個毫秒為引數，在給定的時間內阻塞并等待套接字的給定型別事件產生，當事件成功產生，或者等待超時之后，函式回傳

　　ae.c/aeApiPoll函式接受一個sys/time.h/struct timeval結構為引數，并在指定時間內，阻塞并等待所有被aeCreateFileEvent函式設定為監聽狀態的套接字產生檔案事件，當至少一個事件產生，或者等待超時后，函式回傳

　　ae.c/aeProcessEvents函式是檔案事件分派器，先呼叫aeApiPoll函式來等待時間產生，然后遍歷所有已產生的事件，并呼叫相應的事件處理器來處理這些事件

　　ae.c/aeGetApiName函式回傳I/O多路復用程式底層所使用的的I/O多路復用函式庫的名稱：回傳“epoll”表示底層為epoll函式庫

　　1.1.5 檔案事件處理器

　　Redis為事件撰寫了多個處理器，這些事件處理器分別用于實作不同的網路通信需求：

為了對連接服務器的各個客戶端進行應答，服務器要為監聽套接字關聯連接應答處理器（networking.c/acceptTcpHandler函式）

為了接收客戶端傳來的命令請求，服務器要為客戶端套接字關聯命令請求處理器（networking.c/readQueryFromClient函式）

為了向客戶端回傳命令的執行結果，服務器要為客戶端套接字關聯命令回復處理器（networking.c/sendReplyToClient函式）

當主服務器和從服務器進行復制操作時，主從服務器都需要關聯特別為復制功能撰寫的復制處理器

　　完整的客戶端和服務器連接示例：

　　1.2 時間事件

　　Redis時間事件分為兩類：

定時事件：一段程式在指定的時間之后執行一次
周期性事件：一段程式每隔指定時間就執行一次

　　時間事件由三個屬性組成：

id：服務器為時間事件創建的全域唯一ID，ID號沿從小到大依次遞增
when：毫秒精度的UNIX時間戳，記錄了時間事件的到達時間
timeProc：時間事件處理器，當時間到達時，服務器就會呼叫相應的處理器來處理事件

　　1.2.1 實作

　　服務器將所有的時間事件都放在一個無序鏈表中，每當時間事件執行器運行時，就會遍歷整個鏈表，查找所有已到達的時間事件，并呼叫相應的事件處理器，

　　1.2.2 API

　　ae.c/aeCreateTimeEvent函式接受一個毫秒數milliseconds和一個時間事件處理器proc作為引數，將一個新的時間事件添加到服務器，

　　ae.c/aeSearchNearesTimer函式回傳到達時間距離當前時間最接近的那個時間事件，

　　ae.c/processTimeEvents函式是時間事件的執行器，這個函式遍歷所有時間事件，并呼叫事件處理器來處理那些已到達的時間事件，

　　1.2.3 時間事件應用實體：serverCron函式

　　持續運行的redis服務器需要定期對自身的資源和狀態進行檢查和調整，這些定期操作由redis.c/serverCron函式負責執行，主要作業包括：

更新服務器的各類統計資訊，比如時間、記憶體占用、資料庫占用情況等
清理資料庫中的過期鍵值對
關閉和清理連接失效的客戶端
嘗試進行AOF或RDB持久化操作
如果服務器是主服務器，那么對從服務器進行定期同步
如果處于集群模式，對集群進行定期同步和連接測驗

　　1.3 事件的調度和執行

　　2. 事務

　　Redis通過MULTI、EXEC、WATCH等命令來實作事務功能，

　　2.1 事務的實作

　　1）事務開始在客戶端狀態的flags屬性中打開REDIS_MULTI標識，

　　2）命令入隊

　　3）執行事務　　

def  EXEC():
        #  創建空白的回復佇列
        reply_queue = []
        
        #  遍歷事務佇列中的每個項
        #  讀取命令的引數，引數的個數，以及要執行的命令
        for argv, argc, cmd, in client.mstate.commands:

                    # 執行命令，并取得命令回傳值
                    reply = execute_command(cmd, argv, argc)
                    
                    # 將回傳值追加到回復佇列末尾
                    reply_queue.append(reply)

        # 移除REDIS_MULTI 標識，讓客戶端回到非事務狀態
        client.flags &= ~REDIS_MULTI

        # 清空客戶端的事務狀態，包括：
        # 1）清零入隊命令計數器
        # 2）釋放事務佇列

        client.msatate.count = 0
        release_transaction_queue(client.mastate.commands)

        # 將事務的執行結果回傳給客戶端
        send_reply_to_client(client, reply_queue)

　　2.2 WATCH命令實作

　　WATCH命令是一個樂觀鎖（optimistic locking），在EXEC命令執行之前，監視任意數量的資料庫鍵，并在EXEC命令執行時，檢查被監視的鍵是否至少有一個已經被修改過，如果是的話，服務器將拒絕執行事務，并向客戶端回傳代表事務執行失敗的慷訓復，

　　假設當前客戶端為A，而資料庫watched_keys字典的監視了“name”鍵，那么當客戶端A執行SET name命令后，客戶端B也向服務器發送了一條SET命令，將“name”的值設為“John”，客戶端B的這個SET命令會導致正在監視“name”鍵的所有客戶端的REDIS_DIRTY_CAS標識被打開，其中包括客戶端A，之后，當c10086向服務器發送EXEC命令時，因為客戶端A的REDIS_DIRTY_CAS標志已經被打開，所以服務器將拒絕執行它提交的事務，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296143.html

標籤：其他

上一篇：第四章 RDB持久化和AOF持久化

下一篇：第六章客戶端與服務器

第五章 事件與事務

1. 事件

2. 事務

第五章事件與事務

　　1. 事件

　　2. 事務