Redis Events and transactions

First, Redis characteristicsFeatures: Fast, key-value based data structure server, rich, simple and stable, client language multiple, persistent, master-slave replication, support high-availability and distributed single-threaded Architecture: Redis uses single-threaded architecture and I/O multiplexing model to achieve high-performance memory database services. A command is not executed immediately from the client to the server, and all commands are entered into a queue and executed individually. (The execution order is indeterminate).

How a single thread can meet the speed of an online operation.  Pure Memory Access: All data is placed in memory and is approximately 100 nanoseconds long in response. non-blocking I/O, using Epoll as an I/O multiplexing technology, plus Redis's own event-handling model converts connections, reads and turns in poll to events, and does not waste much time on network I/O. Single-threaded avoids the consumption of thread switching and race state generation. Ii. Events

The Redis server is an event driver. Handle the following two types of events: File events: The Redis server connects to the client through sockets, and the file event is the server's abstraction of the socket operation. Time Event: The abstraction of a server to a timed operation. 1. File Events

Redis develops its own network event processor, the file event processor, based on the reactor model

The file event handler uses an I/O multiplexing program to listen for multiple sockets at the same time, and associates different transaction processors for sockets based on the tasks currently performed by the socket.

When a listening socket is ready to perform a connection response, read, write, close, and so on, the file event that corresponds to the operation is generated, and the file event handler invokes the event handler associated with the socket before it handles the event.

The file event handler consists of four parts: sockets, I/O multiplexing, file event dispatcher, and event processor I/O multiplexing programs always place all generated sockets in a queue, and then through this queue to order, synchronize, Sends a socket to the file event dispatcher each time a socket is sent. The I/O multiplexer will continue to transmit the next socket to the file event dispatcher after the event that the previous socket generated has been processed.

I/O multiplexing programs are implemented by wrapping the I/O multiplexing Library of common Select, Epoll, Evport, and Kqueue functions. 2. Time Event Classification timed event: Specify time to execute once. Recurring event: Executes once at intervals.

Currently, Redis only uses periodic events instead of timed events. An event time consists primarily of three attributes:

1 ID: The globally unique ID created by the server for the time event

2 When: Millisecond precision Unix timestamp, record time event arrival time

3 Timeproc: Time event handler, a function implementation server put all time events in a unordered list, and whenever the time event executor runs, traverse the entire list, find all the time events that have arrived, and invoke the appropriate event handler. (The list is unordered list, not sorted by the size of the When property) Redis transaction

Redis through the MULTI, EXEC, WATCH and other commands to achieve transaction functions. Transactions provide a way to package multiple command requests, then the mechanism of executing multiple commands at once, sequentially, and during the execution of a transaction, the server does not break the transaction and instead executes the command request of the other client, which completes all the commands in the transaction before processing the command requests of the other clients. 1. Implementation of the transaction

A simple example of a transaction is given below:

127.0.0.1:6379> Multi
OK
127.0.0.1:6379> Set "name" "Wangjia06"
QUEUED
127.0.0.1:6379> get ' Name '
QUEUED
127.0.0.1:6379> set ' company ' ' dianping '
QUEUED
127.0.0.1:6379> get ' company '
QUEUED
127.0.0.1:6379> set
QUEUED 127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) "Wangjia06"
3 OK
4) "Dianping"
5) OK
6) "28"

Exiting a transaction can be done with the MULTI command, at which point the transaction will have an error:

127.0.0.1:6379> Multi
OK
127.0.0.1:6379> get ' company '
QUEUED
127.0.0.1:6379> get ' age "
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> exec
(error) ERR exec without MULTI

A transaction consists of three steps: Transaction start: Transaction starts with MULTI, returns OK command. Command team: Returns QUEUED after each transaction command successfully enters the queue. Transaction execution: EXEC executes a transaction.

Two kinds of errors are encountered within the Redis transaction: The team is unsuccessful in the team: grammatical errors, incorrect command names, or some important conditions such as oom conditions. This kind of client will check, if the team succeeds then return queued, otherwise return an error. If a command fails to join the queue, most clients terminate the transaction.

127.0.0.1:6379> Get name
"wangjia08"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name " Wangjia09 "
QUEUED
127.0.0.1:6379> get
(Error) ERR wrong number of arguments for ' get ' command
127.0.0.1:6379> Get name
QUEUED
127.0.0.1:6379> exec
(error) Execabort Transaction discarded Because of previous errors.
127.0.0.1:6379>

Command execution times error: A list operation is performed on a string value. All other commands will be executed normally even if some commands fail in the execution of the transaction.

127.0.0.1:6379> Multi
OK
127.0.0.1:6379> set sex man
QUEUED
127.0.0.1:6379> lpop Sex
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) Wrongtype Operation against a key holding the wrong k IND of value
127.0.0.1:6379> get sex
"mans"
127.0.0.1:6379>

Redis does not support transaction rollback functionality for about two reasons: a Redis command fails, typically a syntax error or should be detected in the development phase, rather than in a production environment. Redis pursuit of simple, fast, so do not provide transaction rollback function. implementation of the 2.WATCH command

The Watch command provides a CAS feature for redis transactions. It is an optimistic lock that checks if at least one of the monitored health has been modified, refuses to execute if it is, and returns nil on behalf of the failed execution.

As in the following example, the key "name" is monitored before a client opens the transaction, and if the other client modifies the value of the key "name" before the transaction is executed, the transaction is reported nil.

127.0.0.1:6379> Watch "name"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set
age QUEUED
127.0.0.1:6379> Get "name"
QUEUED
127.0.0.1:6379> exec
(nil)

127.0.0.1:6379> Set "name" "Wangjia08"
OK

Watch command to monitor multiple keys:

127.0.0.1:6379> Watch ' name ' ' age '
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> get ' Name '
QUEUED
127.0.0.1:6379> get ' age '
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379>

127.0.0.1:6379> set "Age" all
OK

3. The acid nature of the transaction Atomicity: Redis transactions are performed as a whole, either by executing all operations in a transaction or by not executing one. Consistency: "Consistent" means that the data conforms to the definition and requirements of the database itself and does not contain illegal or invalid error data join errors: The server refuses to perform the transaction. Execution error: The command to make an error is identified by the server, and the appropriate error handling is not made any changes to the database, nor does it affect data consistency. Server downtime: rdb ,  AOF  restoring database state isolation: single-threaded execution of transactions, and the server guarantees that transactions do not break persistence during a transaction: When a transaction completes, The result of executing this transaction has been saved to a permanent storage medium (such as a hard drive). The persistence of Redis transactions is determined by the persistence mode used by Redis (no persistence mode,  RDB ,  AOF ). Redis the transaction does not persist in the absence of persistence mode. When  appenfsync  is  no  in  AOF  mode, the transaction is not persistent