• string
  • The dictionary Hash
  • list
  • Set the set
  • An ordered set
  • HyperLogLog
  • Geo
  • Pub/Sub

string

Get/set the scene:

  • session
  • Data caching in general
  • counter
  • A distributed lock

Bottom implementation: based on SDS data structure, and did not use pure C language string. The reason:

  1. C language string length traversal
  2. C strings add/subtract design redistribution
  3. Cannot save binary information such as pictures
C string SDS
The complexity of getting string length is O(N). The complexity of getting string length is O(1).
The API is not secure and may cause buffer overflows. The API is secure and does not cause buffer overflows.
Changing the string length N times requires N memory reallocations Changing the string length N times requires a maximum of N memory reallocations.
Only text data can be saved. Can save text or binary data.
You can use all the functions in the <string.h> library. You can use some of the functions in the <string.h> library.

The dictionary Hash

hget/hset/hgetall

Scene:

  • Can be intuitive, more space saving than string, the maintenance of cache information, such as user information, video information, etc..

Rehash:

  • When the BGSAVE/BGSAVEAOF command is not executed, set the load factor to 1
  • When executing BGSAVE/BGSAVEAOF commands, the load factor is increased by =5 to avoid memory consumption, because during executing BGSAVE or BGREWRITEAOF commands, Redis needs to create child processes of the current server process. Most operating systems use copy-on-write technology to optimize the use of subprocesses, so the server increases the load factor required to perform the extension operation during the existence of the subprocess, thus avoiding the hash table extension operation during the existence of the subprocess as much as possible. This avoids unnecessary memory writes and maximizes memory savings.
  • Hash function: murmurhash2

Progressive rehash:

Because the dictionary uses both THE HT [0] and HT [1] hash tables during progressive rehash, the dictionary deletes, finds, updates, and so on on both hash tables during progressive rehash: For example, to look for a key in a dictionary, the program looks in HT [0] first, and if it doesn’t find one, it continues to ht[1], and so on. In addition, during progressive rehash, new key-value pairs added to the dictionary are stored in HT [1] and ht[0] does not add any more: This ensures that the number of key-value pairs contained in HT [0] will only decrease, and eventually become empty as the rehash operation executes.

An ordered set

The underlying implementation is skip lists

Redis skip table data structure

Skip table add node, delete node skip table principle