Redis Cache policy

When using apsaradb for redis to cache data, design the cache logic as follows: when obtaining data, first obtain data from the cache. if the obtained data is empty, query the database, then, cache the queried data to redis, and then return the data. but now you have two questions: if the data... when using redis to cache data, design the cache ideas as follows:
When obtaining data, first obtain data from the cache. if the obtained data is empty, query the database, then cache the queried data to redis, and then return the data.
However, I have two questions:

1. If the query results in the database are empty, the data will not be cached, and therefore the data cannot be obtained from the cache. Therefore, a database query will be performed each time the data is obtained. how can this problem be optimized?

2. What should I do when data is updated?

I have some immature thoughts on these two questions. I would like to ask you to find out if they are feasible and whether there are better solutions:

For the first problem, if no data is obtained from the database query, a fixed default value (such as string: 'nodata') indicates no data is cached. The next time you obtain data from the cache, if this fixed value is obtained, it indicates that no data is returned, and the database does not need to be queried again.

For the second question, the current idea is that if the updated data is not particularly important, then the data will be written to the database and then the corresponding data in the cache will be directly updated, you can directly obtain the latest data without querying the database when you get the data next time. However, if the updated data is particularly important (for example, money ), after writing data to the database, the corresponding cache is cleared directly. The next time you get the data, you need to query the database to obtain the latest data.

Reply content:

When using redis to cache data, design the cache ideas as follows:
When obtaining data, first obtain data from the cache. if the obtained data is empty, query the database, then cache the queried data to redis, and then return the data.
However, I have two questions:

1. If the query results in the database are empty, the data will not be cached, and therefore the data cannot be obtained from the cache. Therefore, a database query will be performed each time the data is obtained. how can this problem be optimized?

2. What should I do when data is updated?

I have some immature thoughts on these two questions. I would like to ask you to find out if they are feasible and whether there are better solutions:

For the first problem, if no data is obtained from the database query, a fixed default value (such as string: 'nodata') indicates no data is cached. The next time you obtain data from the cache, if this fixed value is obtained, it indicates that no data is returned, and the database does not need to be queried again.

For the second question, the current idea is that if the updated data is not particularly important, then the data will be written to the database and then the corresponding data in the cache will be directly updated, you can directly obtain the latest data without querying the database when you get the data next time. However, if the updated data is particularly important (for example, money ), after writing data to the database, the corresponding cache is cleared directly. The next time you get the data, you need to query the database to obtain the latest data.

1. You need a method (for example, a null type or a type) to distinguish the two cases. For example, a JSON list is stored in the data.[{...}, {...}]When there is no data, it is stored naturally.[]. In short, there is no conflict.

2. Cache update routine | CoolShell.cn

What I said upstairs makes sense.
You can refer to the file cache ideas,
The thinkphp file cache uses serialize (valle) to save data, and the file name is used as the key name. Clear the cache and directly set (null.
The cache is only for the convenience of query and reduces the number of mysql accesses. As for the cache update problem, it must be implemented by code.