当前位置：网站首页>Memcached comprehensive analysis – 3 Deletion mechanism and development direction of memcached

Memcached comprehensive analysis – 3 Deletion mechanism and development direction of memcached

2022-06-24 21:27:00 【Hello，C++！】

memcached It's cache , So the data will not be permanently stored on the server , This is the introduction of... Into the system memcached The premise of . This introduction memcached Data deletion mechanism , as well as memcached The latest development direction of —— Binary protocol （Binary Protocol） And external engine support .

memcached Efficient use of resources in data deletion

Data doesn't really come from memcached Disappear in

The last time Introduced , memcached No allocated memory is released . After recording timeout , The client can no longer see the record （invisible, transparent ）, Its storage space can be reused .

Lazy Expiration

memcached Internal does not monitor whether records are out of date , But in get Check the time stamp of the record , Check if the record is out of date . This technology is called lazy（ inert ）expiration. therefore ,memcached It doesn't cost... On overdue monitoring CPU Time .

LRU： The principle of effectively deleting data from the cache

memcached Priority will be given to the space of records that have timed out , But even so , There will also be insufficient space for adding new records , Use the name Least Recently Used（LRU） Mechanism to allocate space . seeing the name of a thing one thinks of its function , This is to delete “ Recently at least use ” The mechanism of recording . therefore , When memcached When there is not enough memory space for （ from slab class When you get new space ）, Just search for records that have not been used recently , And allocate its space to new records . From the practical point of view of caching , The model is ideal .

however , In some cases LRU The mechanism can cause trouble .memcached Startup pass “-M” Parameters can disable LRU, As shown below ：

$ memcached -M -m 1024

What you have to pay attention to when starting up is , Lowercase “-m” Option is used to specify the maximum memory size . If no specific value is specified, the default value is used 64MB.

Appoint “-M” After the parameter is started , When memory runs out memcached Will return an error . Come back ,memcached It's not memory, after all , It's caching , Therefore, it is recommended to use LRU.

memcached The latest development direction of

memcached Of roadmap There are two big goals . One is the planning and implementation of binary protocol , The other is the loading function of the external engine .

About binary protocol

The reason for using the binary protocol is that it does not require parsing of the text protocol , Make the original high-speed memcached To a higher level of performance , It can also reduce the vulnerability of text protocol . At present, it has been mostly realized , This function is already included in the code base for development . memcached There is a link to the code base on the download page of .

http://danga.com/memcached/download.bml

Binary protocol format

The package of the agreement is 24 Byte frame , This is followed by keys and unstructured data （Unstructured Data）. The actual format is as follows （ From the 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/ COMMAND-SPECIFIC 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 , Occupy 16 Byte header (HEADER) It is divided into Request header （Request Header） And response headers （Response Header） Two kinds of . The header contains a that indicates the validity of the package Magic byte 、 Command types 、 Bond 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                                                        |
   +---------------+---------------+---------------+---------------+
 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 , Sure checkout Out memcached Code tree of binary protocol , Refer to docs In folder protocol_binary.txt file .

HEADER What stands out in

notice HEADER After the format, my feeling is , The upper limit of the key is too large ！ current memcached In the specification , The maximum key length is 250 byte , But the size of the key in the binary protocol is 2 The byte represents . therefore , Theoretically, the maximum available 65536 byte （2¹⁶） Long key . Even though 250 Keys larger than bytes are not commonly used , After the binary protocol is released, you can use huge keys .

Binary protocol from the next version 1.3 The series began to support .

External engine support

Last year I experimented with memcached The storage tier of has been transformed into scalable （pluggable）.

http://alpha.mixi.co.jp/blog/?p=129

MySQL Of Brian Aker After seeing this transformation , Send the code to memcached The mailing list for . memcached Developers are also very interested in , Just put it in roadmap in . Now it's up to me and memcached The developer of the Trond Norbye Collaborative development （ Specification design 、 Implementation and testing ）. Time difference is a big problem when developing with foreign countries , But with the same vision , Finally, the prototype of extensible architecture can be published . The code base can be accessed from memcached Download page Visit .

The need for external engine support

There are many in the world memcached Derivative Software , The reason is that you want to keep the data permanently 、 Realize data redundancy, etc , Even at the expense of some performance . I am developing memcached Before , stay mixi Our R & D department used to Considered reinventing memcached.

The loading mechanism of the external engine can encapsulate memcached The network function of 、 Complex processing such as event processing . therefore , At this stage, by means of coercion or redesign, etc memcached The difficulty of working with storage engines It will vanish , It will be easy to try various engines .

Simple API The key to the success of design

The most important thing in this project is API Design . Too many functions , Will cause trouble for engine developers ; Too complicated , The threshold for implementing the engine will be too high . therefore , The original version of the interface function only 13 individual . The specific content is limited to space , It's omitted here , Just describe what the engine should do ：

Engine information （ Version, etc ）
Engine initialization
The engine shuts down
Engine Statistics
In terms of capacity , Test whether a given record can be saved
by item（ Record ） Structure allocates memory
Release item（ Record ） Of memory
Delete record
Keep records
Recycling records
Timestamp of the update record
Mathematical operation processing
Data flush

Readers interested in detailed specifications , Sure checkout engine Project code , In the reader engine.h.

Reexamine the current system

memcached The difficulty of supporting external storage is , Network and event handling related code （ Core server ） And The code stored in memory is closely related . This phenomenon is also called tightly coupled（ Tightly coupled ）. The code stored in memory must be separated from the core server , To flexibly support external engines . therefore , Based on our design API,memcached Be reconstituted into the following ：

After refactoring , We and 1.2.5 edition 、 The performance of binary protocol support version is compared , It is proved that it will not cause performance impact .

When considering how to support external engine loading , Give Way memcached Parallel control （concurrency control） Is the easiest solution , But for engines , Parallel control is the essence of performance , Therefore, we have adopted the design scheme that the multithreading support is completely entrusted to the engine .

Future improvements , Will make memcached It has a wider range of applications .

summary

This time, I introduce memcached The timeout principle of 、 How to delete data internally , On this basis, the binary protocol and External engine support, etc memcached The latest development direction of . These functions should be up to 1.3 Version will support , Coming soon ！

This is my last article in this series . Thank you for reading my article ！

Nagano will introduce you next time memcached Application knowledge and application compatibility .