Publish and subscribe Redis provides a one-to-many or many-to-many node message communication through a publish subscription consisting of commands such as publish, SUBSCRIBE, Psubscribe, PubSub, and so on.
- Subscribe command: Subscribe to a channel, in the redisserver structure through the Pubsub_channels dictionary property to save the current server all channels of the subscription relationship, dictionary key when the channel name, the dictionary value is a linked list, recorded all subscribed to this channel client.
- Unsubscribe command: Unsubscribe from the channel, after invoking the command, the subscription relationship will be deleted from the pubsub_channels, if the key corresponding to the list is empty, the key is removed from the dictionary.
- Psubscribe command: Subscription mode, the server saves all schema subscription relationships in the Pubsub_patterns attribute of the redisserver structure, which is a linked list, each linked list node contains a pubsubpattern structure, The structure records the subscribed mode and the client that subscribes to the pattern.
- Punsubscribe command: Unsubscribe mode, after invoking the command, the server will traverse the pubsub_patterns linked list, the client and the pattern matching the node to delete.
- Publish command: Send a subscription message, after the server receives the command, the first traversal Pubsub_channels find the channel subscribers, send the message to all channel subscribers, and then traverse Pubsub_patterns to find the channel matching mode, and sends messages to clients subscribed to these patterns.
- PubSub command, view subscription information contains the following three subcommands:
- PUBSUB channles [pattern]: Returns the channel to which the current server is subscribed, as specified by pattern, and returns the channel that matches the mode
- PUBSUB numsub [Channel-1 ... channel-n]: Returns the number of subscribers to the specified channel
- PUBSUB Numpat: Returns the number of currently subscribed modes of the server
Redis implements transactional functionality through commands such as multi, EXEC, watch, and so on, enabling multiple commands to be packaged and executed in a single order. The transaction begins with the Multi command, and the EXEC command ends. The command executed after executing the MULTI command does not execute immediately, but instead returns a queued to the client, which executes after the EXEC command is executed.
Implementation transaction start of transaction
After executing the multi command, the server switches the client from a non-transactional state to a transactional state, and opens the Redis_multi identity by setting the flags identifier of the redisclient.
command to queue
When the client is in a non-transactional state, the command sent by the client executes immediately when it is in a transactional state:
If the client sends a command that is exec, DISCARD, WATCH, and multi, the server executes immediately.
If the command sent by the client is another command, the server does not execute the command immediately, but instead puts the command into the transaction queue and returns queued to the client.
There is a property of multistate structure in Redisclient mstate records the transaction state of the client, there is a commands list property in the multistate structure, it records the command that the client queued after the call to multi, The Count property records the number of queued commands. The MULTICMD Structure Record command implements the function pointer, the parameter of the command, the number of parameters already. The transaction queue saves the queued command in a FIFO manner, and the queued command executes first.
Execution transactions
Executes the EXEC command to commit the transaction after the server receives the command:
- Iterate through the client.mstate.commands, get the queued commands and execute them all, adding the return value of the command to the tail of the reply queue.
- Clears the client's transaction state, including clearing 0 of the Queued command counter, releasing the transaction queue.
- Returns the execution result to the client.
The watch command implementation of the Watch command is an optimistic lock that monitors the established database keys before exec executes, checks to see if at least one of the monitored keys has been modified while executing the EXEC command, and if so, the server rejects the command and returns a null reply to the client that failed to execute on the transaction.
The REDISDB structure of the Redis database holds a Watched_keys dictionary, the keys of a dictionary are monitored by the Watch command, the value is a linked list, and all the clients that monitor the corresponding database keys are recorded in the list.
When you execute a command that modifies the database, the Multi.c/touchwatchkey function is called after execution to check the Watched_keys dictionary to see if any clients are monitoring the database keys that have just been modified by the command, and if so, The Touchwatchkey function opens the Redis_dirty_cas identity of the client that monitors the modified key, indicating that the client's transaction security has been compromised. When the server receives an EXEC command from a client, the server decides whether to execute the transaction based on whether the client has opened the Redis_dirty_cas identity.
Acid atomicity of a transaction: for REDIS transactions, multiple commands in a transaction are treated as a whole, the commands in the transaction queue are either all executed or not executed, and Redis transactions are atomic, but the Redis transaction supports rollback. The entire transaction continues to execute even if an error occurs in the execution of a command in the queue and does not affect subsequent commands.
Consistency: The database consistency is not affected when the command is queued for errors, execution errors, and server downtime. PS: When a queue error occurs, the transaction will continue to execute before 2.6.5, and after 2.6.5, the transactions will be rejected.
Isolation: Redis transactions are not interrupted by other commands, run serially, and Redis transactions are isolated
Durability:
- When the server is running in memory mode without persistence, the transaction is not persistent: once the server is down, all the data will be lost
- When the server is running in RDB persistence mode, data is lost for a period of time when the server is down and the transaction is not persistent
- When the server is running in aof persistence mode, and the Appendsync option value is always, the data is saved to the hard disk in a timely manner, when the transaction is persistent (provided that the No-appendfsync-on-rewrite option is not turned on, and after the option is turned on, To minimize IO operations, when the server executes Bgsave or bgrewriteaof, the AoF file synchronization is stopped, so the transaction is not persisted at this time)
- When the server is running in aof persistence mode, and the Appendsync option value is everysec, you may lose 1 seconds of data at which time the transaction is not persisted
- When the server is running in aof persistence mode, and the Appendsync option value is no, the data is lost when the server is down, and the transaction is not persistent
Redis design and Implementation Learning notes-publishing subscriptions and transactions
