Today, I have finished reading the "memcached comprehensive analysis" series written by MixiArticleIn combination with my experience in using memcache in projects, I will talk about the application policies of memcache on large websites.
[Deployment policy]
Memcached-based slab and dump memory management methods, which produce a small amount of memory fragments and do not require OS to perform complicated memory recovery, so its CPU usage is quite low. Therefore, we recommend that you use it with a web server with a high CPU usage to save costs. Of course, if you have a large number of cheap pcs, it would be nice to use memcached servers. In a 32-bit operating system, each process can only use 2 GB of memory at most, so if you have large memory, you can start more than two memcached services in daemon mode, or simply use a 64-bit CPU and OS.
[Service monitoring]
Memcached supports the Distributed Mechanism. php implements this mechanism through memcache: addserver, it implements a mechanism that will no longer connect to the server if one of the servers in the server list goes down at the time specified by the retry_interval parameter. Therefore, if you restart or repair the server within this period of time, the front-end will not be greatly affected. Of course, if you never restart the server, I have tested that the addserver connection time will be extended by one second than usual. You can use the last parameter failure_callback of addserver to define a callback function to enable email notification or SMS notification to administrators.
For manual restart, we recommend that you set this value to 20 minutes. However, for servers that die from the memcached process, you only need to restart memcached to run normally. Therefore, it is best to monitor and automatically start the memcached process. Recommended tools for Mixi: Nagios and daemontool
[Application policy]
Memcached is mainly used to reduce the impact of large traffic on the database. Therefore, the general logic is to first read data from memcached. If not, read data from the database and write it into memcache, the next read can be read from memcached. But the specific application policy in the project (that is, what data should be cached? How to cache? Expiration Policy ?) This is a problem. A general principle of memcached is to cache the data that often needs to be read from the database in memcached. These data are also divided into several types: 1. data that is frequently read and has poor real-time requirements can be automatically expired. For example, the list of the latest articles on the homepage and the ranking data of XX. That is, even if new data is generated, the user experience will not be affected.
This type of data uses a typical cache policy to set a reasonable expiration time and read data from the database after it expires. Of course, you have to develop a cache clearing policy to facilitate editing or other personnel to see the effect immediately. 2. data that is frequently read and has high real-time requirements. Such as the user's friend list, user article list, and user reading records.
This type of data is first loaded into memcached, And the cache is cleared when changes (ADD, modify, delete) occur. When caching, I obtain the hash value of the queried SQL statement MD5 () as the key, and write the result array as the value to memcached, in addition, the table_name and hash values involved in the SQL statement are paired into memcached. When this table is changed, I will delete all the cache of the keys that match this table. Iii. Statistics cache, such as the number of articles browsed and website PVS
This type of cache accumulates data in the database in memcached. Get is also obtained through memcached. However, this creates a problem. If the memcached server is down, the data may be lost. Therefore, memcached's permanent storage is generally used. In this regard, we use memcachedb on Sina. 4. Basic information about active users or a popular article.
One feature of this type of data is that the data is a row, that is, a one-dimensional array. when the data is updated (such as modifying the nickname or comment number of the article), while changing the database data, use memcache: replace to replace the data in the cache. This effectively avoids the re-query of the database. Vi. session data
Using memcached to store sessions is the most efficient. Memcached itself is also very stable, and it is not enough to worry that it will suddenly go down and cause the loss of session data. Even if it is lost, it will not be enough to log on again. See [Multi-server session sharing-memcache sharing]
[Summary]
The pressure on the above policy database will be greatly reduced. To check whether memcached is used properly, you can view the memcached hit rate. Some well-configured websites have a hit rate of more than 90%.
[Postscript]
1. memcached does not support failover at the moment. We hope this function will be supported in future versions. Of course, you can replace memcached with Tokyo tyrant of the Japanese, which supports the memcached protocol and permanent fixed storage and failover. However, I have not used it in the production environment and have no relevant performance test data. I will try this stuff later.
2. memcached does not support retrieval. In actual use, for example, if we want to put an IP table in memcached to retrieve the region where an IP address belongs, with the retrieval function, it is much more convenient. He hopes to provide this function in future versions. Currently, this function can be implemented on the client through the sort storage and binary method.
III. The memcached1.2.2 version is unstable, and sometimes the machine is down. We strongly recommend that you upgrade it to version 1.2.6. See Official notes: Version 1.2.6 Released . Major crash fixes, dtrace support, minor updates. If you have stability issues with any previous release, please upgrade to this one.
