Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "springboot how to integrate redis to modify the partition", so the editor summarizes the following content to you, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how springboot integrates redis to modify the partition" article.

The cause of the problem of springboot integrating redis to modify Partition

Recently, using springboot to integrate redis, a system dynamic data source connects to different databases and caches the redis used, so you need to cache data from different databases to different partitions of redis, that is, different libraries.

Old version solution

The old version here refers to before 2.0. the 1.5.9 I use is ok.

The configuration class of redis is not posted here, there are many on the Internet.

1. Modify using JedisConnectionFactory

@ AutowiredJedisConnectionFactory jedisConnectionFactory;jedisConnectionFactory.setDatabase (database)

two。 Modify using redisTemplate

RedisTemplate.getConnectionFactory (). GetConnection (). Select (database)

The above two methods do not need to specifically add bean to the redis configuration class.

New version of solution

The new version here refers to those after 2.0, and I use 2.0.3.

The following bean needs to be added to the redis configuration class

@ Bean RedisStandaloneConfiguration redisStandaloneConfiguration () {RedisStandaloneConfiguration redisStandaloneConfiguration = new RedisStandaloneConfiguration (); redisStandaloneConfiguration.setHostName ("localhost"); redisStandaloneConfiguration.setPort (6379); redisStandaloneConfiguration.setDatabase (0); return redisStandaloneConfiguration;} @ Bean JedisConnectionFactory jedisConnectionFactory (RedisStandaloneConfiguration redisStandaloneConfiguration) {/ / redisStandaloneConfiguration.setPassword (RedisPassword.of (password)); JedisClientConfiguration.JedisClientConfigurationBuilder jedisClientConfiguration = JedisClientConfiguration.builder (); jedisClientConfiguration.connectTimeout (Duration.ofMillis (0)) / / connection timeout JedisConnectionFactory factory = new JedisConnectionFactory (redisStandaloneConfiguration, jedisClientConfiguration.build ()); return factory;}

Modify using RedisStandaloneConfiguration

@ AutowiredRedisStandaloneConfiguration redisStandaloneConfiguration;redisStandaloneConfiguration.setDatabase (database); redis partition

How data is distributed across multiple Redis instances

Partitioning is to distribute your data across multiple Redis instances so that each instance contains only a portion of the data.

Why is zoning useful?

The Redis partition has two main goals:

It allows for larger databases, using the sum of the memory of many computers. If you don't partition, you will be limited by the memory of a single computer.

It allows for the extension of computing power to multiple cores and multiple computers, and the extension of network bandwidth to multiple computers and network adapters.

Suppose we have four Redis instances (R0, R1, R2, R3) with many key representing users, such as user:1, user:2,... Wait, so there are many ways to store an key.

One of the simplest ways is to partition by scope, that is, to allocate data to a specified Redis instance according to the mapping scope of the object. For example, if we specify that the ID is 010000, it will be assigned to R0time1000120000 to R1, and so on. This approach is OK, but one drawback is that a table is required to maintain the mapping relationship. This table needs to be managed, and every key needs one, so range partitioning in Redis is usually unpopular because it is much less efficient than other partitioning methods.

In addition to range partitioning, another method is hash partitioning (hash partitioning):

Step 1, take the key and convert it to a number using a hash function. For example, if key is foobar, the hash function crc32, then crc32 (foobar) will output 93024922.

Step 2, use modular arithmetic (modulo) to convert this number to a direct number from 0 to 3 so that it can be mapped to one of my four Redis instances. For example, 93024922 4 = 2, so foobar should be stored on the R2 instance.

(PS: first, do a hash of the key to get a number, and then model the number to determine which instance the final data should be stored on.)

There are many other ways to partition, and you should be able to understand through the above two examples. An advanced form of hash partitioning, called consistent hashing, is implemented by several Redis clients and agents.

Different partition implementations

Client partition: for a given key, the client directly selects the correct node to read and write. Many Redis clients implement client partitioning.

Agent partition: the client sends a request to an agent, which communicates with Redis, and the agent selects the correct Redis instance according to our configuration.

Query routing: you can send your query to any Redis instance, and the instance will redirect your query to the correct server.

(PS: for a given key, the job of the partition is to select the correct Redis instance, so the selection process can be done by the client, agent, or Redis instance)

Inadequacies of zoning

1. Operations involving multiple key are usually not supported. You cannot insert a key that maps to two different Redis instances.

2. Operations involving multiple key cannot use Redis transactions

3. The partition granularity is key, so it is impossible to split the data with a single very large key (for example, a very large sorted set).

4, when using partitions, data processing will be more complex, for instances you have to deal with multiple RDB/AOF files, in order to back up data, you need to aggregate persistent files from multiple instances and hosts.

5. Adding and deleting capacity (space) becomes more complex. For example, Redis clusters support transparent data rebalancing for adding and removing nodes at run time, but other systems such as client partitions and agents do not support this feature. However, a technique called pre-slicing helps in this respect.

Data storage or caching?

When Redis is used as a data store, a given key must always be mapped to the same Redis instance. When used as a cache, it is not a big problem if a given node is not available.

If the preferred node for a given key is not available, the consistent hash implementation can usually switch to another node. Similarly, if you add a new node, some of the new keys will start to be stored on the new node.

If you use Redis as the cache, using consistent hashes is easy to scale.

If Redis is used as storage, a fixed keys-to-nodes mapping is used, so the number of nodes must be fixed and cannot be changed. Otherwise, you need a system that can rebalance key between nodes, which the current Redis cluster can do.

The above is about the content of this article on "how springboot integrates redis modified Partition". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more related knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.