Redis is powerful, rich in data types, and even a fast system can’t stand crazy abuse. By disabling some high-risk features and shackling development, businesses are more able to think in a concise, generic way, rather than being tied to an implementation.

Redis has different persistence and eviction policies depending on its use. Therefore, before using and applying for a Redis cluster, make sure that it is used for caching or storage. Redis cluster has two modes, master/slave and Cluster, each of which has its advantages and disadvantages. The following specifications do not distinguish between clustering patterns, and are described in terms of usage scenarios and operation restrictions.

Use standard

Cold and hot data differentiation

Although Redis supports persistence, it is very expensive to store all data in Redis. It is recommended that hot data (such as QPS over 5K) be loaded into Redis. Low-frequency data can be stored in Mysql and ElasticSearch.

Separation of business data

Don’t put all your unrelated data businesses in one Redis. On the one hand, services are not affected by each other. On the other hand, single instance expansion is avoided. In addition, the impact level is reduced and the fault recovery is rapid.

Message size limit

Because Redis is a single-threaded service, too many messages can block and slow down other operations. It’s a good habit to keep message content under 1KB. A single record larger than 50KB is prohibited. Too large messages will also cause a high occupation of network bandwidth, persistent DISK IO problems.

Connection number limit

The frequent creation and destruction of connections can waste a lot of system resources and cause host machine failure in extreme cases. Make sure you use the correct Redis client connection pool configuration.

The expiration time of the cache Key is set

As a Key used for caching, the expiration time must be set. The longer the validity period is, the better. Set the validity period according to the service nature. Note that the unit of failure time is either seconds or milliseconds, which many students do not pay attention to easy to mistake.

Caches cannot have intermediate states

The cache should only be used for caching, and the business logic should not change after it is removed. First, the high availability of the cache affects the business. Second, creating deep coupling can have unexpected effects; Third, it will have skin effect on maintenance line.

Client hash is preferred for extension

Forget the small apps

If a single Redis Cluster does not serve your data, do not rush to expand your Redis Cluster (including M/S and Cluster), the larger the Cluster, the worse the performance in terms of state synchronization and persistence. Client hash is preferred for cluster splitting. For example, the user id is divided into 10 clusters. The user whose id ends with 0 falls into the first cluster.

Operating limits

Keys are strictly prohibited

The Keys command is an O(N) operation that is inefficient and blocks other normal commands. On a cluster, it is a disastrous operation. Do not use this command. The DBA should rename this command and disable it from the root.

Do not use Flush

The flush command clears all data, which is a high-risk operation. Do not use this command. The DBA should rename this command and disable it from the root. Only the DBA can operate this command.

Do not use as a message queue

Use of Redis as a message queue is strictly prohibited without very special requirements. When Redis is used as a message queue, there are multiple issues of capacity, network, efficiency, and functionality. If you need message queues, you can use high-throughput Kafka or highly reliable RocketMQ.

Batch operations without a specified range are prohibited

Redis is such a fast, slow query in addition to network latency, is one of these batch operation functions. Most online problems are caused by these functions.

1. [ZSET] It is strictly prohibited to operate zSET without setting the range

ZRANGE, ZRANGEBYSCORE and other functions that operate ZSET are strictly prohibited to use ZRANGE myzSet 0-1 and other functions that do not set the range. Specify a range, such as ZRANGE myzset 0 100. If you are not sure about the length, use ZCARD to determine the length

2. [hash] Do not use HGETALL for keys with large data volumes

HGETALL retrieves all HASH data. If the number of HASH data is too large, the block will also occur. Ensure that the service is controllable. If the length is uncertain, use HLEN to determine the length first

3. [key] Redis Cluster MGET operation of the Cluster

The MGET operation of Redis Cluster will fetch data from each fragment for aggregation. Compared with the traditional M/S architecture, the performance will be much lower. Please test and evaluate in advance

4. [Others] Sunion, sinter, sdiff and other aggregation operations are strictly prohibited

Disabling the SELECT function

The select function is used to switch between databases. This can be a problem for users. Cluster mode does not support multiple databases and has no benefits.

Disable the transaction

Redis itself is already fast, so it is recommended to catch exceptions and roll back if not necessary, rather than using transaction functions, which is rarely done.

Disable lua script extensions

Lua scripts can do a lot of cool looking things, but they are like SQL stored procedures, introducing performance and some difficult maintenance issues, and are disabled.

Disable the monitor for a long time

The monitor function can quickly see the current flow of data being executed by Redis, but be careful if a long period of peak time is blocked on the monitor command, which can seriously affect Redis performance. This command is not prohibited, but must be used with special care.

The Key specification

Redis keys must be standardized so that problems can be easily located. Redis is a scheme-free KV database, so we establish its scheme semantics by convention. The benefits:

1. Data can be cleaned according to certain keys

2. Data can be updated according to certain types of keys

3. Know the owner and application scenario of a certain type of key

4. Prepare for unification and platformization and reduce technical changes

Generally, a key must have the following dimensions: service, key usage, and variables. The following are several key examples:

User :sex user 10002232 gender MSG: ACHI 201712 number of user comments ranking

End

Appropriate constraints are the necessary conditions for mature architecture, and achieving specifications by convention is the highest level of collective development. Redis use much, also want to use steady, give some constraints, establish some rules, life will become beautiful. Through secondary encapsulation of redis client, direct blocking, the effect is better.

More excellent articles.

Microservices are not all, just a subset of a particular domain. With so many monitoring components, there is always one that fits your “library and list”? Be careful with the selection and process, or you’ll get out of control. What are we really developing with Netty? The most common set of “vim” techniques used in Linux production environments

Linux five-piece or something.

Linux “Cast Away” (1) Preparation for Linux “Cast Away” (2) CPU Linux “Cast Away” (3) memory Linux “CAST Away” (4) I/O Linux “Cast Away” (5) network