Development and O&M Rules

This section describes usage rules of the GeminiDB Redis database based on Huawei's years of experience in cloud database development and O&M, so as to help you effectively evaluate and improve service system stability.

Development Rules

When developing a service program, you need to pay attention to the following development rules to prevent service instability caused by improper usage.

**Table 1** Development rules of GeminiDB Redis
No.	Development Rules	Description
1	The service program must have a proper automatic reconnection mechanism.	In scenarios for the specification change, patch upgrade, HA switchover, network link jitter, or packet loss, the connection between the service program and the DB instance may be interrupted for a short period of time. The service program must support automatic reconnection. NOTE: Use Jedis instead of Lettuce because Lettuce is not automatically reconnected after multiple requests time out.
2	Provide a connection pool and configure sufficient connections for a service program.	To prevent the program from failing to obtain connections when the number of concurrent requests increases sharply, you are advised to use a connection pool for the service program and configure proper connection pool parameters. For details about the recommended configuration of the connection pool of the client, see Configuring Parameters for a Client Connection Pool.
3	The service program must have a proper command retry mechanism for important operations.	When the connection is interrupted or the request times out, requests from the service program may fail to be executed within a short period of time. Therefore, a service fault tolerance mechanism is needed. Proper command retry intervals and times can ensure important data is successfully written or modified.
4	A correct HA connection address needs to be used to prevent services from being affected by a single point of failure.	When connecting a service program to a database through a private network, use a load balancer IP address to achieve HA. Do not directly connect the service program to an independent compute node. NOTE: If a database is accessed from a public network, do not directly connect the service program to an independent compute node.
5	A connection pool needs to be used to avoid using a single connection or a large number of short connections.	A single connection has HA risks. The performance of short connections is poor, and short connections consume a large number of CPUs and network resources, may causing performance bottlenecks. Therefore, you are advised to use mainstream SDK connection pools to connect a service program to GeminiDB Redis instances.
6	You are not allowed to run the KEYS command when there are more than 1,000 keys in an instance.	The KEYS command is a typical high-risk command. It obtains all data in the entire instance at a time and returns the data to the client. If there are a large number of keys in an instance, running the KEYS command will block requests or make the instance unavailable.
7	Do not set element values to excessively large or small values and ensure the number of elements contained in a single key is not too large.	According to best practices, the size upper limit of a string key is 10 KB, the number of elements in a Hash, List, Zset, or Set key should be less than 5,000, and the size of a single element should be 1 KB or smaller. NOTE: Similar to the community Redis, GeminiDB Redis does not strictly restrict the storage of big keys. Therefore, you need to develop service programs within the rule scope.
8	A single command does not contain many elements at a time. Too large network packets cannot be generated by a single command.	It is recommended that no more than 1000 keys be concurrently operated using MSET or MGET. Make sure that no more than 1000 key elements to be concurrently operated using HMSET, HGETALL, LRANGE, ZADD, or ZRANGE. The limit parameter is not included in the Redis ZREMRANGEBYSCORE command, so the number of elements to be deleted at a time cannot be limited. You are advised to use ZRANGEBYSCORE (with limit) + ZREM instead. NOTE: Similar to the community Redis, GeminiDB Redis does not strictly restrict the access to big keys. Therefore, you need to develop a service program within the rule scope.
9	Properly distribute keys to avoid performance bottlenecks in hotspot keys or hash tags.	Frequent access to a single key or a group of keys with the same hash tags may cause hot key problems, which may cause bottlenecks such as compute resource skew, request queuing, and slow response. Hot keys are usually created due to insufficient key splitting in service design. Therefore, service splitting needs to be optimized. NOTE: Negative examples: Ultra-large global rankings are accessed frequently and intensively. Several hash keys are stored in an instance. Each key is used to store information of the entire table. For product inventory, there are only a small number of bucket hash tags for all keys. As a result, requests for querying hot hash tags may queue.
10	Run less than 300 packaging commands at a time using the pipeline.	Do not include a large number of commands in a pipeline. Using pipelines improperly may cause bottlenecks in CPU and bandwidth resources and block requests. NOTE: Compared with the community Redis, GeminiDB Redis does not strictly restrict the use of pipelines. Therefore, you need to develop a service program within the rule scope.
11	Do not use time-consuming code in Lua scripts.	When using LUA scripts, excessive command execution times and time-consuming statements such as long-time sleep and large loop statements should be avoided.
12	Do not pack too many commands in a transaction.	When using a transaction, do not pack too many commands or complex commands in a single transaction. If a transaction contains too many commands, requests are blocked, or the instance may become abnormal.
13	Different data types cannot use the same key.	The community Redis allows no use of the same key in different data types. Although GeminiDB Redis has no requirements for this, avoid using the same key in different data types during program development to ensure the program is clear and easy to maintain.

O&M Rules

During routine O&M, you need to pay attention to the following O&M rules to prevent potential risks and master key emergency solutions.

**Table 2** O&M rules of GeminiDB Redis
No.	Rule	Description
1	Ensure that the phone number and email address bound to your Huawei Cloud account are valid so that you can receive notifications in a timely manner.	Huawei Cloud will send notifications to you through websites, emails, SMS messages, or internal messages in scenarios for changes, upgrades, and fault notifications. Ensure that the contact information bound to your account is valid.
2	Subscribe to major alarms.	You can subscribe to alarms such as big key access, high storage utilization, high connection usage, and high CPU usage to detect and handle instance risks in a timely manner. For details, see Configuring Alarm Rules.
3	When the LB address is used for access, you need to configure access control instead of security groups.	A load balancer address does not support security groups. After instance creation is complete, configure IP address access control. If no whitelist is configured, all IP addresses that can communicate with the VPC can access the instance.
4	Configure autoscaling for instances.	GeminiDB Redis supports autoscaling, which effectively prevents sudden data volume surge. Enable autoscaling by referring to Configuring Autoscaling.
5	Keep the load at the healthy level.	If the service data volume is greater than 80% for a long time, you are advised to expand the capacity in a timely manner. If the service traffic exceeds the QPS limit of an instance or the CPU usage maintains 80% or more for a long time, upgrade the specifications or add nodes to prevent overloading and affecting service access. When the instance computing power is overloaded due to the sharp increase of service traffic and the number of connections, you can add nodes to quickly improve the cluster computing power. Scaling up CPU cores is performed in rolling mode and takes a long time, which is not recommended in emergency scenarios.
6	Rename high-risk commands.	Disable or rename high-risk commands such as FLUSHALL, or KEYS to enhance instance security. For details, see Renaming Commands.
7	Perform periodical online diagnosis of big keys.	You can periodically view the big key diagnosis report of the instance on the console to view keys that are the most frequently accessed in the Redis database. For details, see Big Key Diagnosis.
9	Run the DBSIZE command after data migration.	Running DBSIZE can ensure data consistency. For example, if there are no expired keys, you can run DBSIZE several minutes after data is imported to obtain the accurate number of keys and ensure data consistency.