If redis and the database are updated at the same time, it is actually a cache update strategy issue. Let me tell you my opinion, let’s consider it as a starting point:
Two strategies are commonly used for this type of problem:
1. Update when writing to the cache: This means that the cache is updated after the DB is written successfully. This strategy can reduce penetration, but it can easily cause data inconsistencies.
2. Update when reading the cache: This means that the cache is only deleted after the DB is written successfully, and the cache is rebuilt when it needs to be read. The consistency of this strategy can be guaranteed, but the penetration is large and can easily put pressure on the DB.
(After searching, I found that there are many cache update modes. The two mentioned above are just what I know of
1.Write-through Write immediately
2.Write-behind Write the cache first, put the write event into the Queue, and then write to the database
3. Eviction Policies Cache update policy directly deletes the data in the cache and waits for it to be updated the next time it is read.
4. Replication
5. Peer-To-Peer (P2P)
)
If you only update redis and then update it asynchronously to the database, it will be difficult to reconstruct the data after the cache is down. If your data does not need to be strictly accurate but needs to be accessed quickly, you can consider doing this, such as the number of page visitors.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
If redis and the database are updated at the same time, it is actually a cache update strategy issue. Let me tell you my opinion, let’s consider it as a starting point:
Two strategies are commonly used for this type of problem:
1. Update when writing to the cache: This means that the cache is updated after the DB is written successfully. This strategy can reduce penetration, but it can easily cause data inconsistencies.
2. Update when reading the cache: This means that the cache is only deleted after the DB is written successfully, and the cache is rebuilt when it needs to be read. The consistency of this strategy can be guaranteed, but the penetration is large and can easily put pressure on the DB.
(After searching, I found that there are many cache update modes. The two mentioned above are just what I know of
1.Write-through Write immediately
2.Write-behind Write the cache first, put the write event into the Queue, and then write to the database
3. Eviction Policies Cache update policy directly deletes the data in the cache and waits for it to be updated the next time it is read.
4. Replication
5. Peer-To-Peer (P2P)
)
If you only update redis and then update it asynchronously to the database, it will be difficult to reconstruct the data after the cache is down. If your data does not need to be strictly accurate but needs to be accessed quickly, you can consider doing this, such as the number of page visitors.
redis-fdw has never been used.