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

This article mainly introduces how to expand the capacity of redis, has a certain reference value, friends in need can refer to. I hope you will learn a lot after reading this article. Next, let the editor take you to learn about it.

Option 1:

The first thing that comes to mind is to increase the number of Redis servers, perform hash operation on the stored key on the client, store it in different Redis servers, and perform the same hash operation when reading, and find the corresponding Redis server, which can solve the problem, but not good:

First, the client needs to change the code

Second, clients are required to remember the addresses of all Redis servers

This solution can be used, but can it be expanded without changing the code?

Option 2:

Build a cluster, because the Redis server uses version less than 3.0, does not support clusters, can only be used through the use of agents, think of the famous Redis proxy twemproxy.

The performance of twemproxy is also leverage drop, although it is an agent, but its impact on access performance is so small that even the Redis authors recommend it.

Twemproxy is easy to use, and for a novice, you can learn to use it in less than an hour, and the key is to support almost all Redis commands and pipe operations without changing the client code. You only need to change the IP and PORT of Redis configured in the configuration file of the client, from the original IP and Port of Redis to IP and PORT of twemproxy service.

The client does not need to think about hash, these twemproxy will do, the client is like operating a Redis.

The word "almost" is used because some commands, such as "keys *", are not supported.

Soon after the deployment of the twemproxy and the following four Redis machines, the pressure test found that the CPU utilization of the next four Redis came down, but the new problem came, twemproxy is also a single process! The performance bottleneck is on twemproxy again!

Option 3:

The access to Redis is divided into writing and reading, similar to producers and consumers. After careful analysis, it is found that there are fewer writes and relatively more reads. This can separate read and write, write to the master, and read from the backup. The situation happens to be that read and write are two services, so that the separation of read and write can be easily achieved by changing the configuration information, thus dispersing the pressure on the main Redis.

The pressure to access Redis here has improved, but it is not a long-term solution. For example, when holding an event and the amount of data increases, there will still be a performance risk.

The final approach is to integrate options 2 and 3, as shown in the following figure:

This method makes minimal changes to the existing services and can effectively alleviate the problem of redis pressure.

The hash algorithm used by the twemproxy on the producer side and the browser side is the same, otherwise the key will not be found.

If plan one is included, it will be more complicated and will not be used for the time being.

Thank you for reading this article carefully. I hope the editor will share how to expand the content of redis to help everyone. At the same time, I also hope that you will support us, pay attention to the industry information channel, and find out if you encounter problems. Detailed solutions are waiting for you to learn!

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.