Memcached overall architecture of distributed cache system

Distributed cache for the following considerations, the first is the cache itself, the horizontal line extension problem, followed by cache large concurrency of its own performance problems, once again avoid the single point of failure of the cache (multi-replica and replica consistency). The core technology of distributed cache includes the management problem of memory itself, including the allocation of memory, management and recovery mechanism. Secondly, distributed management and distributed algorithm, followed by cache key value management and routing.

What is memcached

Many Web applications save data to an RDBMS, where the application server reads the data and displays it in the browser. But with the increase of data volume, the concentration of access, there will be Rebms burden, database response deterioration, site display delay and other significant impact. Memcached is a high-performance distributed memory cache server. The purpose of the general use is to reduce the number of database accesses by caching database query results, so as to improve the speed and expansibility of dynamic Web applications.

Memcached as a distributed cache server running at high speed has the following characteristics.

• The protocol is simple: memcached Server client communication does not use a complex MXL format, but rather uses a simple text-based protocol.
• Event handling based on Libevent: Libevent is a library that encapsulates the time-processing functions of Linux epoll, BSD-like operating systems, and so on, into a unified interface. Memcached uses this libevent library, so it can perform its high performance on Linux, BSD, Solaris and other operating systems.
• Built-in memory storage: To improve performance, the data saved in memcached is stored in Memcached's built-in memory storage space. Since the data only exists in memory, restarting memcached and restarting the operating system will cause all data to disappear. Additionally, when the content capacity reaches the specified value, memcached automatically deletes the non-applicable cache.
• memcached non-interoperable distributed: memcached Although it is a "distributed" cache server, there is no distributed functionality on the server side. Each memcached does not communicate with each other to share information. His distribution is mainly implemented through the client.

Memcached Memory Management

Recent memcached by default, a mechanism named slab allocatoion is used to allocate and manage memory. Prior to the change mechanism, the allocation of memory was performed simply by malloc and free for all records. However, this approach can lead to memory fragmentation, aggravating the burden on the operating system memory manager.

The basic principle of the Slab allocator is to divide the allocated memory into blocks of a specific length according to a predetermined size, which completely resolves the memory fragmentation problem. The principle of Slab Allocation is quite simple. Divide the allocated memory into blocks (CHUCNK) of various sizes and divide the same size blocks into groups (CHUCNK collections)

And slab allocator also has the purpose of reusing allocated memory. In other words, the allocated memory is not freed, but reused.

Main terms of Slab Allocation

• Page: The memory space allocated to slab, which is 1MB by default. After assigning to slab, the slab is divided into chunk according to the size of the.
• Chunk: The memory space used to cache records.
• Slab Class: A group of chunk of a specific size.

The principle of caching records in slab

Memcached depending on the size of the data received, select the slab (Figure 2) with the most appropriate data size, memcached the list of free chunk in slab, select chunk from the list, and then cache the data in it.

memcached Efficient use of resources in data deduplication

Memcached data does not actually disappear from memcached when data is deleted. The memcached does not release allocated memory. After the record times out, the client can no longer see the record (invisible Transparent) and its storage space can be reused.

Lazy expriationmemcached internally does not monitor whether the record is out of date, but instead looks at the timestamp of the record at get and checks whether the record is out of date. This technique is called the lazy expiration. Therefore, memcached will not consume CPU time on expired monitoring.

In the case of cache storage full capacity of the deletion needs to consider a variety of mechanisms, on the one hand, according to the queue mechanism, on the other hand should be the priority of the cache object itself, according to the priority of the cache object to delete objects.

LRU: The principle of effectively deleting data from the cache

Memcached will prefer to use a record space that has timed out, but even so, there is a situation where there is a lack of time between additional records. You will use the least recently used (LRU) mechanism to allocate space at this time. This is the mechanism for deleting the least used records. Therefore, when memcached has insufficient memory space (unable to get new space from Slab Class), it searches from the most recent unused record and allocates space to the new record.

Memcached distributed

Although Memcached is called a "distributed" cache server, there is no "distributed" functionality on the server side. The distribution of memcached is completely client-implemented. Now let's take a look at how memcached implements distributed caching.

For example, assuming that the memcached server has node1~node3 three, the application will save data with the key named "Tokyo" "Kanagawa" "Chiba" "Saitama" "Gunma".

First add "Tokyo" to the memcached. When "Tokyo" is passed to the client library, the client-implemented algorithm determines the memcached server that holds the data based on the "key". When the server is selected, it commands it to save "Tokyo" and its values.

Similarly, "Kanagawa" "Chiba" "Saitama" "Gunma" is the first to select the server and then save.

Next, you get the saved data. The key "Tokyo" To get is also passed to the library. The function library selects the server according to the "key" by the same algorithm as when the data is saved. Using the same algorithm, you can select the same server as you saved, and then send a GET command. As long as the data is not deleted for some reason, the saved value can be obtained.

This allows the memcached to be distributed by saving different keys to different servers. memcached server, the key will be scattered, even if a memcached server failure can not connect, nor affect the other cache, the system can continue to run.

A brief description of consistent hashing

Consistent hashing is as follows: first, the hash value of the memcached Server (node) is calculated and configured on the 0~232 Circle (Continuum). It then uses the same method to find the hash value of the key that stores the data and maps it to the circle. It then searches clockwise from where the data is mapped, saving the data to the first server found. If more than 232 still cannot find the server, it will be saved to the first memcached server.

Add a memcached server from the state. The remainder of the distributed algorithm affects the cache hit rate because the server that holds the key changes dramatically, but in consistent hashing, only the keys on the first server that increase the location of the server counter-clockwise on continuum are affected.

Therefore, the consistent hashing minimizes the redistribution of the keys. Moreover, some consistent hashing implementation methods also adopt the idea of virtual node. With the general hash function, the distribution of the server map location is very uneven. Therefore, using the idea of a virtual node, assign 100~200 points to each physical node (server) on the continuum. This can suppress uneven distribution and minimize cache redistribution when the server is increasing or decreasing.

Memcached installation and startup scripts http://www.linuxidc.com/Linux/2013-07/87641.htm

Performance issues with memcached in PHP http://www.linuxidc.com/Linux/2013-06/85883.htm

Ubuntu installation memcached and command explanation http://www.linuxidc.com/Linux/2013-06/85832.htm

Installation and application of memcached http://www.linuxidc.com/Linux/2013-08/89165.htm

A small picture storage scheme using nginx+memcached http://www.linuxidc.com/Linux/2013-11/92390.htm

Getting Started with memcached http://www.linuxidc.com/Linux/2011-12/49516p2.htm

Caching Multiple Replicas

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

1. Cache timeout is removed (normal expiration)

2. Cache is removed due to storage space limitations (Exception invalidation)

3. Cache invalidation due to cache node changes (exception invalidation)

In the case of caching multiple replicas, the distributed distribution policy of the cache needs to be reconsidered. The second cache of multiple replicas is actually possible for multiple read nodes, which can be done as a distributed parallel read, which is another issue that can be considered.

Consistency issues with cached data

The cached data is as read-only as possible, so the cache itself is a data scenario that is not suitable for a large number of write and update operations. In the case of read, if there is a change in data, one is to update both the cache and the database. One is to directly invalidate the cached data.

for more details, please read on to the next page. Highlights : http://www.linuxidc.com/Linux/2015-01/112507p2.htm

Memcached overall architecture of distributed cache system