Using memcached for paging caching may be troublesome for many users. Because you do not know what data will be affected during the process of adding, modifying, and deleting data. If you delete all the paging-related data caches and recreate them again, It is very troublesome to implement them, it is not even feasible, so mysql is simply used for direct paging, which is simple and convenient, but the performance is also reduced. This chapter describes how to use memcached for paging cache.
First, if we need to display an article page by page, the page type will be divided by category, by the latest page, by hotspot page, by custom page, and so on. This leads to a tricky issue. We are not sure which pages are affected by data updates, and what cache needs to be deleted. You may think that it is not good to delete the cache of all types of pages when updating data. Then I ask you, how many paging types are there, how many pages are there for each type, and what are the key composition methods? If the page contains other get query parameters, how do you know what values are passed by get and how do you delete all paging caches.
Here, you may feel a little disappointed, isn't it? I didn't expect it to be so troublesome to use memcached for paging cache. Is there a simple solution? The answer is yes. I believe that the purpose of this article is to tell you a simple solution. After talking about this, there is only one core issue that needs to be solved. When we add, modify, and delete Article data, the cache of pages will be invalidated. The solution is also very simple. We only need to introduce the version number, and add the version number to all affected memcached keys. When we add, modify, and delete Article data, the version number is + 1, in this way, the cache related to all pages becomes invalid.
The implementation code is as follows:
- <? Php
- // Note: if the following functions have already initialized $ memcached
- Class Article
- {
- Private $ article_version = 'Article _ version ';
- Public function getArticle ($ type = 'new', $ page = '1', $ limit = 0 ){
- // Set the memcached key and add the version number to the end of the key.
- $ Cache_id = 'art _ type '. $ type. '_ page '. $ page. '_ limit '. $ limit. 'V _'. $ this-> _ getArticleVersion ();
- // Obtain paging data
- $ Artdata = $ memcached-> get ($ cache_id );
- If (FALSE ===$ artdata ){
- // Obtain data from the database again and set a new memcached Cache
- }
- Return $ artdata;
- }
- Public function updateArticle ($ conditions, $ data ){
- // Update database data operations
- // Update the Article version so that all the cache related to the Article table becomes invalid. The new cache data will be generated when the getArticle function is called the next time.
- $ This-> _ setArticleVersion ();
- }
- Private function _ getArticleVersion (){
- $ Article_version_num = $ memcached-> get ($ this-> article_version );
- If (FALSE ===$ article_version_num ){
- $ Article_version_num = 1;
- $ Memcached-> set ($ this-> article_version, $ article_version_num, 86400 );
- }
- Return $ article_version_num;
- }
- Private function _ setArticleVersion (){
- $ Article_version_num = $ memcached-> get ($ this-> article_version );
- $ Article_version_num ++;
- $ Memcached-> set ($ this-> article_version, $ article_version_num, 86400 );
- }
-
- }
- ?>
Is it easy? That is, two functions _ getArticleVersion () and _ setArticleVersion () are added to the memcached cache. When we add, modify, or delete an article, we call _ setArticleVersion () function to make the version number + 1, that is, the data of the previous version invalid. Because the key is added to _ getArticleVersion () when the cached data of the article is obtained (), therefore, if you do not get the cached data of the new version number, you can find the data from the database and generate a new version of the cache. The old cache will automatically release the memory space after the expiration time.