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

Why do you want to use Redis's multi-database? I believe many inexperienced people don't know what to do about it. Therefore, this article summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

I don't understand why we use redis's multi-database, which is just how we use it in our project. If you want to do business isolation, you can add a prefix to the cache key of different businesses. If the key is too long, you can split a large redis cluster into clusters corresponding to multiple services. No matter how many libraries are divided, the total memory size of the cluster is the same, and the amount of data that can be stored is the same, so why not split a large cluster to each business?

Since we need to do business isolation, split a large redis cluster to different businesses, and split it according to the cache size requirements of different businesses and the concurrent access volume, so as to achieve better business isolation. There is nothing wrong with isolating different databases, but if each service is not split by business, this method will cause the database to be switched every time the redis is operated in the project. For the service, the network Icano has been added innocently, which reduces the performance of cache read and write. The greater the concurrency, the more problems will be revealed, which runs counter to the tuning of high concurrent performance.

In java projects, in addition to jedis supporting dynamic database switching, using other frameworks can be achieved either by dynamically modifying the configuration of connection pools, or by configuring a connection pool for each library, which will affect performance, so jedis has become the best choice. Why do these frameworks not support dynamic switching libraries, because no one will use them in this way? obviously, dynamic switching libraries are not recommended.

I saw this post on the Redis DB forum of the Google online forum, the link: https://groups.google.com/forum/?spm=a2c4e.11153987.0.0.1d6e4e37polahb#!forum/redis-db.

The picture shows a post on tim lossen by antirez, author of redis, database names? In reply, tim lossen asked in the post why redis's multi-database does not support the use of names, but only numbers. As you can see in the figure, the reply from redis author antirez roughly means: Redis multi-database is my worst decision in Redis design. I hope that to some extent, we can give up support for multiple databases, but I think it may be too late, because a lot of people use this feature at work.

In previous redis articles, I also mentioned that when using jedis to configure connection pooling, it is recommended to turn off the configuration that sends a ping command to the server to check whether the connection is available each time a connection is obtained from the connection pool, because in high concurrency scenarios, this operation will cause the service to frequently send ping commands to the redis server, and it will also cause the service itself to consume more than one get request, because of the network get O.

The project is not split by business, resulting in serious coupling between projects, and the use of multiple databases increases the difficulty of project maintenance and communication costs between teams, and "what is key and which library is it in?" It has also become a common language in our communication. When you want to modify a key, you need to consult the teams, each project has to be modified, and when you want to add a key, you need to ask the teams if the key has been used to avoid overwriting other people's key. Of course, this is also the biggest mistake at the system architecture level. Putting aside the system architecture problems, it is obvious that whether by adding the key prefix or using multiple clusters, it is more appropriate to use different libraries to isolate the business.

After reading the above, have you figured out why you want to use Redis's multi-database? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.