ApsaraDB for Redis:Features of ApsaraDB for Redis 4.0

Lazyfree

Redis 4.0 supports the Lazyfree feature. This feature can avoid congestion on the Redis-server caused by the DEL, FLUSHDB, FLUSHALL and RENAME commands and ensure service stability. The following sections describes this feature.

unlink

For versions that are earlier than Redis 4.0, OK is returned only after all memory resources of a key are released when the DEL command is run. If the key contains a large amount of data, such as 10 million entries in a hash table, other connections may remain pending for a long time period. To be compatible with the existing DEL syntax, Redis 4.0 uses the UNLINK command. The UNLINK command can be used in the same way that you use the DEL command. However, the background thread releases the memory when Redis 4.0 runs the UNLINK command.

UNLINK key [key ...]

flushdb/flushall

The FLUSHDB and FLUSHALL commands in Redis 4.0 allow you to specify whether to use the Lazyfree feature to release the memory.

FLUSHALL [ASYNC]
FLUSHDB [ASYNC]

rename

When you run the RENAME OLDKEY NEWKEY command, if the specified new key exists, Redis first deletes the existing new key. If the key contains a large amount of data, other connections remain pending for a long time period. To use the Lazyfree feature to delete the key, set the following configuration in the console:

lazyfree-lazy-server-del yes/no

Expire or evict data

You can specify data expiration time and allow Redis to delete expired data. However, CPU jitter may occur when a large expired key is deleted. Redis 4.0 allows you to specify whether to use the Lazyfree feature to expire or evict data.

lazyfree-lazy-eviction yes/no
lazyfree-lazy-expire yes/no

New commands

swapdb

The SWAPDB command is used to swap two Redis databases. After you run the SWAPDB command, you can query the new data from the other database without executing the SELECT statement.

127.0.0.1:6379> select 0
OK
127.0.0.1:6379> set key value0
OK
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set key value1
OK
127.0.0.1:6379[1]> swapdb 0 1
OK
127.0.0.1:6379[1]> get key
"value0"
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> get key
"value1"

zlexcount

The ZLEXCOUNT command is used to return the number of elements in a sorted set. The ZLEXCOUNT command is similar to the ZRANGEBYLEX command. However, the ZRANGEBYLEX command returns all the elements in the sorted set.

memory

Versions that are earlier than Redis 4.0 use the INFO MEMORY command to provide the memory information. Redis 4.0 allows you to run the MEMORY command to obtain further information about the memory status.

127.0.0.1:6379> memory help
1) "MEMORY DOCTOR                        - Outputs memory problems report"
2) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key"
3) "MEMORY STATS                         - Show memory usage details"
4) "MEMORY PURGE                         - Ask the allocator to release memory"
5) "MEMORY MALLOC-STATS                  - Show allocator internal stats"

• memory usage

  The USAGE child command is used to view the memory usage of a specified key in Redis.

  Notice

  • Key-value pairs in Redis consume memory. Redis also consumes memory to manage data.
  • The memory usage of keys such as hash tables, lists, sets, and sorted sets is calculated based on sampling. The SAMPLES command is used to specify the number of samples.

• memory stats

  27.0.0.1:6379> memory stats
         1) "peak.allocated"    // The maximum memory that Redis used after startup.
         2) (integer) 423995952
         3) "total.allocated"    //The current memory usage.
         4) (integer) 11130320
         5) "startup.allocated"    //The memory that Redis uses after startup and initialization.
         6) (integer) 9942928
         7) "replication.backlog"    //The amount of memory of the backlog used in resuming an interrupted master-replica replication. Default value: 10 MB.
         8) (integer) 1048576
         9) "clients.slaves"    // The amount of memory used in a master-replica replication.
        10) (integer) 16858
        11) "clients.normal"    //The amount of memory used by read and write buffers for common clients.
        12) (integer) 49630
        13) "aof.buffer"    //The sum of the cache used for append-only file (AOF) persistence and the cache generated during the AOF rewrite operations.
        14) (integer) 3253
        15) "db.0"    //The memory used by metadata in each database.
        16) 1) "overhead.hashtable.main"
            2) (integer) 5808
            3) "overhead.hashtable.expires" //The memory used to manage the data that has TTL configured.
            4) (integer) 104
        17) "overhead.total"    //The total used memory for the preceding items.
        18) (integer) 11063904
        19) "keys.count"    //The total number of keys in the current storage.
        20) (integer) 94
        21) "keys.bytes-per-key"    //The average size of each key in the current memory.
        22) (integer) 12631
        23) "dataset.bytes"        //The memory used by user data (= Total memory - Memory used by Redis metadata).
        24) (integer) 66416
        25) "dataset.percentage"    //100 * dataset.bytes / (total.allocated - startup.allocated)
        26) "5.5934348106384277"
        27) "peak.percentage"    // 100 * total.allocated / peak_allocated
        28) "2.6251003742218018"
        29) "fragmentation"    //The memory fragmentation ratio.
        30) "1.1039986610412598"

• memory doctor

  This command is used to provide diagnostics and identify potential issues.

  Peak memory: peak.allocated/total.allocated > 1.5. This indicates that the memory fragmentation ratio may be high.
    High fragmentation: fragmentation > 1.4. This indicates a high memory fragmentation ratio.
    Big slave buffers: the average memory for each replica buffer is more than 10 MB. This may be caused by high traffic of write operations on the master node.
    Big client buffers: the average memory for a common client buffer is more than 200 KB. This may be caused by the improper use of a pipeline or caused by Pub/Sub clients that delay processing messages.

• malloc stats & malloc purge

  Both commands take effect only when you use jemalloc.

Least Frequently Used (LFU) mechanism and hotkeys

Redis 4.0 supports allkey-lfu and volatile-lfu data eviction policies, and allows you to run the OBJECT command to obtain the frequency of use for a specific key.

object freq user_key

Based on the LFU mechanism, you can run the SCAN and OBJECT FREQ commands to find hotkeys. You can also use the Redis command-line interface (redis-cli) as shown in the following example.

$./redis-cli --hotkeys
# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Hot key 'counter:000000000002' found so far with counter 87
[00.00%] Hot key 'key:000000000001' found so far with counter 254
[00.00%] Hot key 'mylist' found so far with counter 107
[00.00%] Hot key 'key:000000000000' found so far with counter 254
[45.45%] Hot key 'counter:000000000001' found so far with counter 87
[45.45%] Hot key 'key:000000000002' found so far with counter 254
[45.45%] Hot key 'myset' found so far with counter 64
[45.45%] Hot key 'counter:000000000000' found so far with counter 93
-------- summary -------
Sampled 22 keys in the keyspace!
hot key found with counter: 254 keyname: key:000000000001
hot key found with counter: 254 keyname: key:000000000000
hot key found with counter: 254 keyname: key:000000000002
hot key found with counter: 107 keyname: mylist
hot key found with counter: 93  keyname: counter:000000000000
hot key found with counter: 87  keyname: counter:000000000002
hot key found with counter: 87  keyname: counter:000000000001
hot key found with counter: 64  keyname: myset