1. Redis is used as a cache, how to synchronize MySQL data with Redis? (double write consistency)
Prerequisites: First introduce your business background
- Background 1: At that time, we stored the hot data of the article in the cache. Although it was hot data, the real-time requirements were not so high , so we used an asynchronous scheme to synchronize the data.
We used Ali's canal component to achieve data synchronization: no need to change the business code to deploy a canal service. The canal service disguises itself as a slave node of mysql. When the mysql data is updated, canal will read the binlog data, and then obtain the data through the canal client and update the cache.
- Background 2: At that time, we stored the stock of grabbing coupons in the cache, which required real-time data synchronization. In order to ensure strong data consistency , we used the read-write lock provided by rdisson to ensure data synchronization.
Adding a shared lock when reading can ensure that reading and reading are not mutually exclusive, and reading and writing are mutually exclusive. When we update data, add an exclusive lock, which is mutually exclusive for reading and writing, so that it can ensure that other threads will not read data while writing data, and avoid dirty data. What needs to be noted here is that the same lock needs to be used for the read method and the write method.
Follow-up question: How does this exclusive lock guarantee the mutual exclusion of reading and writing and reading and reading?
In fact, the underlying use of other locks is also setnx, which ensures that only one thread can operate the lock at the same time.
Follow-up: Have you heard of delayed double deletion? Why not use it?
Delayed double deletion, if it is a write operation, we delete the data in the cache first, then update the database, and finally delete the data in the cache after a delay. In fact, how long this delay is is not easy to determine. Dirty data will appear, and strong consistency cannot be guaranteed, so it is not used.
2. Redis is used as a cache, how to persist data?
Data persistence in Redis refers to saving the data in memory to the hard disk to ensure that the data can be restored even when the Redis server restarts or an unexpected failure occurs.
Two data persistence methods are provided in Redis: 1.RDB 2.AOF
Follow-up: What is the difference between these two persistence methods?
RDB (Redis Database Backup file) is a snapshot file. It writes the data stored in the redis memory to the disk . When the redis instance goes down and restores the data, it is convenient to restore the data from the RDB snapshot in the file.
AOF (Append-Only File, AOF) means to append a file. When redis operates and writes commands, it will be stored in this file. When the redis instance goes down to recover data, it will execute another command from this file to Data recovery.
Follow-up question: Which of these two methods will recover faster?
Because RDB is a binary file, its volume is relatively small when it is saved. It recovers faster, but it may lose data. We usually use AOF to recover data in projects, although AOF recovery is slower. , but the risk of data loss is much smaller. You can set the flushing strategy in the AOF file. What we set at the time was to write commands in batches once per second.
Supplement 1: RDB execution principle
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. For uses the 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, it will copy a copy of the data and perform the write operation;
Supplement 2; AOF configuration items
| configuration item | Timing of brushing | advantage | shortcoming |
|---|---|---|---|
| Always | Synchronous brush disk | High reliability, almost no data loss | performance impact |
| everysec | Brush per second | moderate performance | Up to 1 second of data loss |
| no | operating system control | best performance | Poor reliability, possible loss of large amounts of data |
When multiple write operations are performed on the same key, but only the last write operation is meaningful, the bgrewriteaof command can be used to enable the aof file to perform the rewrite function and achieve the same effect with the least number of commands.
Supplement 3: Comparison between RDB and AOF
| RDB | AOF | |
|---|---|---|
| Persistence | Take snapshots of the entire memory at regular intervals | Log every command executed |
| data integrity | Incomplete, lost between backups | Relatively complete, depending on the brushing strategy |
| File size | There will be compression, the file size is small | Record commands, the file size is very large |
| Downtime recovery speed | soon | slow |
| Data Recovery Priority | Low because data integrity is not as good as AOF | High because of higher data integrity |
| System resource usage | High, heavy CPU and memory consumption | Low, mainly disk IO resources, but AOF will take up a lot of CPU and memory resources when rewriting |
| scenes to be used | Data loss can be tolerated for several minutes, and the pursuit of faster startup speed | Higher security requirements for read data are common |
If you think this article is helpful to you, I hope you can give me a free like or favorite, this will be the motivation and encouragement for my creation!