Advanced Redis - Distributed Cache

distributed cache

• Solve the problems of stand-alone Redis based on Redis cluster

There are four major problems in stand-alone Redis:

1. Redis persistence

Redis has two persistence schemes:

• RDB persistence
• AOF persistence

1.1. RDB persistence

The full name of RDB is Redis Database Backup file ( Redis data backup file ), also known as Redis data snapshot. Simply put, all data in memory is recorded to disk. When the Redis instance fails and restarts, read the snapshot file from the disk and restore the data. Snapshot files are called RDB files, which are saved in the current running directory by default.

1.1.1. Execution Timing

RDB persistence is performed in four situations:

• Execute the save command
• Execute the bgsave command
• When Redis is down
• When an RDB condition is triggered

1) save command

Execute the following command to execute an RDB immediately:

The save command will cause the main process to execute RDB, and all other commands will be blocked during this process. It may only be used during data migration.

2) bgsave command

The following command can execute RDB asynchronously:

After this command is executed, an independent process will be started to complete the RDB, and the main process can continue to process user requests without being affected.

3) When shutting down

When Redis shuts down, it will execute a save command to achieve RDB persistence.

4) Trigger RDB conditions

Redis has a mechanism to trigger RDB, which can be found in the redis.conf file, and the format is as follows:

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

Other configurations of RDB can also be set in the redis.conf file:

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

1.1.2. Principle of RDB

At the beginning of bgsave, the main process will be forked to obtain the child process, and the child process will share the memory data of the main process. After the fork is completed, the memory data is read and written to the RDB file.

fork uses copy-on-write technology :

• When the main process performs a read operation, it accesses the shared memory;
• When the main process performs a write operation, a copy of the data is copied and the write operation is performed.

1.1.3. Summary

Basic process of bgsave in RDB mode?

• Fork the main process to get a child process, shared memory space
• The child process reads memory data and writes it to a new RDB file
• Replace old RDB files with new RDB files

When will RDB be executed? What does save 60 1000 mean?

• The default is when the service is stopped
• It means that RDB is triggered when at least 1000 modifications are performed within 60 seconds

Disadvantages of RDB?

• The RDB execution interval is long, and there is a risk of data loss between two RDB writes.
• Fork child process, compress, and write out RDB files are time-consuming

1.2. AOF persistence

1.2.1. Principle of AOF

The full name of AOF is Append Only File (append file) . Every write command processed by Redis will be recorded in the AOF file, which can be regarded as a command log file.

1.2.2. AOF configuration

AOF is disabled by default, you need to modify the redis.conf configuration file to enable AOF:

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

The frequency of AOF command recording can also be configured through the redis.conf file:

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

Comparison of three strategies:

1.2.3. AOF file rewriting

Because it is a record command, the AOF file will be much larger than the RDB file. And AOF will record multiple write operations to the same key, but only the last write operation is meaningful. By executing the bgrewriteaof command, the AOF file can be rewritten to achieve the same effect with the fewest commands.

As shown in the figure, AOF originally has three commands, but set num 123 和 set num 666they are all operations on num. The second time will overwrite the first value, so it is meaningless to record the first command.

So after rewriting the command, the content of the AOF file is:mset name jack num 666

Redis will also automatically rewrite the AOF file when the threshold is triggered. Thresholds can also be configured in redis.conf:

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

1.3. Comparison between RDB and AOF

RDB and AOF each have their own advantages and disadvantages. If the data security requirements are high, they are often used in combination in actual development .

1.4 Redis Persistence Usage Scenarios

Redis provides two persistence methods: RDB persistence and AOF persistence, which can be applied to different scenarios respectively.

RDB persistence and AOF persistence can be applied to the following different scenarios:

1. RDB persistence: Applicable to scenarios with large data volume and high speed requirements. For example, scenarios such as data backup, migration, and recovery operations. At the same time, in some scenarios with less reading and writing, using RDB persistence can also reduce the I/O load of the server.
2. AOF Persistence: Applicable to scenarios where data updates are frequent and data accuracy is required. The AOF persistence mode records all write operations to the database in the file in the form of appending, which can avoid data loss, and data recovery can be performed by playing back the AOF file.

It should be noted that RDB persistence and AOF persistence have their own advantages and disadvantages, and should be weighed and selected according to specific business scenarios.

• Generally speaking, for scenarios with a large amount of data and relatively stable read and write operations, using the RDB persistence method can perform data backup and recovery more efficiently;
• For scenarios with high data update frequency and high data accuracy requirements, the AOF persistence method can better ensure data reliability and integrity.
• Of course, according to the actual situation, the combination of the two persistence methods can also be used to give full play to their respective advantages and improve the reliability and efficiency of the system.

2. Redis master-slave

2.1. Build a master-slave architecture

The concurrency capability of single-node Redis has an upper limit. To further improve the concurrency capability of Redis, it is necessary to build a master-slave cluster to achieve read-write separation.

For the specific construction process, refer to Redis cluster

Assuming there are two Redis instances, A and B, how to make B the slave node of A?

• Execute the command on node B: slaveof A's IP A's port

  slaveof 192.168.11.123 6379
  

2.2. Master-slave data synchronization principle

2.2.1. Full synchronization

The first master-slave synchronization is full synchronization. When the master-slave establishes a connection for the first time, it will perform full synchronization and copy all the data of the master node to the slave node. The process is as follows:

Here is a question, how does the master know that the salve is connecting for the first time? ?

There are several concepts that can be used as the basis for judgment:

• Replication Id : Replid for short, is the mark of the data set, and the same id means that it is the same data set. Each master has a unique reply, and the slave will inherit the reply of the master node
• offset : The offset, which gradually increases as the data recorded in repl_baklog increases. When the slave completes the synchronization, it will also record the current synchronization offset. If the slave's offset is smaller than the master's offset, it means that the slave data lags behind the master and needs to be updated.

Therefore, for data synchronization, the slave must declare its own replication id and offset to the master, so that the master can determine which data needs to be synchronized.

Because the slave is originally a master with its own reply and offset, when it becomes a slave for the first time and establishes a connection with the master, the sent reply and offset are its own reply and offset.

The master judges that the replid sent by the slave is inconsistent with its own, indicating that this is a brand new slave, and it knows that it needs to do full synchronization.

The master will send its reply and offset to the slave, and the slave will save the information. In the future, the replid of the slave will be the same as that of the master.

Therefore, the basis for the master to judge whether a node is synchronized for the first time is to see whether the replid is consistent .

As shown in the picture:

Full process description:

• The slave node requests incremental synchronization
• The master node judges replid, finds inconsistency, and refuses incremental synchronization
• Master generates RDB with complete memory data and sends RDB to slave
• The slave clears the local data and loads the RDB of the master
• The master records the commands during the RDB period in repl_baklog, and continuously sends the commands in the log to the slave
• The slave executes the received command and keeps in sync with the master

2.2.2. Incremental synchronization

Full synchronization needs to create RDB first, and then transfer the RDB file to a slave through the network, which is too expensive. Therefore, except for the first full synchronization, the slave and the master perform incremental synchronization most of the time .

What is delta sync? It is to update only part of the data that is different between the slave and the master. As shown in the picture:

So how does the master know where the data difference between the slave and itself is?

2.2.3. repl_backlog principle

How does the master know where the data difference between the slave and itself is?

This is about the repl_baklog file during full synchronization.

This file is an array with a fixed size, but the array is circular, that is to say, after the subscript reaches the end of the array, it will start reading and writing from 0 again , so that the data at the head of the array will be overwritten.

Repl_baklog will record the command log and offset processed by Redis, including the current offset of the master and the offset that the slave has copied to:

The difference between the offset of the slave and the master is the data that the slave needs to incrementally copy.

As data continues to be written, the offset of the master gradually increases, and the slave keeps copying to catch up with the offset of the master:

until the array is filled:

At this point, if new data is written, the old data in the array will be overwritten. However, as long as the old data is green, it means that the data has been synchronized to the slave, even if it is overwritten, it will have no effect. Because only the red part is not synchronized.

However, if the slave has network congestion, the offset of the master far exceeds the offset of the slave:

If the master continues to write new data, its offset will overwrite the old data until the current offset of the slave is also overwritten:

The red part in the brown box is the data that has not been synchronized but has been overwritten. At this time, if the slave recovers, it needs to synchronize, but finds that its offset is gone, and the incremental synchronization cannot be completed. Can only do full sync.

2.3. Master-slave synchronization optimization

Master-slave synchronization can ensure the consistency of master-slave data, which is very important.

Redis master-slave clusters can be optimized from the following aspects:

• Configure repl-diskless-sync yes in the master to enable diskless replication to avoid disk IO during full synchronization.
• The memory usage on a Redis single node should not be too large to reduce excessive disk IO caused by RDB
• Appropriately increase the size of repl_baklog, realize fault recovery as soon as possible when the slave is down, and avoid full synchronization as much as possible
• Limit the number of slave nodes on a master. If there are too many slaves, you can use a master-slave-slave chain structure to reduce the pressure on the master

Master-slave architecture diagram:

2.4. Summary

Briefly describe the difference between full synchronization and incremental synchronization?

• Full synchronization: the master generates an RDB with complete memory data and sends the RDB to the slave. Subsequent commands are recorded in repl_baklog and sent to slave one by one.
• Incremental synchronization: the slave submits its own offset to the master, and the master obtains the commands after the offset in the repl_baklog to the slave

When to perform full synchronization?

• When the slave node connects to the master node for the first time
• The slave node has been disconnected for too long and the offset in the repl_baklog has been overwritten

When is an incremental sync performed?

• When the slave node is disconnected and restored, and the offset can be found in the repl_baklog

2.5 Master-slave synchronization usage scenarios

Redis master-slave synchronization is a data replication mechanism, which can replicate data on one Redis server to another Redis server to achieve data backup, read-write separation, and load balancing. Master-slave synchronization is usually used in the following scenarios:

1. Data backup: realize data backup and disaster recovery by copying the data on the master server to the slave server.
2. Read-write separation: Distribute read operations to multiple slave servers, reduce the pressure on the master server, and improve the concurrency of the system.
3. Load balancing: Multiple slave servers can process client requests at the same time, thereby improving system service capabilities.
4. High availability: When the master server fails, the slave server can be upgraded to the master server through automatic switching to ensure high availability of the system.

It should be noted that although master-slave synchronization can realize functions such as data backup and load balancing, in actual use, problems such as network delay, data consistency, and fault recovery need to be considered, and reasonable design and configuration should be carried out according to specific business scenarios.

3. Redis Sentry

Redis provides a Sentinel mechanism to achieve automatic failure recovery of the master-slave cluster.

3.1. Sentinel principle

3.1.1. Cluster structure and function

The structure of Sentinel is shown in the figure:

The role of the sentinel is as follows:

• Monitoring : Sentinel constantly checks that your master and slave are working as expected
• Automatic failure recovery : If the master fails, Sentinel will promote a slave to master. When the faulty instance recovers, the new master is also the main one
• Notification : Sentinel acts as the service discovery source for the Redis client, and when the cluster fails over, it will push the latest information to the Redis client

3.1.2. Cluster monitoring principle

Sentinel monitors the service status based on the heartbeat mechanism, and sends a ping command to each instance of the cluster every 1 second:

• Subjective offline: If a sentinel node finds that an instance does not respond within the specified time, it considers the instance to be offline subjectively .

• Objective offline: If more than the specified number (quorum) of sentinels think that the instance is subjectively offline, the instance will be objectively offline . The quorum value is preferably more than half of the number of Sentinel instances.

3.1.3. Cluster failure recovery principle

Once a master failure is found, sentinel needs to select one of the salves as the new master. The selection basis is as follows:

• First, it will judge the length of disconnection between the slave node and the master node. If it exceeds the specified value (down-after-milliseconds * 10), the slave node will be excluded
• Then judge the slave-priority value of the slave node, the smaller the priority, the higher the priority, if it is 0, it will never participate in the election
• If the slave-prority is the same, judge the offset value of the slave node. The larger the value, the newer the data and the higher the priority
• The last is to judge the size of the running id of the slave node, the smaller the priority, the higher the priority.

When a new master is elected, how to implement the switch?

The process is as follows:

• Sentinel sends the slaveof no one command to the candidate slave1 node to make the node the master
• Sentinel sends the slaveof 192.168.150.101 7002 command to all other slaves to make these slaves become slave nodes of the new master and start synchronizing data from the new master.
• Finally, sentinel marks the failed node as a slave, and when the failed node recovers, it will automatically become the slave node of the new master

3.1.4. Summary

What are the three functions of Sentinel?

• monitor
• failover
• notify

How does Sentinel judge whether a redis instance is healthy?

• Send a ping command every 1 second, if there is no communication for a certain period of time, it is considered as subjective offline
• If most of the sentinels think that the instance is offline subjectively, it is determined that the service is offline

What are the failover steps?

• First select a slave as the new master, execute slaveof no one
• Then let all nodes execute slaveof new master
• Modify the faulty node configuration, add slaveof new master

3.2. Building a sentinel cluster

For the specific construction process, refer to Redis cluster

3.3.RedisTemplate

In the Redis master-slave cluster under the supervision of Sentinel cluster, its nodes will change due to automatic failover, and the Redis client must perceive this change and update the connection information in time. The underlying layer of Spring's RedisTemplate uses lettuce to realize node perception and automatic switching.

Next, we implement the RedisTemplate integration sentinel mechanism through a test.

3.3.1. Import Demo project

First, we introduce the demo project provided by the pre-class materials

3.3.2. Introducing dependencies

Introduce dependencies in the project's pom file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

3.3.3. Configure Redis address

Then specify the sentinel related information of redis in the configuration file application.yml:

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

3.3.4. Configure read-write separation

In the startup class of the project, add a new bean:

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
    
    
    return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

This bean is configured with read and write strategies, including four types:

• MASTER: read from the master node
• MASTER_PREFERRED: Read from the master node first, read the replica when the master is unavailable
• REPLICA: read from the slave (replica) node
• REPLICA _PREFERRED: Read from the slave (replica) node first, all slaves are unavailable to read the master

3.4 Redis sentry usage scenarios

Redis Sentinel (Sentinel) is a high-availability solution that can automatically perform fault detection, failover, and fault recovery when the Redis master node fails or is unavailable, thereby ensuring the high availability of the Redis cluster. Redis Sentinel is usually suitable for the following scenarios:

1. Redis master-slave replication high availability: When the Redis master node fails or is unavailable, Redis Sentinel can automatically promote one of the slave nodes to a new master node, thereby achieving high availability of the Redis cluster.
2. Redis multi-node high availability: When there are multiple master nodes in the Redis cluster, Redis Sentinel can automatically perform fault detection and switching to ensure the normal coordination among multiple master nodes.
3. Redis read-write separation high availability: When there are multiple read nodes in the Redis cluster, Redis Sentinel can automatically route client requests to available nodes, thereby achieving high availability of read-write separation.
4. Redis operation and maintenance management: Redis Sentinel also provides monitoring, alarm, management and other functions, which can facilitate the operation and maintenance management of Redis cluster.

It should be noted that although Redis Sentinel can improve the high availability of Redis clusters, in actual use, issues such as network delay, node information synchronization, and fault recovery time need to be considered, and should be reasonably designed and configured according to specific business scenarios.

4. Redis fragmentation cluster

4.1. Build a shard cluster

Master-slave and sentry can solve the problem of high availability and high concurrent reading. But there are still two unresolved issues:

• Mass data storage problem

• The problem of high concurrent writing

Using fragmented clusters can solve the above problems, as shown in the figure:

Sharded cluster features:

• There are multiple masters in the cluster, and each master saves different data

• Each master can have multiple slave nodes

• The master monitors each other's health status through ping

• Client requests can access any node in the cluster and will eventually be forwarded to the correct node

For the specific construction process, refer to Redis cluster

4.2. Hash slots

4.2.1. Slot principle

Redis will map each master node to a total of 16384 slots (hash slots) ranging from 0 to 16383, which can be seen when viewing the cluster information:

Data keys are not bound to nodes, but to slots. Redis will calculate the slot value based on the effective part of the key, in two cases:

• The key contains "{}", and "{}" contains at least 1 character, and the part in "{}" is a valid part
• The key does not contain "{}", the entire key is a valid part

For example: if the key is num, then it will be calculated according to num, if it is {itcast}num, then it will be calculated according to itcast. The calculation method is to use the CRC16 algorithm to obtain a hash value, and then take the remainder of 16384, and the result obtained is the slot value.

As shown in the figure, when set a 1 is executed on node 7001, a hash operation is performed on a, and the remainder of 16384 is obtained, and the result is 15495, so it needs to be stored in node 103.

After reaching 7003, get numwhen executing, perform a hash operation on num, take the remainder of 16384, and the result is 2765, so you need to switch to 7001 node

4.2.1. Summary

How does Redis determine which instance a key should be in?

• Allocate 16384 slots to different instances
• Calculate the hash value according to the effective part of the key, and take the remainder of 16384
• The remainder is used as the slot, just find the instance where the slot is located

How to save the same type of data in the same Redis instance?

• This type of data uses the same effective part, for example, keys are all prefixed with {typeId}

In the Redis sharding cluster, the entire data set is divided into a certain number of slots, which are evenly distributed to different nodes. A hash value is calculated according to the hash key, and a corresponding slot is determined according to the hash value. Therefore, each node is responsible for processing part of the slot's data.

An example is as follows: Suppose you want to create a Redis cluster, including 3 nodes, and each node runs a Redis instance, then you can divide the entire slot space into 16384 slots (0-16383), and then evenly distribute these slots to different node. For example, the following assignments can be made:

• Node 1: Responsible for processing slots from 0 to 5460
• Node 2: Responsible for processing slots 5461~10922
• Node 3: responsible for processing slots 10923~16383

When a client connects to a Redis cluster and adds a key-value pair to it, the Redis client will hash the key to calculate a 32-bit integer hash value. Then, map to the corresponding slot according to the hash value, and then find the node that needs to store the key-value pair. If a request sent to that node fails, the client will retry other nodes until it succeeds.

For example, if you want to add a string whose key is "foo" to the example cluster, the Redis client will first perform hash calculation on it to obtain a hash value, assuming it is 4567. From that hash value, it can be determined that it should be stored in node 1's slot. Therefore, the client sends the key-value pair to node 1 and asks it to be stored somewhere in slot 0~5460. In this way, when the value whose key is "foo" needs to be searched, it can be determined in which node to perform the query by calculating its hash value.

4.3. Cluster scaling

redis-cli --cluster provides many commands to operate the cluster, which can be viewed in the following ways:

For example, the command to add a node:

4.3.1. Demand analysis

Requirement: Add a new master node to the cluster and store num = 10 in it

• Start a new redis instance with port 7004
• Add 7004 to the previous cluster and act as a master node
• Assign a slot to the 7004 node so that the key num can be stored in the 7004 instance

Two new functions are needed here:

• Add a node to the cluster
• Assign some slots to new slots

4.3.2. Create a new redis instance

Create a folder:

mkdir 7004

Copy the configuration file:

cp redis.conf /7004

Modify the configuration file:

sed /s/6379/7004/g 7004/redis.conf

start up

redis-server 7004/redis.conf

4.3.3. Add new nodes to redis

The syntax for adding a node is as follows:

Excuting an order:

redis-cli --cluster add-node  192.168.150.101:7004 192.168.150.101:7001

Check the cluster status with the command:

redis-cli -p 7001 cluster nodes

As shown in the figure, 7004 has joined the cluster and is a master node by default:

However, it can be seen that the number of slots of the 7004 node is 0, so no data can be stored on the 7004

4.3.4. Transfer slots

We want to store num to node 7004, so we need to see how many slots num has:

As shown above, the slot of num is 2765.

We can transfer the slots of 0~3000 from 7001 to 7004, the command format is as follows:

The specific commands are as follows:

establish connection:

Get the following feedback:

Ask how many slots to move, we plan to be 3000:

Here comes the new problem:

Which node to receive these slots? ?

Obviously it is 7004, so what is the id of node 7004?

Copy this id, and then copy it to the console just now:

Ask here, where did your slot move from?

• all: represents all, that is, each of the three nodes transfers a part
• Specific id: the id of the target node
• done: no more

Here we want to get from 7001, so fill in the id of 7001:

Once filled, click done, and the slot transfer is ready:

Are you sure you want to transfer? Enter yes:

Then, view the results with the command:

can be seen:

The goal is achieved.

4.4. Failover

The initial state of the cluster is as follows:

Among them, 7001, 7002, and 7003 are masters, and we plan to shut down 7002.

4.4.1. Automatic failover

What happens when a master in the cluster goes down?

Stop a redis instance directly, such as 7002:

redis-cli -p 7002 shutdown

1) First, the instance loses connection with other instances

2) Then there is a suspected downtime:

3) Finally, it is determined to go offline and automatically promote a slave to the new master:

4) When the 7002 starts up again, it will become a slave node:

4.4.2. Manual failover

Using the cluster failover command, you can manually shut down a master in the cluster and switch to the slave node that executes the cluster failover command to realize data migration without perception. The process is as follows:

This failover command can specify three modes:

• Default: The default process, as shown in Figure 1~6 steps
• force: omits the consistency check of offset
• takeover: Execute step 5 directly, ignoring data consistency, master status and other master opinions

Case requirements : Perform manual failover on the slave node 7002 to regain the master status

Proceed as follows:

1) Use redis-cli to connect to node 7002

2) Execute the cluster failover command

As shown in the picture:

Effect:

4.5. RedisTemplate access to fragmented cluster

The bottom layer of RedisTemplate also implements the support of fragmented clusters based on lettuce, and the steps used are basically the same as the sentinel mode:

1) Introduce the starter dependency of redis

2) Configure the shard cluster address

3) Configure read-write separation

Compared with sentinel mode, only the configuration of fragmented clusters is slightly different, as follows:

spring:
  redis:
    cluster:
      nodes:
        - 192.168.150.101:7001
        - 192.168.150.101:7002
        - 192.168.150.101:7003
        - 192.168.150.101:8001
        - 192.168.150.101:8002
        - 192.168.150.101:8003

4.6 Advantages, disadvantages and usage scenarios of Redis sharding cluster

advantage:

1. Improve system performance and throughput: By distributing data to multiple nodes for parallel processing, the read and write performance and throughput of the system can be significantly improved.
2. Improve availability and fault tolerance: When a node goes down or fails, other nodes can still work normally, avoiding the impact of a single point of failure on the entire system, and ensuring data security and reliability.
3. Good scalability: By increasing the number of nodes, the processing and storage capabilities of the system can be easily expanded, with good horizontal scalability.

shortcoming:

1. Additional configuration and management are required: configuration and management of sharding rules, node running status, etc. are required. Compared with a single node, the deployment and maintenance of a sharded cluster is much more complicated.
2. High cost of data migration: When the number of nodes needs to be adjusted or the system is upgraded, a large amount of data migration and rebalancing is required, including data backup, recovery, redirection and rebalancing operations, etc., so the cost of data migration is very high.
3. Transaction processing limitation: due to the limitation of Redis's distributed transaction function, there may be many restrictions when performing transaction processing because it spans multiple nodes, and in some scenarios, it may be necessary to use related technologies such as distributed locks. Controlling transaction processing.

scenes to be used:

1. Large amount of data or frequent reading and writing: When a single Redis node cannot meet the performance requirements of the system, you can consider dividing the data into multiple nodes to improve the processing capacity and throughput of the system.
2. Partitioning of business requirements: When business data can be divided and processed according to certain rules, such as user ID, data of different users can be stored on different nodes to reduce cross-effects between data and improve system availability. Maintainability and scalability.
3. High availability and fault tolerance: When the business has strict requirements on service availability and data security, Redis sharding clusters can be used to ensure system availability and data security.

ter:
nodes:
- 192.168.150.101:7001
- 192.168.150.101:7002
- 192.168.150.101:7003
- 192.168.150.101:8001
- 192.168.150.101:8002
- 192.168.150.101:8003

## 4.6 Redis分片集群优缺点及使用场景

优点：

1. 提高系统性能和吞吐量：通过将数据分布到多个节点并行处理，可以显著提高系统的读写性能和吞吐量。
2. 提高可用性和容错性：当某个节点宕机或出现故障时，其他节点仍可以正常工作，避免了单点故障对整个系统造成的影响，并保证了数据的安全性和可靠性。
3. 扩展性好：通过增加节点的数量，可以方便地扩展系统的处理能力和存储能力，有良好的水平扩展性。

缺点：

1. 需要额外的配置和管理：需要对分片规则、节点运行状态等进行配置和管理，相比于单节点，分片集群的部署和维护要复杂得多。
2. 数据迁移成本较高：当需要调整节点数量或进行系统升级时，需要大量的数据迁移和重新平衡，其中包括数据备份、恢复、重定向和再平衡操作等，因此数据迁移的成本很高。
3. 事务处理限制：由于Redis的分布式事务功能受到限制，导致在进行事务处理时，可能会因为跨多节点而存在很多限制，而且在某些场景下，可能需要使用到分布式锁等相关技术，进行事务处理的控制。

使用场景：

1. 数据量较大或读写频繁：当单个Redis节点无法满足系统的性能要求时，可以考虑将数据分片到多个节点上，提高系统的处理能力和吞吐量。
2. 业务需求分区：当业务数据可以按照某种规则进行划分并处理，比如按照用户ID进行划分，可以将不同用户的数据存储在不同的节点上，减少数据之间的交叉影响，同时提高系统的可维护性和可扩展性。
3. 高可用性和容错性：当业务对于服务的可用性和数据安全性有严格要求时，可以采用Redis分片集群，保证系统的可用性和数据的安全性。