Redis Document parsing

1. Replication 1,redis uses asynchronous replication. 2, the feature does not block the primary server: even if one or more of the initial synchronizations are in progress from the server, the primary server can continue to process command requests. Principle:  Whether it is the initial connection or reconnection, when a slave server is established, a SYNC command is sent from the server to the primary server. The master server that receives the SYNC command will begin executing BGSAVE and will save all newly executed write commands to a buffer during the save operation execution. When the BGSAVE finishes executing, the master server sends the. rdb file that the save operation sends to the slave server, receives the. rdb file from the server, and loads the data in the file into memory. The master server then sends all the content accumulated in the Write command buffer to the slave server in the format of the Redis command protocol. You can verify the synchronization process yourself by using the telnet command: first connect to the Redis server that is processing the command request, and then send it the Sync command, and after a while you will see that the Telnet session (session) received a large segment of data (. rdb file) from the server , you will then see that all the write commands that were executed by the server are resent to the Telnet session. Even if multiple slave servers are sending sync to the primary server, the primary server can handle all of these synchronization requests from the server by simply executing the BGSAVE command once. After a temporary failure of the network connection, the master-slave server can attempt to continue with the original replication process (process) without necessarily performing a full resynchronization operation. This feature requires the primary server to create a memory buffer (in-memory backlog) for the sent replication stream, and a copy offset (replication offset) and a primary server ID (master run) are recorded between the primary server and all slave servers ID), when a network connection disconnects, the slave server is reconnected and requests to the primary server to continue with the original replication process:

　　

2. Communication protocol 1, the Network layer client and server through the TCP connection for data interaction, the server default port number is 6379. The commands or data sent by the client and the server are all terminated by \ r \ n (CRLF). 2, the first byte of the reply-to-Status reply (status Reply) is "+" the first byte of the error response (Error reply) is "-" the first byte of an integer reply (integer reply) is ":" The first byte of the bulk reply (bulk Reply) is "$" The first byte of a multiple bulk reply (multi bulk Reply) is "*"

　　

3. Transaction multi, EXEC, DISCARD, and WATCH are the underlying transactions of the Redis transaction is a separate quarantine operation: All commands in the transaction are serialized and executed sequentially. The transaction is not interrupted by a command request sent by another client during execution. A transaction is an atomic operation: the commands in a transaction are either all executed or none of them are executed. The 1.MULTIMULTI command is used to open a transaction, and it always returns OK. After the MULTI executes, the client can continue to send any number of commands to the server, which are not executed immediately, but are placed in a queue and all commands in the queue are executed when the EXEC command is called. On the other hand, by calling DISCARD, the client can empty the transaction queue and discard the execution transaction. multiok> INCR fooqueued> INCR barqueued> EXEC1) (integer) 1 The other commands in the transaction queue continue to execute even if some/some of the commands in the transaction fail to execute- -redis does not stop executing commands in a transaction. Redis does not roll back when the transaction fails, but continues to execute the remaining command 2. DISCARD when the DISCARD command is executed, the transaction is discarded, the transaction queue is emptied, and the client exits from the transaction state:redis> SET foo 1okredis> multiokredis> INCR fooqueuedre dis> discardokredis> GET foo "1" 3.WATCH the watch key will be monitored and will notice if the keys have been altered. If at least one of the monitored keys has been modified before exec executes, the entire transaction is canceled, and EXEC returns an empty number of bulk replies (null Multi-bulk reply) to indicate that the transaction has failed.

　　

Redis Document parsing