[Learn More-memcached] memory management and principle of mecached

This article is reprinted -- please indicate the source: http://wenku.baidu.com/view/8686d46c7e21af45b307a8c3.html

What is memcached?

Many Web applications save data to RDBMS. The application server reads data from the data and displays the data in the browser. However, as the amount of data increases and access is concentrated, the burden of rebms will increase, database response will deteriorate, and the website display latency will be significantly affected. Memcached is a high-performance distributed memory cache server. The general purpose is to cache database query results to reduce the number of database accesses, so as to speed up dynamic web applications and improve scalability.

 

As a high-speed distributed cache server, memcached has the following features.

• Simple Protocol: memcached Server Client Communication uses a simple text-based protocol instead of a complex mxl format.
• Libevent-based event processing: libevent is a library that encapsulates time processing functions such as epoll and kqueue of BSD operating systems in Linux into a unified interface. Memcached uses this libevent library to achieve high performance in Linux, BSD, Solaris, and other operating systems.
• Built-in memory storage: to improve performance, data stored in memcached is stored in the memory storage space built in memcached. Since the data only exists in the memory, restarting memcached will cause all data to disappear. In addition, after the content capacity reaches the specified value, memcached automatically deletes the unsuitable cache.
• Distributed memcached does not communicate with each other: Although memcached is a "distributed" cache server, the server does not have distributed functions. Memcached does not communicate with each other to share information. Its distribution is mainly implemented through the client.

Memcached Memory Management

By default, the latest memcached uses the slaballocatoion mechanism to allocate and manage memory. Before the mechanism was changed, the memory was allocated by simply malloc and free all records. However, this method may cause memory fragmentation and increase the burden on the memory manager of the operating system.

The basic principle of Slab allocator is to divide the allocated memory into blocks of a specific length according to the predefined size, which has completely solved the problem of memory fragmentation. The principle of slaballocation is quite simple. Divide the allocated memory into blocks of various sizes (chucnk), and divide the blocks of the same size into groups (a set of chcnk)

In addition, Slab allocator can reuse allocated memory. That is to say, the allocated memory is not released, but reused.

Slab allocation terminology

• Page: memory space allocated to slab. The default value is 1 MB. After being allocated to slab, it is split into Chunk Based on the size of slab.
• Chunk: memory space used to cache records.
• Slabclass: Group of chunks of a specific size.

Principle of caching records in Slab

Memcached selects the slab with the most suitable data size based on the size of the received data (Figure 2) memcached stores the list of idle chunks in slab, and selects chunk according to the list, then, cache the data in it.
 

Memcached effectively exploits resources in data deletion

When memcached deletes data, the data does not actually disappear from memcached. Memcached does not release allocated memory. After the record times out, the client will no longer be able to see the record (invisible transparent), and its storage space can be reused.

Lazyexpriationmemcached does not monitor whether the record has expired. Instead, it checks the timestamp of the record during get to check whether the record has expired. This technology is called lazyexpiration. Therefore, memcached does not consume CPU time on expired monitoring.

When the cache storage capacity is full, multiple mechanisms need to be taken into account. On the one hand, the queue mechanism should be used. On the other hand, objects should be deleted based on the cache object's priority.

LRU: how data is effectively deleted from the cache

Memcached will give priority to the time-out record space, but even so, there will also be insufficient space to append new records. In this case, we need to use the leastrecently used (LRU) mechanism to allocate space. This is the mechanism for deleting the least used records. Therefore, when memcached has insufficient memory space (you cannot obtain the new space from slabclass), you can search for the latest unused records and allocate the space to the new records.

Memcached distributed

Although memcached is called a "distributed" cache server, the server does not have a "distributed" function. Memcached's distributed architecture is completely implemented by clients. Now let's take a look at how memcached implements distributed cache.

For example, assume that the memcached server has node1 ~ Three node3 servers. The application will save the data with the key name "Tokyo" "Kanagawa" "CHBA" "Saitama" "Gunma.
 
First, add "Tokyo" to memcached ". After "Tokyo" is passed to the client library, the algorithm implemented by the client determines the memcached server that stores data based on the "key. After the server is selected, run the command to save "Tokyo" and its value.
 
Similarly, "Kanagawa", "CHBA", "Saitama", and "Gunma" are both saved on the server first.

Next, obtain the saved data. The key "Tokyo" to be obtained is also passed to the function library. The function library uses the same algorithm as the data storage algorithm to select a server based on the "key. If the algorithm used is the same, you can select the same server as the storage server and then send the GET command. As long as the data is not deleted for some reason, you can get the saved value.
 
In this way, memcached is distributed by storing different keys on different servers. When the number of memcached servers increases, keys will be dispersed. Even if a memcached server fails to connect, other caches will not be affected, and the system will continue to run.

Memcached cache distribution policy: http://blog.csdn.net/bintime/article/details/6259133

A brief description of consistenthashing (Distributed consistent hash algorithm)

Consistent hashing is as follows: first obtain the hash value of the memcached server (node) and configure it to 0 ~ 232 of the circle (continuum. Then, use the same method to obtain the hash value of the key for storing the data and map it to the circle. Search clockwise from the location where the data is mapped, and save the data to the first server. If more than 232 still cannot find the server, it will be saved to the first memcached server.

Add a memcached server from the status. The residual number distributed algorithm affects the cache hit rate because the server that saves the key changes significantly. However, in consistent hashing, the keys on the first server that is added to the Continuum server in a counterclockwise direction will be affected.

Therefore, consistent hashing minimizes key redistribution. In addition, some consistenthashing implementation methods also adopt the idea of virtual nodes. If a common hash function is used, the server's ing locations are unevenly distributed. Therefore, the idea of virtual nodes is used to allocate 100 ~ 200 points. In this way, the distribution will be restrained unevenly, minimizing the cache redistribution when servers increase or decrease.

Cache multiple copies

Multiple cached copies are used to store multiple cached copies when cached data is stored to prevent cache invalidation. Cache invalidation occurs in the following situations:

• 1. cache timeout is removed (normal failure)
• 2. the cache is removed due to storage space restrictions (abnormal and invalid)
• 3. cache failure due to changes in the cache node (abnormal failure)

When multiple copies are cached, you need to reconsider the cache distributed distribution policy. Second, multiple cached copies are actually multiple read nodes, which can be used as distributed parallel reads. This is another consideration.

Cache Data Consistency

The cached data should be read-only as much as possible. Therefore, the cache itself is not suitable for data scenarios with a large number of write and update operations. If data changes occur during read operations, the cache and database are updated simultaneously. One is to process cache data failure directly.