Implementation Based on Redis distributed cache

Redis is used as the cache in the project and memcache is not yet used. There are two main considerations: redis's rich data structure, its hash, list, set, and Strin with rich functions

Redis is used as the cache in the project and memcache is not yet used. There are two main considerations: redis's rich data structure, its hash, list, set, and Strin with rich functions

In brief, writing this article is a summary of your recent work. I hope it will be helpful and a little bit of accumulation.

I. Why redis?

Redis is used as the cache in the project and memcache is not used yet. There are two main considerations:

1. Support for redis's rich data structures, its hash, list, set, and function-rich strings can be of great help to actual projects. (Refer to redis. io on the official website)

2. redis single point performance is also very efficient (using project data testing is superior to memcache ).

Based on the above considerations, redis is used as the cache application.

Ii. Architecture Design of Distributed Cache

1. Architecture Design

Because redis is a single point, it must be used in projects and distributed by itself. The basic architecture diagram is as follows:

2. distributed implementation

Implements the distribution of keys corresponding to redis nodes through consistent hash of keys.

Implementation of consistent hash:

Hash Value Calculation: supports MD5 and MurmurHash Calculation Modes. By default, MurmurHash is used for efficient hash calculation.

Implementation of consistency: Simulate the ring structure through the java TreeMap to achieve even distribution

3. client Selection

Jedis is mainly used to modify the partition module so that it supports Partitioning Based on BufferKey and different redis node information. Different ShardInfo can be initialized, at the same time, the underlying implementation of the JedisPool is modified to connect to the pool to support the construction of data keys and values. Different ShardInfos are used to create different jedis connection clients, achieve the partition effect for the application layer to call

4. Module description

The dirty data processing module handles cache operations that fail to be executed.

Shield the monitoring module and monitor exceptions of jedis operations. When an exception occurs at a node, you can control operations such as redis node removal.

The entire distributed module uses hornetq to remove abnormal redis nodes. You can also use the reload method to add new nodes. (This module can be easily implemented for new nodes)

The implementation of the above distributed architecture meets the needs of the project. In addition, some redis nodes can be set separately for cache data of some important purposes to set a specific priority. In addition, the design of the cache interface can also meet the requirements to implement basic interfaces and some special logical interfaces. Cas-related operations and some transaction operations can be implemented through the watch mechanism. (Refer to redis transaction Introduction)