Developing applications with Redis is a pleasant process, but like any other technology, there are a few things you need to keep in mind when designing Redis-based applications. Before, you may already know the whole routine of relational database development, and Redis-based application development has many similarities, but you must keep the following two points in mind - Redis is an in-memory database, and it is single threaded. Therefore, when using Redis, you need to pay attention to the following points:
1. Control all keys stored in Redis
The main function of the database is to store data, but it is normal for developers to ignore some data stored in the database because of changes in application requirements or data usage methods, and the same is true in Redis. You might ignore certain keys that expire, or you might forget the data because a module in your application is deprecated.
In either case, Redis stores some data that is no longer used, taking up some space for no reason. Redis' weakly structured data model makes it hard to figure out what's stored centrally unless you use a very mature naming convention for keys. Using proper naming will simplify your database management. When you namespace your keys through your application or service (usually using colons to delimit the key names), you can use it during data migration, transformation, or deletion. easy identification.
Another common use case for Redis is as a secondary data store for hot data items, where most of the data is stored in other databases such as PostgreSQL or MongoDB. In these use cases, developers often forget to delete the corresponding data in Redis when data is removed from primary storage. In the case of cross-data storage, cascading deletion is usually required. In this case, it can be achieved by saving all identifiers of specific data items in the Redis configuration, so as to ensure that after the data is deleted in the main database, the system will A cleaner is invoked to remove all relevant copies and information.
2. Control the length of all key names
We said above about using proper naming conventions and adding prefixes to identify where the data goes, so this one seems to go against it. However, don't forget that Redis is an in-memory database, and the shorter the keys, the less space you need. Of course, when there are millions or billions of keys in the database, the length of the key names can matter a lot.
For example: on a 32-bit Redis server, if you store 1 million keys, each value is 32-character in length, then when using 6-character length key names, it will consume about 96MB of space, However, if a 12-character key name is used, the space consumption will increase to about 111MB. With more keys, the 15% extra overhead will have a significant impact.
3. Use appropriate data structures
Whether it is memory usage or performance, sometimes the data structure will have a big impact. Here are some best practices to refer to:
Instead of storing data as thousands (or millions) of individual strings, consider using a hash data structure to group related data. Hash tables are very efficient and can reduce your memory usage; at the same time, hashing is more beneficial for detail abstraction and code readability.
When appropriate, use list instead of set. If you don't need to use the set feature, List can provide faster speed than set while using less memory.
Sorted sets are the most expensive data structures, both in terms of memory consumption and complexity of basic operations. If you just need a way to query records and don't care about properties like sorting, then it is recommended to use a hash table.
An often overlooked feature in Redis is bitmaps or bitsets (after V2.2). Bitsets allow you to perform multiple bit-level operations on Redis values, such as some lightweight parsing.
4. Do not use keys when using SCAN
Since Redis v2.8, the SCAN command has been available, which allows keys to be retrieved from the keyspace using a cursor. Compared with the KEYS command, although SCAN cannot return all matching results at one time, it avoids the high risk of blocking the system, so that some operations can be performed on the master node.
Note that the SCAN command is a cursor-based iterator. After each SCAN command is called, a new cursor will be returned to the user, and the user needs to use this new cursor as the cursor parameter of the SCAN command in the next iteration, so as to continue the previous iteration process. At the same time, using SCAN, the user can also use the keyname mode and count options to adjust the command.
SCAN-related commands also include SSCAN commands, HSCAN commands and ZSCAN commands, which are used for sets, hash keys, and sequels, respectively.
5. Using server-side Lua scripts
In the process of using Redis, the support of Lua script will undoubtedly provide developers with a very friendly development environment, thus greatly liberating the creativity of users. When used properly, Lua scripts can bring very large improvements in performance and resource consumption. Instead of sending data to the CPU, scripts allow you to execute logic closest to the data, reducing network latency and redundant data transfers.
A very classic use case for Lua in Redis is data filtering or aggregating data into applications. By encapsulating the processing workflow into a script, you only need to call it to get a smaller answer in less time and with few resources.
Pro tip: Lua is really great, but it also has some problems, like it's hard to report and handle bugs. A sensible approach is to use Redis' Pub/Sub functionality and have the script push log messages through a dedicated channel. Then create a subscriber process and process accordingly.