redis的事務較簡單,并不具備事務的acid的全部特征。主要原因之一是redis事務中的命令并不是立即執行的,會一直排隊到發布exec命令才執行所有的命令;另一個主要原因是它不支持回滾,事務中的命令可以部分成功,部分失敗,命令失敗時跟不在事務上下文執行時
redis的事務較簡單,并不具備事務的acid的全部特征。主要原因之一是redis事務中的命令并不是立即執行的,會一直排隊到發布exec命令才執行所有的命令;另一個主要原因是它不支持回滾,事務中的命令可以部分成功,部分失敗,命令失敗時跟不在事務上下文執行時返回的信息類似。不知道在未來會不會提供更好的支持。
我們且來看看現在redis事務的實現。
redis中跟事務相關的主要結構如下所示。每個redisClient的multiState保存了事務上下文要執行的命令。
/* Client MULTI/EXEC state */ typedef struct multiCmd { robj **argv; int argc; struct redisCommand *cmd; } multiCmd; typedef struct multiState { multiCmd *commands; /* Array of MULTI commands */ int count; /* Total number of MULTI commands */ } multiState; typedef struct redisClient { --- multiState mstate; /* MULTI/EXEC state */ --- } redisClient;
client通過發布multi命令進入事務上下文。處于事務上下文的client會設置REDIS_MULTI標志,multi命令會立即返回。
static void multiCommand(redisClient *c) { c->flags |= REDIS_MULTI; addReply(c,shared.ok); }
處于事務上下文中的client會將在exec命令前發布的命令排隊到mstate,并不立即執行相應命令且立即返回 shared.queued(如果之前參數檢查不正確,則會返回出錯信息,那就不會排隊到mstate中),這在processCommand函數中反映出來(對processCommand的詳細解釋可參看前面命令處理章節)。queueMultiCommand只是簡單的擴大mstate數組,并將當前命令加入其中。
static int processCommand(redisClient *c) { --- /* Exec the command */ if (c->flags & REDIS_MULTI && cmd->proc != execCommand && cmd->proc != discardCommand) { queueMultiCommand(c,cmd); addReply(c,shared.queued); } else { if (server.vm_enabled && server.vm_max_threads > 0 && blockClientOnSwappedKeys(c,cmd)) return 1; call(c,cmd); } --- }
當client發布exec命令時,則redis會調用execCommand來執行事務上下文中的命令集合。注意,在此之前,redis會使用execBlockClientOnSwappedKeys提前加載其命令集所需的key(該函數最終是調用前面介紹過的 waitForMultipleSwappedKeys來加載key)。因為這在命令表cmdTable是這樣設置的:
{"exec",execCommand,1,REDIS_CMD_INLINE|REDIS_CMD_DENYOOM,execBlockClientOnSwappedKeys,0,0,0},
execCommand會檢查是不是處于事務上下文,然后使用execCommandReplicateMulti向 slave/monitor/aof(前提是使用這些功能)發送/寫入multi命令字,因為multi命令本身沒有排隊,而execCommand會在執行完后寫入exec命令的,必須讓exec和multi命令配對,這之后就是調用call依次執行每個命令了。從這里沒有檢查call的返回就可以看出,如果命令執行失敗了,只能由call命令本身返回出錯信息,這里并不檢查命令執行的成功與否,最后就是清空mstate中的命令字并取消 REDIS_MULTI狀態了。
static void execCommand(redisClient *c) { int j; robj **orig_argv; int orig_argc; if (!(c->flags & REDIS_MULTI)) { addReplySds(c,sdsnew("-ERR EXEC without MULTI\r\n")); return; } /* Replicate a MULTI request now that we are sure the block is executed. * This way we'll deliver the MULTI/..../EXEC block as a whole and * both the AOF and the replication link will have the same consistency * and atomicity guarantees. */ execCommandReplicateMulti(c); /* Exec all the queued commands */ orig_argv = c->argv; orig_argc = c->argc; addReplySds(c,sdscatprintf(sdsempty(),"*%d\r\n",c->mstate.count)); for (j = 0; j < c->mstate.count; j++) { c->argc = c->mstate.commands[j].argc; c->argv = c->mstate.commands[j].argv; call(c,c->mstate.commands[j].cmd); } c->argv = orig_argv; c->argc = orig_argc; freeClientMultiState(c); initClientMultiState(c); c->flags &= (~REDIS_MULTI); /* Make sure the EXEC command is always replicated / AOF, since we * always send the MULTI command (we can't know beforehand if the * next operations will contain at least a modification to the DB). */ server.dirty++; }
最后稍微提一下,如果事務上下文執行過程中,redis突然down掉,也就是最后的exec命令沒有寫入,此時會讓 slave/monitor/aof處于不正確的狀態。redis會在重啟后會檢查到這一情況,這是在loadAppendOnlyFile中完成的。當然這一檢測執行的前提是down掉前和重啟后都使用aof進行持久化。redis在檢測到這一情況后,會退出程序。用戶可調用用redis-check- aof工具進行修復。
原文地址:redis源代碼分析21– 事務, 感謝原作者分享。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com