In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly introduces the example analysis of Redi key management, which is very detailed and has a certain reference value. Friends who are interested must finish it!
Single key management
1. Key rename
Rename key newkey
We see that the rename command does rename the key, but if the new key already exists when the rename command is executed, then the rename command replaces the key value of the new key. This is shown in the following figure:
Of course, since it is risky to use the rename command, Redis provides the renamenx command to ensure the security of renaming the key. as the name implies, the renamenx command ensures that the rename command succeeds when the current new key does not exist.
As shown in the figure above, when the renamenx command renames the key, if the renamed key exists, the renamenx command returns 0, indicating that the current command failed, otherwise 1 indicates success.
Let's take a look at the considerations when using the rename command or the renamenx command.
Because the del command is executed to delete the old key when using the rename command or the renamenx command, blocking may occur if the value in the old key is large.
If you use the rename command or the renamenx command, if the new key is the same as the old key, the above command can be executed successfully, but the previous version of Redis3.2 will report an error.
two。 Randomly returns a key
Randomkey
3. Key expiration
Expire key seconds
Expireat key timestamp
Both the ttl command and the pttl command can query the remaining expiration time of the key, but the pttl command is more precise and can support milliseconds. Let's take a look at the return values of the ttl command and the pttl command.
An integer greater than or equal to 0: the remaining expiration time of the key (ttl seconds, pttl milliseconds).
-1: the key does not set the expiration time
-2: key does not exist
Let's take a look at the expireat command.
The expireat command can directly set the millisecond expiration timestamp of the key. In addition, the Redis2.6 version also supports millisecond expiration time.
Pexpire key milliseconds
Pexpireat key milliseconds-timestamp
Let's take a look at the considerations when using the above command.
If the key does not exist when using the above command, 0 is returned directly, indicating that the operation failed.
If the expiration time is set to a negative number when using the above command, the current key expires directly and is deleted directly, which is equivalent to executing the del command.
The persist command clears the expiration time of the key.
For keys of string type, the expiration time is removed by default when executing the set command, which is easy to ignore.
Redis does not support the expiration of elements within secondary data structures, such as the inability to set the expiration time of an element in a list or collection type.
As a combination of set and expire, setnx command is not only atomic, but also reduces the time of network communication.
4. Migration key
As the name implies, a migration key is to move a key from one place to another. For example, moving keys from the production environment to the test environment, and so on. There are three ways to support key migration in Redis, which are move, dump + restore and migrate3. But their underlying implementation and usage scenarios are not quite the same. Let's take a closer look at it.
(1), move
Move key db
The move command migrates data within Redis, and there are actually multiple databases in Redis, so the move command moves the specified key from the source database to the target database. We will introduce the knowledge related to database in Redis in the following articles.
(2), dump + restore
Dump key
Restore key ttl serialized-value [REPLACE]
Dump + restore can also implement data migration between different instances in Redis. But unlike the move command, dump + restore needs to be implemented in two parts, so let's take a look at it in detail.
Use the dump command on the source database to serialize the key values in RDB format.
Use the restore command in the target database to restore the serialized values from the previous step, where the ttl parameter indicates the expiration time, and if ttl equals 0, there is no expiration time.
Let's take a look at the considerations for the dump + restore approach.
The whole process of migration is not atomic, but is done step by step by the client.
The migration takes place on two clients, so the results of dump are not between the source and target databases.
Let's fully demonstrate how to move keys using the dump + restore command.
1) execute dump in the source Redis.
2) execute restore in the target Redis.
We enabled 2 clients in the above operation, one port is 6379 and the other port is 6380. Redis returns an error if both the dump and restore commands are in the same port client.
(3), migrate
Migrate host port key | destination-db timeout [COPY] [REPLACE] [KEYS key]
The migrate command can also realize the key migration function in Redis. Compared with the other migration commands mentioned above, the difference is that the migrate command combines dump, restore and del commands together, and simplifies the operation flow. The migrate command also supports atomic operations. Let's look at the difference between using the migrate command and the dump + restore command.
The whole process of the migrate command is atomic and there is no need to open multiple Redis clients.
The data transfer of the migrate command is done directly in the source Redis and the destination Redis.
After the destination Redis completes the restore, it will send the OK to the source Redis. After accepting it, the source Redis will decide whether to delete the corresponding key on the source Redis according to the corresponding options of the migrate.
Let's take a closer look at the relevant parameters of the migrate command.
-host: IP address of the destination Redis.
-port: the port of the target Redis.
-key | ": before the Redis3.0.6 version, migrate only supports the migration of one key, so this is the key to be migrated, but after the Redis3.0.6 version, multiple keys can be migrated, so if you currently want to migrate multiple keys, this is an empty string".
-destination-db: the database index of the target Redis, because it is mentioned above that there are multiple databases in Redis, but the relevant knowledge will be described in detail later. Here, we only need to know this concept first.
-timeout: the supermarket time of the key migration (in milliseconds).
-[copy]: if you add this option, the source key will not be deleted after migration.
-[replace]: if you add this option, migrate migrates data regardless of whether the key exists in the target Redis and overwrites it.
-[keys key [key...]]: migrate multiple keys and write as many keys as you want.
Let's demonstrate how to migrate keys in Redis through the migrate command.
1). The source Redis has a key to be migrated, but not in the destination Redis:
Let's execute the following command:
Migrate host port key | destination-db timeout [COPY] [REPLACE] [KEYS key]
When using the migrate command to migrate keys, it is important to note that when the migrate command is executed, it is executed in the source Redis, and if it is executed in the target Redis, it will not be migrated successfully, as shown in the figure above.
2), source Redis and destination Redis all have keys to migrate.
If you do not add the replace parameter when using the migrate command to migrate the key, Redis displays an error, and if you do not add the copy command, when the key migrates successfully, the migration key in the source Redis will be deleted.
3) there are no keys to migrate in the source Redis.
Let's demonstrate the operation of bulk migrating multiple keys:
Let's compare the differences of the above three kinds of key migration.
The above is all the contents of the article "sample Analysis of Redi key Management". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.