High Performance Website Architecture Design cache Chapter (4)-Master-slave replication

Redis's master-slave replication configuration is very easy, but let's look at some of its features.

1. Redis uses asynchronous replication. Starting with Redis 2.8, slave also periodically tells master the current amount of data. Maybe it's just a mechanism, and it shouldn't be used very much.

2. A master can have multiple slave, nonsense, this is also the industry standard bar.

3. The slave can receive connections from other slave. Does that mean that slave becomes master after receiving connections from other slave? Wait, we'll verify.

4. Redis replication is non-blocking at the end of the master, meaning that master can still execute the client's operation commands without affecting the slave when synchronizing with the data. That's not a guarantee, what are you doing?
5. Redis replication is also non-blocking at the end of the slave. There is a slave-serve-stale-data in the config file, and if it is yes, slave can use the old version of the data to process the query request when it performs the synchronization, and if it is no, slave will return an error. After the synchronization is complete, slave needs to delete the old data and load the new data, and at this stage, slave will block the connection.

6. Replication can used both for scalability, in order to has multiple slaves for read-only queries (for example, heavy S ORT operations can be offloaded to slaves), or simply for data redundancy. I don't understand the meaning of this sentence either.

7. Using replication avoids the overhead of having to write all of the data sets to disk, so you can comment out all of the save configuration items in master, do not save them, and then configure slave for slave to be saved. Although there is this feature, it seems that we do not generally do so.

Well, let's do a few examples to practice.

Open three terminals first, then three instances and connect them with three clients respectively:

Zhaoguihuadediannao:src zhaogh$./redis-server--port 10000--daemonize Yes

ZHAOGUIHUADEDIANNAO:SRC zhaogh$

ZHAOGUIHUADEDIANNAO:SRC zhaogh$./redis-cli-p 10000

Port 10000 does the master.

Slave 01:

Zhaoguihuadediannao:src zhaogh$./redis-server--port 10001--daemonize Yes

ZHAOGUIHUADEDIANNAO:SRC zhaogh$

Zhaoguihuadediannao:src zhaogh$./redis-cli-p 10001

Slave 02:

Zhaoguihuadediannao:src zhaogh$./redis-server--port 10002--daemonize Yes

ZHAOGUIHUADEDIANNAO:SRC zhaogh$

Zhaoguihuadediannao:src zhaogh$./redis-cli-p 10002

The above just lets their instance start up and connect it with the client, and does not set the master-slave relationship. Execute the following command on slave 01 and slave 02:

127.0.0.1:10001> slaveof 127.0.0.1 10000

Ok

127.0.0.1:10001>

This will set up the master-slave relationship. Let's try and see if it works.

127.0.0.1:10001> Get testkey001

(nil)

127.0.0.1:10001>

There is no value at this time.

Execute on Master:

127.0.0.1:10000> Set testkey001 testvalue001

Ok

127.0.0.1:10000>

And see if there are any slave on it:

127.0.0.1:10001> Get testkey001

"Testvalue001"

127.0.0.1:10001>

127.0.0.1:10002> Get testkey001

"Testvalue001"

127.0.0.1:10002>

Have, is not more than * * * point reading machine still easy? Already have the perceptual understanding, let us introduce the principle of it.

When you set up a master-slave relationship, the slave will send a sync command to master the first time it connects or re-connects master slave;

After master receives the instruction, start the background save process to save the data, and then collect all the data modification instructions. The background is saved, Master sent this data to Slave,slave first save the data to disk, and then load it into memory, master then the collected data modification instruction line to send Slave,slave received after the re-execution of the instruction, In this way, data synchronization is achieved.

Slave automatically reconnect after losing contact with master. If master receives multiple slave synchronization requests, it performs a single background save for all slave services.

Once master and slave are disconnected and reconnected, a full synchronization is always performed again. Starting with Redis 2.8, however, it's possible to just partially resynchronize. Please refer to the official documentation for details.

I wish you a Happy Dragon Boat Festival.

Next, redis cluster configuration, please look forward to.