Redis Notes 01

The content of this article is excerpted from the design and implementation of Redis

Simple dynamic string

1. Redis has built itself as an abstract type named simple dynamic string String,sds, and SDS is used as the default string representation of Redis

2. SDS attribute:

1). Free: Unused space

2). Len: The length of the saved string

3). Buf:char type array, the string holds the contents, the last byte is a null character ' \ s '

3. SDS follows the Convention that the C string ends with an empty string, and the 1-byte space that holds the null character is not counted in the Len attribute of the SDS. The advantage of following an empty string convention is that SDS can directly reuse a subset of functions in the C string function library.

4. The difference between SDS and C string:

1). C String Gets the complexity of the length of the string O (N), SDS gets the complexity of the string length O (1)

2). The C string API is unsafe and may cause a buffer overflow. The SDS API is secure and does not cause a buffer overflow.

3). C String to modify the length of the string n times must be performed n this memory allocation. SDS modifies the string length n times to perform a maximum of n this memory reallocation. SDS reduces the number of memory re-allocations that are caused by modifying strings:

A. Space pre-allocation

B. Inert Space release

4). The C string can only hold text data. SDS can be saved or binary data.

5). SDS can only be compatible with some C string functions

5. Binary security: With Hot Press the database is generally used to hold text data, but the scenario of using a database to hold binary data is not uncommon. To ensure that Redis can be used in a variety of different usage scenarios, SDS APIs are binary safe,

All SDS APIs deal with the data stored in the BUF array in a binary way. The program does not make any restrictions, filters, or assumptions about what data is written and what kind of reading it is.

Linked list:

The features of the Redis list implementation can be summarized as follows:

1. Double-ended: The list node has prev and next pointers, the complexity of getting the front and back nodes of a node is O (1)

2. No ring: The prev pointer of the table head node and the next pointer of the footer node all point to null, and access to the linked list is null for the node.

3. With the head pointer and the footer pointer: through the head pointer and the tail pointer of the list structure, the program obtains the complexity of the table head node and footer node of the linked list as O (1)

4. With linked list Length counter: The program uses the Len property of the list structure to count the list nodes that are held by lists, and the program gets the number of nodes in the linked list as complex as O (1)

5. polymorphic: The linked list node uses the void* pointer to hold the node value, and the list structure of the DUP, free, match three properties for the node value set type-specific functions, so the list can be used to hold a variety of different types of values.

6. Linked lists are widely used in various functions of redis, such as List key, publish and subscribe, slow query, monitor, etc.

Dictionary:

1. A dictionary, also known as a symbol table, an associative array or a map, is an abstract data structure used to hold key-value pairs.

2. The Redis dictionary uses a hash table as the underlying implementation, and a hash table can have multiple hash table nodes, and each hash table node holds a key-value pair in the dictionary.

3. Dictionaries are widely used to implement various functions of redis, including databases and hash keys.

4. The dictionaries in Redis use the dark system as the underlying implementation, with each dictionary with two hash tables, one for normal use and the other only for rehash use.

5. Hash tables Use the chaining address method to resolve key conflicts, and multiple key-value pairs that are assigned to the same index are concatenated into a one-way list. The latest key values are at the top for easy access.

6. When extending or shrinking a hash table, the program needs to rehash all the key-value pairs contained in the existing hash table into the new hash table, and the rehash process is not done at once, but incrementally.

7. Because in the process of progressive rehash, the dictionary uses both ht[0] and ht[1] Two hash tables, all during progressive rehash, the delete, find, update, and so on of the dictionary will be done on two hashes. First find ht[0], and then find Ht[1].

Also, during progressive rehash, the new key-value pairs added to the dictionary are saved to ht[1].

8. Expansion and contraction of the hash table:

To perform an extended operation when any of the conditions are met:

1). The server is currently not executing the bgsave or bgrewriteaof command, and the hash table has a load factor greater than or equal to 1.

2). The server is currently executing the bgsave or bgrewriteaof command, and the hash table has a load factor greater than or equal to 5

On the other hand, when the load factor of a hash table is less than 0.1, the program automatically begins a shrink operation on the hash table.

Jumping table:

1. The jump table is a variety of sequential data structures, which can achieve fast access to nodes by maintaining multiple pointers to other nodes in each node.

2. Redis has only two places for jumping tables: one is to implement an ordered set key, and the other is to use the internal data structure in the cluster node.

3. Jumping tables are one of the underlying implementations of an ordered set.

4. The Redis jump table implementation consists of the zskiplist and Zskiplistnode two structures, where zskiplist is used to hold the jump table information (such as the header node, footer node, length), while Zskiplistnode is used to represent the jumping table node.

5. The layer height of each jumping table node is a random number between 1 and 32.

6. In the same jump table, multiple nodes can contain the same score, but the member objects of each node must be unique.

7. The nodes of the jumping table are sorted by the score size, and when the scores are the same, the nodes are sorted by the size of the member objects.

Redis Notes 01