Four modes of redis: singleton mode; master-slave mode; sentinel mode, cluster mode
1. Master-slave mode
Although the singleton mode is simple to operate, it does not have high availability
shortcoming:
- Service disasters and data loss caused by a single point of downtime
- Single-point server memory bottleneck, unable to expand vertically indefinitely
Solution:
When a single node goes down, it can be temporarily replaced by other nodes, and the downtime is checked slowly, that is, the master-slave mode
advantage
With the master-slave, the overall availability of Redis is improved. When the master node (master) hangs up, the slave node (slave) can be manually upgraded to the master node to continue serving.
shortcomingIf the master hangs up the entire Redis, it will lose the ability to write operations. It only has read operations. It needs O&M to get up in the middle of the night to manually upgrade. The data loss in the middle of the request failure is intolerable.
SolutionThere can be a way to automatically upgrade slave to master ------【Sentinel Mode】
1.1 Master-slave replication
Copy data from one Redis server (master node) to other Redis servers (slave node). Data replication is one-way, only from the master node to the slave node, the master can read and write, and the slave can only read but not write; by default, each Redis server is the master node, and the slave node needs to be configured separately in the configuration file to be read from The default master node becomes a slave node. A master node can have 0 or more slave nodes, but each slave node can only have one master node.
2.1.1 Replication principle
When the slave connects to the master for the first time, it will definitely perform a full copy. The amount of
full copy data is too large, which will cause a lot of network
overhead and consume CPU/memory/hard disk IO. In the lost scene, when the slave connects to the master again, and it is the original master, if conditions permit, the master reissues the data to the slave. The amount of reissued data is small to avoid the overhead of full replication (whether it can be replicated or not depends on the offset and buffer) case)
If the master connected to the slave again is the newly elected master, then only full copy can be performed.
Early redis only had full copy, incremental copy is a major optimization of full copy, try to use version 2.8 or above
2.1.1.1 full copy
- The slave sends a sync synchronization command to the master
- The master uses the bgsave command to fork the child process to generate RDB files persistently
- The master transfers the RDB file to the slave through the network
- The slave clears the old data and loads the new RDB file. At this time, the slave is blocked and cannot respond to the client, and concentrates on copying
2.1.1.2 Incremental replication
- The master and slave nodes each maintain their own offset offset. When the master node writes a command, offset=offset+command byte length; the slave node will also increase its own offset accordingly when it receives the command from the master node, and synchronize it to the master node. The master node maintains its own offset and the offset of the slave node at the same time, so as to judge whether the data of the master and slave nodes are consistent.
- The master node command is recorded in the local buffer (buffer), and the buffer is asynchronously synchronized to the slave node
- If the network is not good and the synchronization speed is slow, the previous content will be overwritten from the beginning when the buffer is full, so it cannot be incrementally copied, and must be copied in full
# Master-slave principle
1. The copy library connects to the main library through the slaveof 127.0.0.1 6379 command, and sends SYNC to the main library.
2. The main library receives the SYNC, it will immediately trigger BGSAVE, save the RDB in the background, and send it to the copy library.
3. Copy The RDB snapshot will be applied after the library receives it.
4. The main library will successively save and send the new operations generated in the middle to the copy library. 5. At this point,
our main copy set will work normally.
New operations will be automatically sent to the replica library in the form of command propagation.
7. All replication-related information can be found from the info information. Even if any node is restarted, its master-slave relationship is still there.
8. If it happens When the master-slave relationship is disconnected, there is no damage to the data in the slave library. After the next reconnection, the slave library sends PSYNC to the master library
. From the purpose# Do you want to enable persistence in the main library (generally, it should be turned on).
If not, it is possible that the main library will restart the operation, resulting in the loss of all master-slave data!
2.2 Read-write separation
Most of the cases are read operations. Put the read operation on the slave node and the write operation on the master node to reduce the pressure on the server; at the same time, some operations that take a long time to execute can also be done on a slave node, such as keys, sort . (When to connect to the master node and when to connect to the slave node to read is controlled by the client itself)
Minimum configuration: one master and two slaves. When the master node goes down, one of the slave nodes will be upgraded to the master node, leaving one slave node.
2.3 Main function
- Data redundancy: hot backup, another way to persist
- Fault recovery: master is down, quickly upgrade slave to master
- Separation of reading and writing: master writes, slave, improves the load capacity of the server, and can add slaves according to requirements
- Load balancing: Cooperate with read-write separation, read more and write less scenarios, multiple slaves share the load, greatly improving concurrency
- The cornerstone of high availability: the basis for implementing sentinels and clusters
2. The specific operation of master-slave construction
# 前置条件1 :至少需要两台机器--》在一台机器运行两个redis实例
# 前置条件2:辅助配置(主从数据一致性配置)
min-slaves-to-write 1
min-slaves-max-lag 3
#那么在从服务器的数量少于1个,或者三个从服务器的延迟(lag)值都大于或等于3秒时,主服务器将拒绝执行写命令
# 方式一:
# 1 6380是从,6379是主
# 2 启动器两台实例
# 3 搭建主从关系
-在从库上:slaveof ip port
slaveof 127.0.0.1 6379
# 4 断开主从关系
-在从库上:slaveof no one
# 方式二:配置文件方式
# 在从库的配置文件中:
slaveof 127.0.0.1 6379
slave-read-only yes
# 使用info查看主从关系