Redis source code analysis (17) --- multi transaction operations

As a non-relational database, redis has the same transaction operations with RDBMS, which surprised me. A dedicated file in redis is used to perform transaction-related operations. We can also learn how to implement transaction operations in Redis code. First, some apis under mulic. c are displayed. *

As a non-relational database, redis has the same transaction operations with RDBMS, which surprised me. A dedicated file in redis is used to perform transaction-related operations. We can also learn how to implement transaction operations in Redis code. First, some apis under mulic. c are displayed. /* ======================================

As a non-relational database, redis has the same transaction operations with RDBMS, which surprised me. A dedicated file in redis is used to perform transaction-related operations. We can also learn how to implement transaction operations in Redis code. First, some apis under mulic. c are displayed.

/* ==================================== MULTI/EXEC ==== =========================*/void initClientMultiState (redisClient * c) /* initialize the client operation */void freeClientMultiState (redisClient * c)/* release all client resources related to multi/exec */void queueMultiCommand (redisClient * c) /* Add a new command to the multi command queue of the client */void discardTransaction (redisClient * c)/* cancel transaction operation */void flagTransaction (redisClient * c) /* indicates that a transaction is in the DIRTY_EXEC state and the execution fails. This method is called when the command is inserted */void multiCommand (redisClient * c) /* Add the multi command */void discardCommand (redisClient * c)/* undo command */void execCommandPropagateMulti (redisClient * c) /* Send the multi Command to all slave clients and aof files */void execCommand (redisClient * c)/* run the Command on a single client */void watchForKey (redisClient * c, robj * key)/* Add a key listener to the client */void unwatchAllKeys (redisClient * c)/* remove all keys from the client */void touchWatchedKey (redisDb * db, robj * key) /* indicates that the key is being monitored, and the next operation will fail. */void touchWatchedKeysOnFlush (int dbid)/* indicates the database where the key is located, touch all the watched-keys in this db */void watchCommand (redisClient * c)/* watch key command method, use parameters in the client to pass the value */void unwatchCommand (redisClient * c)/* cancel the command Method for listening to keys */

There are not many methods, but there is a frequently used word "key" in it ". This key does play a key role here. The muli code mainly contains commands, execution commands, and undo commands, such as the following undo transaction operations.

/* Cancel the transaction */void discardTransaction (redisClient * c) {freeClientMultiState (c); initClientMultiState (c); c-> flags & = ~ (REDIS_MULTI | REDIS_DIRTY_CAS | REDIS_DIRTY_EXEC); // The client cancels listening for all keys unwatchAllKeys (c );}

There is an unwatchAllKeys () method. The following are the key principles of transaction operations:

/* In transaction processing, there are two mapping types: key --> client lists, which indicates that all the clients in the list are listening for this key. When the value of this key changes, it can mark these clients as DIRTY States and need to be updated. At the same time, a key of list is maintained inside the Client, indicating all keys monitored by a Client. When the Client has a free operation, update the list of clients maintained in the key */

/* Indicates that the key is being monitored, and the next operation will fail */

That is to say, if the client is listening for the key, its next command will fail to be executed, achieving the synchronization effect,

/* "Touch" a key, so that if this key is being WATCHed by some client the * next EXEC will fail. * // * indicates that the key is being monitored, and the next operation will fail */void touchWatchedKey (redisDb * db, robj * key) {list * clients; listIter li; listNode * ln; if (dictSize (db-> watched_keys) = 0) return; clients = dictFetchValue (db-> watched_keys, key); if (! Clients) return;/* Mark all the clients watching this key as REDIS_DIRTY_CAS * // * Check if we are already watching for this key */listRewind (clients, & li ); while (ln = listNext (& li) {redisClient * c = listNodeValue (ln); // traverses the Client owned by the key, mark flag as DIRTY_CAS status c-> flags | = REDIS_DIRTY_CAS ;}}

When the Client tries to use the touch method to listen to the key, the flag status of the Client is changed to DIRTY_CAS. I cannot help but guess that the synchronous method is to use the CAS algorithm, if many clients use this algorithm, the CPU usage is indeed high. In general, the key maintains a Client list, and a Client also has a list of all its watch keys. The structure of the key is very simple:

/* Defines the watchedKey struct */typedef struct watchedKey {robj * key; redisDb * db;} watchedKey;

The key contains the database to which it belongs. Therefore, if you just undo the transaction, you need to remove all the keys listened by the client.