Redis advanced

Redis

1. data structure

1. character string （String）
2. Linked list （List）
3. Hash （Hash）
4. aggregate （Set）
5. Ordered set （Zset）

2. Persistence strategy

redis It's a memory database , A little bit is reading data fast , The disadvantage is data volatility , Memory data disappears after power failure .

Solution ：

1. RDB（Redis Data Base）

principle ： hold redis Generate a snapshot of the data in memory （RDB file ） Save on hard disk .

Manual trigger

1. save command , Main thread execution rdbsave function , The server process is blocked .

2. bgsave command ,fork A child process to execute rdbsave function . The server process will not block .

Automatic triggering

Write... In the configuration file save m n, Representative as m Occurs inside n Time of change , Will execute bgsave

2. AOF（Append Only File）

principle ： Record all pairs after redis Modify the data . adopt AOF File executes the command recovery in the file .

Manual trigger

1. bgrewriteaof

Automatic triggering

1. Set... In the configuration file appendonly yes Turn on
2. Write strategy （always、everysec,no）, Default everysec

3. cache

1. Cache obsolescence

• fifo FIFO
• Recently at least use LRU
• The least used LFR

2. Cache delete

• Active delete
• Lazy deletion
• Delete regularly

3. Cache consistent

CacheAside

• Model a （ Delete the cache before updating data . problem ： Reading is faster than writing , Another client reads the database even if the cache fails , It is also possible to read old data ）
• Model 2 （ Update the data first , Delete the cache . problem ： Because of the Internet 、 There is a small probability of program problems, reading old data ）

Solution ： Delay double delete （ Delete cache , Update data , Delete cache again ）

Read/Write Throuth

The core is to use cache as the main data reading method , Avoid cache breakdown .（ Do not delete cache , Instead, update the cache directly ）

Write Behind

CacheAside and Read/Write Throuth All are deleted synchronously 、 Synchronous update cache . There is a delay problem .

Write Behind The core is asynchronous processing

• utilize MQ Asynchronous execution
• simulation mysql Master slave copy

4. Cache breakdown

Definition ： Query the value of a data , This value is no longer cached , There is... In the database .

problem ： If the query volume of this value is suddenly very large , Because there is no data in the cache , All requests will be sent to the back-end database .

Solution ：

• mysql angle ： Reduce direct traffic
• redis angle ： Set the data not to expire ; Asynchronous thread refresh expiration time

5. Cache penetration

Definition ： Query the value of a data , This value is no longer cached , There is no .

Solution ：

1. Intercept illegal query requests
2. Caching empty objects
3. The bloon filter

6. Cache avalanche

Similar to cache breakdown , Cache breakdown is a single point , Cache avalanche is multipoint . It often happens when the service is started

Solution ：

• mysql angle ： Reduce direct traffic
• redis angle ： Set the data not to expire ; Scattered failure time points ; Cache preheating .

4. colony

1. Master slave copy

The main library is responsible for executing the write command 、 Synchronize data to the slave Library

The slave library is responsible for executing the read command

2. sentry

Sentinel system （ Similar service registries ）

3. cluster （ Partition ）

Partitioning is dividing data into multiple Redis The process of the instance , So each instance only saves key A subset of .

5. Distributed lock

1） Mutual exclusivity

Only one client can acquire the lock at any time .

This is easy to understand , Only one system in all systems can hold locks .

2） Anti deadlock

If a client crashes while holding a lock , No release lock , Then other clients can't get locks , It will cause deadlock , So make sure that the client will release the lock .

Redis We can set the expiration time of the lock to ensure no deadlock .

3） Lock holder unlocking

He who breaks the bell must tie the bell , Lock and unlock must be the same client , client A The lock added by the thread of must be the client A To unlock , The client cannot unlock other clients .

4） Reentrant

When a client acquires an object lock , This client can get the lock on this object again .

Code example

setnx k v
#  Business 
del k

set k v ex 10 nx
#  Business 
del k

--  Get the thread ID in the lock , Dynamically passing parameters 
local keyName = redis.call('get',KEYS[1])
--  Compare whether the thread flag and the in the lock are always 
if (ARGV[1] == keyName) then
   --  Release the lock 
    redis.call('del',KEYS[1])
    return 1
     --  If it's not consistent , Then the returned result is 0
else
    return 0
end