REDIS data Structure Storage dict design details (Redis design and implementation notes)

When it comes to Redis's Dict (dictionary), although the algorithm is no different from the general Dict implementation in the market, there are 2 special places in Redis's dict that is its rehash (re-hash) and its dictionary node one-way list.

Here is the structure used by dict:

typedefstructDictentry {//the node of the dictionary    void*key; Union {//the union used        void*Val; uint64_t U64;//These two parameters are usefulint64_t S64;      } V; structDictentry *next;//Next node pointer} dictentry; typedefstructDicttype {unsignedint(*hashfunction) (Const void*key);//hash function Pointer    void* (*keydup) (void*privdata,Const void*key);//key copy function pointer    void* (*valdup) (void*privdata,Const void*obj);//value copy function pointer    int(*keycompare) (void*privdata,Const void*key1,Const void*key2);//key comparison function pointer    void(*keydestructor) (void*privdata,void*key);//Key constructor Pointer    void(*valdestructor) (void*privdata,void*obj);//Value Constructor Pointer} Dicttype; /*This is our hash table structure. Every dictionary has both of this as we * implement incremental rehashing, for the old to the new table. */typedefstructdictht {//Dictionary Hash TableDictentry **table;//can be seen as a dictionary array, commonly known as bucket bucketsUnsignedLongSize//The size of the pointer array, which is the number of layers of the bucketUnsignedLongSizemask; unsignedLongUsed;//the current number of nodes in the dictionary} dictht; typedefstructdict {dicttype*type; void*privdata;//Private DataDICTHT ht[2];//Two hash table    intRehashidx;/*rehashing not in progress if rehashidx = =-1*/ //Rehash Index    intiterators;/*Number of iterators currently running*/ //the number of current dictionary iterators} dict;

Because the landlord algorithm capacity is limited: So the hash algorithm is not too deep understanding, so here algorithm is unknown to write, we are interested can Baidu.

When a hash algorithm is used to calculate the index of a k0, Redis is inserted into the specified location

When K2 and K1 appear to calculate the same key index, the Redis dictentry (the dictionary node) has a next property (single-chain table), and Redis will queue the elements of the conflicting key index to the front of the data before inserting it, thus solving the problem

Now if you insert 2 elements, and the amount of data already exceeds the load of dict, Redis will enable rehash, although it is rehash operation but Redis is a progressive operation, not all of a sudden memory is not enough to directly manipulate the memory, and then transfer the data, This can lead to a time-consuming operation, and Redis takes this into account and

First Ht[1] Another dict structure to expand a number of ht[0].used*2 dictentry array, and then the 2 data through the hash algorithm added to the array.

And then the above elements asynchronous gradually moved to the following array, in this process if the client to manipulate the element, if the ht[0] in the check can not find the build, will go to check ht[1] whether there is a specified key, so as not to affect the use of data, And you can avoid the time-consuming problems caused by the one-off operation Rehash, and finally Reshash finished, the ht[1] and ht[0] switch positions and empty the deprecated hash node array to complete all operations.

REDIS data Structure Storage dict design details (Redis design and implementation notes)