Redis transactions and master-slave replication (notes)

I. Redis Services

you can execute multiple commands at once, essentially a set of commands. All commands in a transaction are serialized and sequentially executed in sequential order without being inserted by other commands and stoppering.

Transaction command:
Discard Cancel Transaction

EXEC executes commands within a transaction block

Multi marks the beginning of a transaction

Unwatch cancels the watch command for all key controls

Watch monitors one or more keys, and if the keys are changed by other commands before the transaction is executed, the transaction is interrupted

After marking the start of a transaction, if one of the commands inserts a queue error, all commands in the transaction are not executed.
If a transaction obtains a nonexistent value, executing exec and returning nil does not affect the execution of other commands in the transaction.

pessimistic locks pessimistic lock
Very pessimistic, every time the data are thought that others will be modified, so every time you get the data will be locked. The traditional relational database used a lot of this lock mechanism, such as row lock, table lock, read lock, write lock, etc., are locked before operation.

optimistic locking optmistic lock
Very optimistic, every time to take the data are not modified, so it will not be locked, but in the update will judge whether someone has updated this data, you can use the version number and other mechanisms, optimistic lock more application type, can improve throughput.

Once the exec is executed, the previously added monitor lock will be canceled.

Multiple keys are monitored by the Watch command before the transaction is executed, and if any key value changes after watch, the transaction executed by the EXEC command is discarded and the nullmulti-bulk reply is returned to fail through the caller transaction.

Features:
Separate isolation operation: All commands in a transaction are serialized and executed sequentially. A transaction is not interrupted by a command request sent by another client during execution.

There is no isolation level concept: The commands in the queue are not actually executed until they are committed, and there is no "query within the transaction to see the update in the transaction, the query outside the transaction cannot see"

does not guarantee atomicity: Redis in the same transaction, if a command fails after exec, the subsequent command is still executed and no rollback is performed.

two. master-slave copying

Common one main two from

redis> info replication To see if the current Redis is the main or the library

matching from library does not match the main library

redis> slaveof IP Port sets which library the current Redis is from library

Synchronization of the master library data from the library requires that both the master and the library services are started, and the master library modifies the data to be synchronized immediately to the library.

The Slave library cannot modify the data, and the master library can modify the data.

The Master library shutdown exited, and the slave library does not automatically ascend to the Master library. The Master library restarts the service, still the original master/slave system.
The slave library shutdown exits and restarts the slave library service and does not automatically revert to the slave library, but to the master library, which requires the Slaceof IP Port restore system to be reset.

The previous slave can be master of the next slave, slave can also receive other slave connection and synchronization requests, then the slave as the next master in the chain, can effectively reduce the pressure of master.
Change direction halfway: Clears the previous data, builds the copy up to date

Slaveof no one causes the current database to stop synchronizing with other databases and turn it into the primary database.

Copy principle:
Slave boot successfully connected to master sends a sync command,
Master receives the command to start the background disk process while collecting all the commands that are used to modify the dataset, and when the background process finishes, master transfers the entire data file to slave to complete a full synchronization.

Full-volume replication: The slave service after receiving the database file, save it and load it into memory.
Incremental replication: Master continues to pass all the new collected commands to slave to complete the synchronization.

as long as it is reconnected to master, a full volume copy will be performed automatically.

The disadvantage of replication: Since all writes are now operating on master, then sync to slave, all from master to slave machine has a certain delay, when the system is busy, the delay problem will be more serious, the increase in the number of slave machines will also add to this problem.

Sentinel Mode
Redis directory new sentinel.conf file, the name can not be wrong.

Vim sentinel.conf

Fill in content: Sentinel monitor is monitored the primary database name (named by itself) IP Port N
The last digit n above indicates that after the host hangs up, all slave votes to see who takes over as the host and gets more votes than N.

Start Sentry Redis-sentinel/.../sentinel.conf