Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive
On this page

Development and O&M Rules

Updated on 2025-01-24 GMT+08:00

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, which may cause 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 100 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.

14

Exercise caution when running batch deletion commands.

Do not delete too much data (tens or hundreds of thousands of elements) of the LIST and ZSET types via a single batch deletion command (for example, LREM, LTRIM, and ZREMBYSCORE). Deleting a large amount of data may take a long time, affecting other commands. Processes causing OOM may restart and the instance may be abnormal. In extreme scenarios, service processes may fail to be started repeatedly.

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 instance storage can be automatically scaled up in case of a sudden surge in data volumes. Enable autoscaling by following Automatically Scaling Up Disk Space.

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

Exercise caution when performing the FLUSHALL operation during account management.

  • When an IAM user with the read and write permissions executes FLUSHALL, all data on the instance is cleared.
  • Do not perform FLUSHALL. You can perform FLUSHDB after confirming the database. Exercise caution when performing this operation.

8

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.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback