Chapter 2 delete mechanism and development direction of memcached

Memcached is a cache, so data is not permanently stored on the server. This is the prerequisite for introducing memcached to the system.
This article introduces the data deletion mechanism of memcached and the latest development direction of memcached-binary Protocol
Protocol) and external engine support.
3.1 memcached effectively uses resources for data deletion
Data will not actually disappear from memcached
As described in the previous chapter, 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.
Lazy expiration
Memcached does not monitor whether the record expires, but checks the timestamp of the record during get to check whether the record expires. This
Lazy (inert) expiration. Therefore, memcached does not consume CPU time on expired monitoring.
3.2 LRU: how data is effectively deleted from the cache
Memcached preferentially uses the space of records that have timed out, but even so, there will also be insufficient space-time for appending new records,
In this case, the least recently used (LRU) mechanism is used to allocate space. As the name suggests, this is to delete the "least recent
Use the "record mechanism. Therefore, when memcached has insufficient memory space (the new space cannot be obtained from the slab class)
), Search from the records that have not been used recently, and allocate their space to the new records. From the perspective of caching
The model is ideal.
However, in some cases, the LRU mechanism may cause problems. When memcached is started, use "M"
The parameter can disable LRU, as shown in figure
As shown below:
$ Memcached m
M
1024
Note that the lower-case "M"
Specifies the maximum memory size. If no specific value is specified, the default value is used.
The value is 64 MB.
Specify "M"
After the parameter is enabled, memcached returns an error when the memory usage is exhausted. After all, memcached is not a storage device.
Is cached, so LRU is recommended.
3.3 The Latest Development Direction of memcached
Memcached's roadmap has two major targets. One is the planning and implementation of the binary protocol, and the other is the external engine.
Load function.
18
Idv2.com Chapter 4 Delete mechanism and development direction of memcached
About the binary Protocol
The reason for using the binary protocol is that it does not need to parse the text protocol, making the original high-speed memcached performance more powerful.
To reduce text protocol vulnerabilities. Currently, most of the implementations have been implemented. Code Library already contains this function.
The download page of memcached contains a link to the code library.
Http://danga.com/memcached/download.bml
Binary protocol format
The Protocol package is a 24-byte frame followed by a key and unstructured data ). The actual format is as follows (
Protocol document ):
Byte/0 | 1 | 2 | 3 |
/|
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 |
++
+
+
+
0/Header/
//
//
//
++
+
+
+
24/commandspecific
Extras (as needed )/
+/(Note length in th extras Length header field )/
++
+
+
+
M/Key (as needed )/
+/(Note length in Key Length header field )/
++
+
+
+
N/value (as needed )/
+/(Note length is total body length header field, minus/
+/Sum of the extras and key length body fields )/
++
+
+
+
Total 24 bytes
As shown above, the package format is very simple. It should be noted that the header occupying 16 bytes is divided into request headers.
Request Header and response header. The header contains the magic word indicating the validity of the package.
Section, command type, key length, value length, and other information. The format is as follows:
Request Header
Byte/0 | 1 | 2 | 3 |
/|
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 |
++
+
+
+
0 | magic | opcode | key length |
++
+
+
+
4 | extras length | data type | reserved |
++
+
+
+
8 | total body length |
++
+
+
+
12 | opaque |
19
Idv2.com Chapter 4 Delete mechanism and development direction of memcached
++
+
+
+
16 | CAS |
|
++
+
+
+
Response Header
Byte/0 | 1 | 2 | 3 |
/|
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 |
++
+
+
+
0 | magic | opcode | key length |
++
+
+
+
4 | extras length | data type | status |
++
+
+
+
8 | total body length |
++
+
+
+
12 | opaque |
++
+
+
+
16 | CAS |
|
++
+
+
+
If you want to know the details of each part, you can checkout the code tree of the memcached binary protocol. For details, refer to
Protocol_binary.txt in the docsfolder.
What is striking in the header
What I think after seeing the header format is that the upper limit of the key is too large! In the current memcached specification, the maximum key length is
250 bytes, but the size of the key in the binary protocol is 2 bytes. Therefore, theoretically the maximum length is 65536 bytes (216 ).
. Although keys larger than 250 bytes are not very commonly used, a huge key can be used after the binary protocol is released.
The binary protocol is supported in the next version 1.3 series.
3.4 external engine support
Last year I tried to transform the memcached storage layer into a scalable (Pluggable ).
• Http://alpha.mixi.co.jp/blog? P = 129
After seeing this transformation, Brian Aker of MySQL sent the code to the memcached email list. Memcached
Developers are also very interested, so they are placed in roadmap. I am working with Trond norbye, A memcached developer.
Release (specification design, implementation and testing ). The time difference with overseas collaborative development is a big problem, but with the same vision, finally
You can publish the prototype of the scalable architecture. The code library can be accessed from the memcached download page.
Necessity of external engine support
There are many derivative memcached software in the world, on the grounds that they want to permanently save data and achieve data redundancy, even if one
Performance. Before developing memcached, I had considered too many new inventions in Mixi's R & D department.
Memcached.
20
Idv2.com Chapter 4 Delete mechanism and development direction of memcached
The external engine's loading mechanism can encapsulate memcached's network functions, event processing, and other complex processes. Therefore
The difficulty of cooperation between memcached and the storage engine will disappear, and the attempt of various engines will change.
It's easy.
Key to successful API design
In this project, we pay the most attention to API design. Too many functions may cause engine developers to be in trouble; too complicated to implement the engine
The threshold will be too high. Therefore, there are only 13 interface functions in the original version. The specific content is limited by space, which is omitted here.
1. operations that the engine should perform:
• Engine information (version, etc)
• Engine Initialization
• Engine shutdown
• Engine statistics
• In terms of capacity, test whether a given record can be saved
• Allocate memory for the item (record) Structure
• Release item (record) memory
• Delete records
• Save records
• Recycling records
• Update the record Timestamp
• Mathematical operation Processing
• Data flush
Readers interested in the detailed specifications can check the code of the checkout engine project and the engine. h In the reader.
Review the current system
Memcached's difficulty in supporting external storage is the code (core server) related to network and event processing and the code stored in memory.
Closely related. This phenomenon is also known as tightly coupled (tightly coupled ). Code stored in memory must be removed from the core server
To support external engines flexibly. Therefore, based on our designed API, memcached is re-constructed as follows
Sub:
21
Idv2.com Chapter 4 Delete mechanism and development direction of memcached
Fig 3.1: New memcached Architecture
After reconstruction, we compared the performance with 1.2.5 and binary protocol supported versions, and confirmed that it would not affect the performance.
When considering how to support external engine loading, the most effective solution is to enable memcached to implement concurrency control.
It is easy, but for the engine, parallel control is the true meaning of performance. Therefore, we have adopted the multi-thread support
Engine Design Scheme.
Future improvements will make memcached more widely used.