Why write?
Like everyone, I have the habit of visiting the blog garden every day. Today, I saw "The First Encounter of Asp.net MVC Database Dependence on Cache " written by "a siege lion" in the blog garden . The friend uses .Net's SqlCacheDependency cache dependency to solve the problem of when the cached data is updated.
However, this idea has certain limitations. For example, it is necessary to use the stored procedure of the database to notify the client to update the cache, which is inseparable from the system of Microsoft's Sql Server. If other databases are used, it may not be so easy to implement. . And the stored procedure needs to be executed in the database, which is not conducive to transferring the business to the service program.
Programmers are more taboo to build wheels, and I believe that the same is true of programmers writing blogs. Therefore, I still want to stand on the shoulders of giants and borrow "a siege lion" in "The First Encounter of Asp.net MVC Database Depends on Caching " The background of writing is to elicit what I want to say. If there is anything wrong with "a siege lion", please contact me for removal.
-------------------------------------------------- ------------quote start ------------------------------------ -------------
A very simple function I have recently made is to request a piece of data from a drop-down table from the server using an ajax request.
This function has been done before, but an idea came up when doing this function this time:
The piece of data I requested is a relatively fixed piece of data, that is to say, it does not change much, maybe only once a few months. Because the change cycle of this kind of data is very long, in the past, when this function was used, the cache was used for optimization, and the data could be read directly from the cache, avoiding the need to ask the database for data every time an ajax request was received, reducing the The interaction between the server and the database reduces the pressure on the database server. But here comes the problem. No matter how long the data change cycle is, it will eventually change. When the data in the database changes, you have to remove the old cache content.
................................{The word XXX is omitted in the middle, and the author in the middle roughly tells that the cache is set to expire regularly}......... ......................................
There is a disadvantage to the cache periodically expiring: during the period before the expiration time, the requested data is still the original cached data. If the database data is updated during this period, the cached data and the data in the database are inconsistent. .
The absolute expiration time point set should be set according to the tolerability of the actual data refresh, and it happens that the tolerability in my application scenario is the most unpredictable. It requires that when the data in the database changes after , the corresponding data in the cache must be changed immediately after the next request. Of course, you can also adjust the expiration time as small as possible to one second. Of course, in this case, we still have to make frequent requests to the database. Isn't that deviating from our original purpose of using cache optimization?
So now the question is: Is there a way to establish a connection between the database and the server program, this connection is like a kind of "telepathy", when the data in the database table changes, the server can be immediately The corresponding cache item in "sensing" this change, thus invalidating the original cache item?
-------------------------------------------------- ------------End of reference-------------------------------------- ------
my approach
To sum up, the pain point of client (or browser) caching data is, when is the data updated? How to let the client know that the server data has changed?
Walk in four steps.
The first step, when the data is requested for the first time
When the client requests data for the first time, it will send the data the client wants together with the version number of the data (the last update time of the data) to the client. The data version number is stored in the Redis database. We know that in Redis The data is stored in memory and reading data is not a little bit faster than a relational database.
After the client receives the data, it will cache the received data and the data version number.
The second step, when the database data is updated
When the database data is updated, the server will update the Redis data version number to the current time while updating the relational database.
The third step, when the client uses data:
When the client needs to use the cached data, it will ask the server for the data version number (that is, the last update time of the data). If the data version number is consistent with the data version number cached by the client, then the data cached by the client Safe and available, if inconsistent, the data has been updated, and the client caches the new version number and retrieves it again. Then, go to step four.
The fourth step is to retrieve the data
When re-acquiring data, there is no need to carry the version number. The client has already acquired and cached it in the third step.
pros and cons
benefit:
1. When the amount of data requested is large but changes infrequently, the client and server do not need to exchange large data frequently, but only need to exchange the data version number.
2. The data version number is stored in the Redis database, which not only has a fast reading speed, but also has a small amount of data, so the response is fast and the exchange cost is low.
3. This idea has strong versatility and is suitable for use with any type of relational database and Nosql database.
Disadvantages:
1. Before each use of data, the client must communicate with the server to verify the data version number.
Good or bad is not absolute, the best one is the best one. The above is my solution. Everyone has different opinions. Welcome to leave a message for discussion. I also thank "A Siege Lion" for providing the background for the discussion!