Redis Distributed Locks and partitions

The following is a translation of the official website document Redlock and partition section, you can easily understand how the distributed lock in REDIS implementation and its way

Methods for Redis Partitioning

The distributed lock Redlock algorithm implemented by Redis, distributed lock, which acquires the same lock on multiple master

1.in order to get the Lock,the client get the current MS time

2. Get lock permissions for n instances sequentially (n is master), set the connection time-out when attempting to lock, prevent the instance from being hung, and the operation cannot be performed for a long time

3. Calculation in order to obtain the time of the lock consumption, and only, the client acquires more than half of the machine's lock, and the acquisition of the lock time is less than the duration of the lock, it is considered that the client acquires a lock

4. After the lock is acquired, its legal duration is: the effective time of the initial setting-in order to obtain the time of the lock consumption

5. If the client does not acquire the lock successfully for some reason, it unlocks all master instances (even if there are instances where it cannot be locked successfully)

Is the algorithm asynchronous?

The premise of the algorithm is that multiple processes or machines do not synchronize clocks, resulting in time fluctuations, inability to calculate the time to acquire locks to be prepared, or different computers, the time lapse of the speed range is very small

Redis Partition:

Benefits of Partitioning

1. Form a larger database

2. Increased computing power, using more core numbers

Basic Partitioning method

1. Scope partition, with a route table record 1-1000 which instance, 1001-2000 which instance, the disadvantage is also obvious, need routing table, key type a lot of time, need to give different types of key to different routes

2.hash partition, CRC32 (key), get a large number, use this number and Redis instance number to modulo, find the corresponding instance

3. Consistent hash Partitioning

Different implementations

1.client-Side partitioning: The client chooses the correct redis directly

2. Agent-assisted partitioning: client requests proxy,proxy forward the correct redis and returns the result to the client

3. Query routing; The client randomly sends a Redis,redis forward query to the right node, and the Redis query is routed, returning the correct Redis address, and the clients go to the correct redis fetch, but this will request redis more once.

Shortage of partitions

1. Do not provide simultaneous operation of multiple keys

2.redis transactions are not available directly

3. Partition granularity is key, if a key to save a large amount of data, partition also helpless

4. Data processing becomes complex, if you want to back up, you need to aggregate multiple instances

5. The expansion or shrinking capacity becomes complex, and the Redis cluster supports transparent rebalancing data, but the client partition, the proxy partition, cannot transparently support this feature (pre-partitioning technology can solve)

Store data? Cache?

If Redis is stored as data, then a key always needs to correspond to the same redis

Redis Distributed Locks and partitions