I can’t figure out why we need to use the multi-database of Redis, which is used in our project. If you want to do business isolation, you can add a prefix to the cache keys of different businesses. If the keys are too long as a result, you can split a large Redis cluster into clusters for multiple businesses. No matter how many libraries are divided, the total memory size of the cluster is the same, and the amount of data can be stored is also the same. Why not split a large cluster for each business?

Since we want to do business isolation, it is better to split a large Redis cluster for different businesses to use, according to the requirements of different businesses on cache size and concurrent access to split, so as to achieve business isolation. Use different database isolation there wasn’t much trouble, but if the service is not break up of the business case, every operation in this way can lead to project a redis need to switch the database, for service, for no reason innocent added a network I/O, degrade the performance of the cache, speaking, reading and writing, the greater the concurrency value reveal, the more trouble, This is the opposite of high concurrency performance tuning.

In Java projects, with the exception of Jedis, which supports dynamic database switching, using other frameworks either by dynamically modifying the connection pool configuration or by configuring one connection pool per library affects performance, making Jedis the optimal choice. The reason why none of these frameworks support dynamically switching libraries is because no one uses them and obviously dynamically switching libraries is not recommended.

I see on Google online BBS Redis DB BBS so a post, link: https://groups.google.com/forum/?spm=a2c4e.11153987.0.0.1d6e4e37polahb#! The forum/redis – db.

Pictured here is a post by Redis author Antirez on Tim Lossen database Names? Tim Lossen asked in his post why Redis multiple databases don’t support names instead of numbers. As you can see in the picture, Redis author Antirez’s reply was to the effect that redis multi-database was my worst decision in Redis design. I hope at some point we can give up support for multiple databases, but I think it’s probably too late because there are so many people who use this feature in their work.

In previous Redis articles, I mentioned that when configuring connection pooling using Jedis, it is recommended to disable the configuration of sending a ping command to the server to check whether the connection is available each time a connection is fetched from the connection pool. In high concurrency scenarios, this operation will result in the service frequently sending a ping command to the Redis server. It can also result in the equivalent of one more GET request for the service itself because of network I/O.

The project is not separated according to business, resulting in serious coupling between projects, the use of multiple databases is more difficult to maintain the project, increased the communication cost between teams, and “what is the key, in which library? It has become a common language in our communication. When you want to change a key, you need to ask each team for their opinion, every project needs to change, and when you want to add a key, you need to ask each team if the key is used, to avoid overwriting other people’s keys, which is of course the biggest mistake in system architecture. Regardless of the system architecture, it is clear that either using a key prefix or using multiple clusters is more appropriate than using different libraries to isolate the business.