Redis 7.0 正式发布，新增近 50 个新命令

Redis 7.0 正式发布，新增近 50 个新命令

Redis 7.0 现已正式发布，该版本已经开发了将近一年，之前经历了三个候选版本。现如今，开发团队认为它已经足够稳定，可以应用于生产。

简而言之，Redis 7.0 几乎包括了对各个方面的增量改进。其中最值得注意的是 Redis Functions、ACLv2、command introspection 和 Sharded Pub/Sub，它们代表了基于用户反馈和生产经验教训的现有功能的重大演变。

7.0 版添加了近 50 个新命令和选项来支持这种演变并扩展 Redis 的现有功能。

例如，位图、列表、集合、排序集合和流数据类型都添加了支持其数据管理用例的功能。此外，缓存语义已扩展为支持 existential 和 comparative modifiers。

公告指出，“虽然面向用户的功能很容易吹嘘，但这个版本中真正的 unsung heroes 其实是努力使 Redis 更高效、更稳定和更精简”。

开发人员的大部分精力都投入到了通过关注 Redis 相对于它使用的资源的性能来提高 Redis 的操作效率。

Redis 7.0 对其管理的几乎每个子系统都进行了多项改进，包括内存、计算、网络和存储。虽然有些优化是默认启用的，但其他优化可能需要配置。

有关详细信息，可参阅 redis.conf 文件中的内联文档：

​​"appendonly.aof"# For convenience, Redis stores all persistent append-only files in a dedicated# directory. The name of the directory is determined by the appenddirname# configuration parameter.appenddirname "appendonlydir"# The fsync() call tells the Operating System to actually write data on disk# instead of waiting for more data in the output buffer. Some OS will really flush# data on disk, some other OS will just try to do it ASAP.## Redis supports three different modes:## no: don't fsync, just let the OS flush the data when it wants. Faster.# always: fsync after every write to the append only log. Slow, Safest.# everysec: fsync only one time every second. Compromise.## The default is "everysec", as that's usually the right compromise between# speed and data safety. It's up to you to understand if you can relax this to# "no" that will let the operating system flush the output buffer when# it wants, for better performances (but if you can live with the idea of# some data loss consider the default persistence mode that's snapshotting),# or on the contrary, use "always" that's very slow but a bit safer than# everysec.## More details please check the following article:# If unsure, use "everysec".# appendfsync alwaysappendfsync everysec# appendfsync no# When the AOF fsync policy is set to always or everysec, and a background# saving process (a background save or AOF log background rewriting) is# performing a lot of I/O against the disk, in some Linux configurations# Redis may block too long on the fsync() call. Note that there is no fix for# this currently, as even performing fsync in a different thread will block# our synchronous write(2) call.## In order to mitigate this problem it's possible to use the following option# that will prevent fsync() from being called in the main process while a# BGSAVE or BGREWRITEAOF is in progress.## This means that while another child is saving, the durability of Redis is# the same as "appendfsync none". In practical terms, this means that it is# possible to lose up to 30 seconds of log in the worst scenario (with the# default Linux settings).## If you have latency problems turn this to "yes". Otherwise leave it as# "no" that is the safest pick from the point of view of durability.no-appendfsync-on-rewrite no# Automatic rewrite of the append only file.# Redis is able to automatically rewrite the log file implicitly calling# BGREWRITEAOF when the AOF log size grows by the specified percentage.## This is how it works: Redis remembers the size of the AOF file after the# latest rewrite (if no rewrite has happened since the restart, the size of# the AOF at startup is used).## This base size is compared to the current size. If the current size is# bigger than the specified percentage, the rewrite is triggered. Also# you need to specify a minimal size for the AOF file to be rewritten, this# is useful to avoid rewriting the AOF file even if the percentage increase# is reached but it is still pretty small.## Specify a percentage of zero in order to disable the automatic AOF# rewrite feature.auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb# An AOF file may be found to be truncated at the end during the Redis# startup process, when the AOF data gets loaded back into memory.# This may happen when the system where Redis is running# crashes, especially when an ext4 filesystem is mounted without the# data=ordered option (however this can't happen when Redis itself# crashes or aborts but the operating system still works correctly).## Redis can either exit with an error when this happens, or load as much# data as possible (the default now) and start if the AOF file is found# to be truncated at the end. The following option controls this behavior.## If aof-load-truncated is set to yes, a truncated AOF file is loaded and# the Redis server starts emitting a log to inform the user of the event.# Otherwise if the option is set to no, the server aborts with an error# and refuses to start. When the option is set to no, the user requires# to fix the AOF file using the "redis-check-aof" utility before to restart# the server.## Note that if the AOF file will be found to be corrupted in the middle# the server will still exit with an error. This option only applies when# Redis will try to read more data from the AOF file but not enough bytes# will be found.aof-load-truncated yes# Redis can create append-only base files in either RDB or AOF formats. Using# the RDB format is always faster and more efficient, and disabling it is only# supported for backward compatibility purposes.aof-use-rdb-preamble yes# Redis supports recording timestamp annotations in the AOF to support restoring# the data from a specific point-in-time. However, using this capability changes# the AOF format in a way that may not be compatible with existing AOF parsers.aof-timestamp-enabled no################################ SHUTDOWN ###################################### Maximum time to wait for replicas when shutting down, in seconds.## During shut down, a grace period allows any lagging replicas to catch up with# the latest replication offset before the master exists. This period can# prevent data loss, especially for deployments without configured disk backups.## The 'shutdown-timeout' value is the grace period's duration in seconds. It is# only applicable when the instance has replicas. To disable the feature, set# the value to 0.## shutdown-timeout 10# When Redis receives a SIGINT or SIGTERM, shutdown is initiated and by default# an RDB snapshot is written to disk in a blocking operation if save points are configured.# The options used on signaled shutdown can include the following values:# default: Saves RDB snapshot only if save points are configured.# Waits for lagging replicas to catch up.# save: Forces a DB saving operation even if no save points are configured.# nosave: Prevents DB saving operation even if one or more save points are configured.# now: Skips waiting for lagging replicas.# force: Ignores any errors that would normally prevent the server from exiting.## Any combination of values is allowed as long as "save" and "nosave" are not set simultaneously.# Example: "nosave force now"## shutdown-on-sigint default# shutdown-on-sigterm default################ NON-DETERMINISTIC LONG BLOCKING COMMANDS ###################### Maximum time in milliseconds for EVAL scripts, functions and in some cases# modules' commands before Redis can start processing or rejecting other clients.## If the maximum execution time is reached Redis will start to reply to most# commands with a BUSY error.## In this state Redis will only allow a handful of commands to be executed.# For instance, SCRIPT KILL, FUNCTION KILL, SHUTDOWN NOSAVE and possibly some# module specific 'allow-busy' commands.## SCRIPT KILL and FUNCTION KILL will only be able to stop a script that did not# yet call any write commands, so SHUTDOWN NOSAVE may be the only way to stop# the server in the case a write command was already issued by the script when# the user doesn't want to wait for the natural termination of the script.## The default is 5 seconds. It is possible to set it to 0 or a negative value# to disable this mechanism (uninterrupted execution). Note that in the past# this config had a different name, which is now an alias, so both of these do# the same:# lua-time-limit 5000# busy-reply-threshold 5000################################ REDIS CLUSTER ################################ Normal Redis instances can't be part of a Redis Cluster; only nodes that are# started as cluster nodes can. In order to start a Redis instance as a# cluster node enable the cluster support uncommenting the following:## cluster-enabled yes# Every cluster node has a cluster configuration file. This file is not# intended to be edited by hand. It is created and updated by Redis nodes.# Every Redis Cluster node requires a different cluster configuration file.# Make sure that instances running in the same system do not have# overlapping cluster configuration file names.## cluster-config-file nodes-6379.conf# Cluster node timeout is the amount of milliseconds a node must be unreachable# for it to be considered in failure state.# Most other internal time limits are a multiple of the node timeout.## cluster-node-timeout 15000# The cluster port is the port that the cluster bus will listen for inbound connections on. When set # to the default value, 0, it will be bound to the command port + 10000. Setting this value requires # you to specify the cluster bus port when executing cluster meet.# cluster-port 0# A replica of a failing master will avoid to start a failover if its data# looks too old.## There is no simple way for a replica to actually have an exact measure of# its "data age", so the following two checks are performed:## 1) If there are multiple replicas able to failover, they exchange messages# in order to try to give an advantage to the replica with the best# replication offset (more data from the master processed).# Replicas will try to get their rank by offset, and apply to the start# of the failover a delay proportional to their rank.## 2) Every single replica computes the time of the last interaction with# its master. This can be the last ping or command received (if the master# is still in the "connected" state), or the time that elapsed since the# disconnection with the master (if the replication link is currently down).# If the last interaction is too old, the replica will not try to failover# at all.## The point "2" can be tuned by user. Specifically a replica will not perform# the failover if, since the last interaction with the master, the time# elapsed is greater than:## (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period## So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the# replica will not try to failover if it was not able to talk with the master# for longer than 310 seconds.## A large cluster-replica-validity-factor may allow replicas with too old data to failover# a master, while a too small value may prevent the cluster from being able to# elect a replica at all.## For maximum availability, it is possible to set the cluster-replica-validity-factor# to a value of 0, which means, that replicas will always try to failover the# master regardless of the last time they interacted with the master.# (However they'll always try to apply a delay proportional to their# offset rank).## Zero is the only value able to guarantee that when all the partitions heal# the cluster will always be able to continue.## cluster-replica-validity-factor 10# Cluster replicas are able to migrate to orphaned masters, that are masters# that are left without working replicas. This improves the cluster ability# to resist to failures as otherwise an orphaned master can't be failed over# in case of failure if it has no working replicas.## Replicas migrate to orphaned masters only if there are still at least a# given number of other working replicas for their old master. This number# is the "migration barrier". A migration barrier of 1 means that a replica# will migrate only if there is at least 1 other working replica for its master# and so forth. It usually reflects the number of replicas you want for every# master in your cluster.## Default is 1 (replicas migrate only if their masters remain with at least# one replica). To disable migration just set it to a very large value or# set cluster-allow-replica-migration to 'no'.# A value of 0 can be set but is useful only for debugging and dangerous# in production.## cluster-migration-barrier 1# Turning off this option allows to use less automatic cluster configuration.# It both disables migration to orphaned masters and migration from masters# that became empty.## Default is 'yes' (allow automatic migrations).## cluster-allow-replica-migration yes# By default Redis Cluster nodes stop accepting queries if they detect there# is at least a hash slot uncovered (no available node is serving it).# This way if the cluster is partially down (for example a range of hash slots# are no longer covered) all the cluster becomes, eventually, unavailable.# It automatically returns available as soon as all the slots are covered again.## However sometimes you want the subset of the cluster which is working,# to continue to accept queries for the part of the key space that is still# covered. In order to do so, just set the cluster-require-full-coverage# option to no.## cluster-require-full-coverage yes# This option, when set to yes, prevents replicas from trying to failover its# master during master failures. However the replica can still perform a# manual failover, if forced to do so.## This is useful in different scenarios, especially in the case of multiple# data center operations, where we want one side to never be promoted if not# in the case of a total DC failure.## cluster-replica-no-failover no# This option, when set to yes, allows nodes to serve read traffic while the# cluster is in a down state, as long as it believes it owns the slots.## This is useful for two cases. The first case is for when an application# doesn't require consistency of data during node failures or network partitions.# One example of this is a cache, where as long as the node has the data it# should be able to serve it.## The second use case is for configurations that don't meet the recommended# three shards but want to enable cluster mode and scale later. A# master outage in a 1 or 2 shard configuration causes a read/write outage to the# entire cluster without this option set, with it set there is only a write outage.# Without a quorum of masters, slot ownership will not change automatically.## cluster-allow-reads-when-down no# This option, when set to yes, allows nodes to serve pubsub shard traffic while# the cluster is in a down state, as long as it believes it owns the slots.## This is useful if the application would like to use the pubsub feature even when# the cluster global stable state is not OK. If the application wants to make sure only# one shard is serving a given channel, this feature should be kept as yes.## cluster-allow-pubsubshard-when-down yes# Cluster link send buffer limit is the limit on the memory usage of an individual# cluster bus link's send buffer in bytes. Cluster links would be freed if they exceed# this limit. This is to primarily prevent send buffers from growing unbounded on links# toward slow peers (E.g. PubSub messages being piled up).# This limit is disabled by default. Enable this limit when 'mem_cluster_links' INFO field# and/or 'send-buffer-allocated' entries in the 'CLUSTER LINKS` command output continuously increase.# Minimum limit of 1gb is recommended so that cluster link buffer can fit in at least a single# PubSub message by default. (client-query-buffer-limit default value is 1gb)## cluster-link-sendbuf-limit 0 # Clusters can configure their announced hostname using this config. This is a common use case for # applications that need to use TLS Server Name Indication (SNI) or dealing with DNS based# routing. By default this value is only shown as additional metadata in the CLUSTER SLOTS# command, but can be changed using 'cluster-preferred-endpoint-type' config. This value is # communicated along the clusterbus to all nodes, setting it to an empty string will remove # the hostname and also propagate the removal.## cluster-announce-hostname ""# Clusters can advertise how clients should connect to them using either their IP address,# a user defined hostname, or by declaring they have no endpoint. Which endpoint is# shown as the preferred endpoint is set by using the cluster-preferred-endpoint-type# config with values 'ip', 'hostname', or 'unknown-endpoint'. This value controls how# the endpoint returned for MOVED/ASKING requests as well as the first field of CLUSTER SLOTS. # If the preferred endpoint type is set to hostname, but no announced hostname is set, a '?' # will be returned instead.## When a cluster advertises itself as having an unknown endpoint, it's indicating that# the server doesn't know how clients can reach the cluster. This can happen in certain # networking situations where there are multiple possible routes to the node, and the # server doesn't know which one the client took. In this case, the server is expecting# the client to reach out on the same endpoint it used for making the last request, but use# the port provided in the response.## cluster-preferred-endpoint-type ip# In order to setup your cluster make sure to read the documentation# available at web site.########################## CLUSTER DOCKER/NAT support ######################### In certain deployments, Redis Cluster nodes address discovery fails, because# addresses are NAT-ted or because ports are forwarded (the typical case is# Docker and other containers).## In order to make Redis Cluster working in such environments, a static# configuration where each node knows its public address is needed. The# following four options are used for this scope, and are:## * cluster-announce-ip# * cluster-announce-port# * cluster-announce-tls-port# * cluster-announce-bus-port## Each instructs the node about its address, client ports (for connections# without and with TLS) and cluster message bus port. The information is then# published in the header of the bus packets so that other nodes will be able to# correctly map the address of the node publishing the information.## If cluster-tls is set to yes and cluster-announce-tls-port is omitted or set# to zero, then cluster-announce-port refers to the TLS port. Note also that# cluster-announce-tls-port has no effect if cluster-tls is set to no.## If the above options are not used, the normal Redis Cluster auto-detection# will be used instead.## Note that when remapped, the bus port may not be at the fixed offset of# clients port + 10000, so you can specify any port and bus-port depending# on how they get remapped. If the bus-port is not set, a fixed offset of# 10000 will be used as usual.## Example:## cluster-announce-ip 10.1.1.5# cluster-announce-tls-port 6379# cluster-announce-port 0# cluster-announce-bus-port 6380################################## SLOW LOG #################################### The Redis Slow Log is a system to log queries that exceeded a specified# execution time. The execution time does not include the I/O operations# like talking with the client, sending the reply and so forth,# but just the time needed to actually execute the command (this is the only# stage of command execution where the thread is blocked and can not serve# other requests in the meantime).## You can configure the slow log with two parameters: one tells Redis# what is the execution time, in microseconds, to exceed in order for the# command to get logged, and the other parameter is the length of the# slow log. When a new command is logged the oldest one is removed from the# queue of logged commands.# The following time is expressed in microseconds, so 1000000 is equivalent# to one second. Note that a negative number disables the slow log, while# a value of zero forces the logging of every command.slowlog-log-slower-than 10000# There is no limit to this length. Just be aware that it will consume memory.# You can reclaim memory used by the slow log with SLOWLOG RESET.slowlog-max-len 128################################ LATENCY MONITOR ############################### The Redis latency monitoring subsystem samples different operations# at runtime in order to collect data related to possible sources of# latency of a Redis instance.## Via the LATENCY command this information is available to the user that can# print graphs and obtain reports.## The system only logs operations that were performed in a time equal or# greater than the amount of milliseconds specified via the# latency-monitor-threshold configuration directive. When its value is set# to zero, the latency monitor is turned off.## By default latency monitoring is disabled since it is mostly not needed# if you don't have latency issues, and collecting data has a performance# impact, that while very small, can be measured under big load. Latency# monitoring can easily be enabled at runtime using the command# "CONFIG SET latency-monitor-threshold " if needed.latency-monitor-threshold 0################################ LATENCY TRACKING ############################### The Redis extended latency monitoring tracks the per command latencies and enables# exporting the percentile distribution via the INFO latencystats command,# and cumulative latency distributions (histograms) via the LATENCY command.## By default, the extended latency monitoring is enabled since the overhead# of keeping track of the command latency is very small.# latency-tracking yes# By default the exported latency percentiles via the INFO latencystats command# are the p50, p99, and p999.# latency-tracking-info-percentiles 50 99 99.9############################# EVENT NOTIFICATION ############################### Redis can notify Pub/Sub clients about events happening in the key space.# This feature is documented at For instance if keyspace events notification is enabled, and a client# performs a DEL operation on key "foo" stored in the Database 0, two# messages will be published via Pub/Sub:## PUBLISH __keyspace@0__:foo del# PUBLISH __keyevent@0__:del foo## It is possible to select the events that Redis will notify among a set# of classes. Every class is identified by a single character:## K Keyspace events, published with __keyspace@__ prefix.# E Keyevent events, published with __keyevent@__ prefix.# g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...# $ String commands# l List commands# s Set commands# h Hash commands# z Sorted set commands# x Expired events (events generated every time a key expires)# e Evicted events (events generated when a key is evicted for maxmemory)# n New key events (Note: not included in the 'A' class)# t Stream commands# d Module key type events# m Key-miss events (Note: It is not included in the 'A' class)# A Alias for g$lshzxetd, so that the "AKE" string means all the events# (Except key-miss events which are excluded from 'A' due to their# unique nature).## The "notify-keyspace-events" takes as argument a string that is composed# of zero or multiple characters. The empty string means that notifications# are disabled.## Example: to enable list and generic events, from the point of view of the# event name, use:## notify-keyspace-events Elg## Example 2: to get the stream of the expired keys subscribing to channel# name __keyevent@0__:expired use:## notify-keyspace-events Ex## By default all notifications are disabled because most users don't need# this feature and the feature has some overhead. Note that if you don't# specify at least one of K or E, no events will be delivered.notify-keyspace-events ""############################### ADVANCED CONFIG ################################ Hashes are encoded using a memory efficient data structure when they have a# small number of entries, and the biggest entry does not exceed a given# threshold. These thresholds can be configured using the following directives.hash-max-listpack-entries 512hash-max-listpack-value 64# Lists are also encoded in a special way to save a lot of space.# The number of entries allowed per internal list node can be specified# as a fixed maximum size or a maximum number of elements.# For a fixed maximum size, use -5 through -1, meaning:# -5: max size: 64 Kb <-- not recommended for normal workloads# -4: max size: 32 Kb <-- not recommended# -3: max size: 16 Kb <-- probably not recommended# -2: max size: 8 Kb <-- good# -1: max size: 4 Kb <-- good# Positive numbers mean store up to _exactly_ that number of elements# per list node.# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),# but if your use case is unique, adjust the settings as necessary.list-max-listpack-size -2# Lists may also be compressed.# Compress depth is the number of quicklist ziplist nodes from *each* side of# the list to *exclude* from compression. The head and tail of the list# are always uncompressed for fast push/pop operations. Settings are:# 0: disable all list compression# 1: depth 1 means "don't start compressing until after 1 node into the list,# going from either the head or tail"# So: [head]->node->node->...->node->[tail]# [head], [tail] will always be uncompressed; inner nodes will compress.# 2: [head]->[next]->node->node->...->node->[prev]->[tail]# 2 here means: don't compress head or head->next or tail->prev or tail,# but compress all nodes between them.# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]# etc.list-compress-depth 0# Sets have a special encoding in just one case: when a set is composed# of just strings that happen to be integers in radix 10 in the range# of 64 bit signed integers.# The following configuration setting sets the limit in the size of the# set in order to use this special memory saving encoding.set-max-intset-entries 512# Similarly to hashes and lists, sorted sets are also specially encoded in# order to save a lot of space. This encoding is only used when the length and# elements of a sorted set are below the following limits:zset-max-listpack-entries 128zset-max-listpack-value 64# HyperLogLog sparse representation bytes limit. The limit includes the# 16 bytes header. When an HyperLogLog using the sparse representation crosses# this limit, it is converted into the dense representation.## A value greater than 16000 is totally useless, since at that point the# dense representation is more memory efficient.## The suggested value is ~ 3000 in order to have the benefits of# the space efficient encoding without slowing down too much PFADD,# which is O(N) with the sparse encoding. The value can be raised to# ~ 10000 when CPU is not a concern, but space is, and the data set is# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.hll-sparse-max-bytes 3000# Streams macro node max size / items. The stream data structure is a radix# tree of big nodes that encode multiple items inside. Using this configuration# it is possible to configure how big a single node can be in bytes, and the# maximum number of items it may contain before switching to a new node when# appending new stream entries. If any of the following settings are set to# zero, the limit is ignored, so for instance it is possible to set just a# max entries limit by setting max-bytes to 0 and max-entries to the desired# value.stream-node-max-bytes 4096stream-node-max-entries 100# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in# order to help rehashing the main Redis hash table (the one mapping top-level# keys to values). The hash table implementation Redis uses (see dict.c)# performs a lazy rehashing: the more operation you run into a hash table# that is rehashing, the more rehashing "steps" are performed, so if the# server is idle the rehashing is never complete and some more memory is used# by the hash table.## The default is to use this millisecond 10 times every second in order to# actively rehash the main dictionaries, freeing memory when possible.## If unsure:# use "activerehashing no" if you have hard latency requirements and it is# not a good thing in your environment that Redis can reply from time to time# to queries with 2 milliseconds delay.## use "activerehashing yes" if you don't have such hard requirements but# want to free memory asap when possible.activerehashing yes# The client output buffer limits can be used to force disconnection of clients# that are not reading data from the server fast enough for some reason (a# common reason is that a Pub/Sub client can't consume messages as fast as the# publisher can produce them).## The limit can be set differently for the three different classes of clients:## normal -> normal clients including MONITOR clients# replica -> replica clients# pubsub -> clients subscribed to at least one pubsub channel or pattern## The syntax of every client-output-buffer-limit directive is the following:## client-output-buffer-limit ## A client is immediately disconnected once the hard limit is reached, or if# the soft limit is reached and remains reached for the specified number of# seconds (continuously).# So for instance if the hard limit is 32 megabytes and the soft limit is# 16 megabytes / 10 seconds, the client will get disconnected immediately# if the size of the output buffers reach 32 megabytes, but will also get# disconnected if the client reaches 16 megabytes and continuously overcomes# the limit for 10 seconds.## By default normal clients are not limited because they don't receive data# without asking (in a push way), but just after a request, so only# asynchronous clients may create a scenario where data is requested faster# than it can read.## Instead there is a default limit for pubsub and replica clients, since# subscribers and replicas receive data in a push fashion.## Note that it doesn't make sense to set the replica clients output buffer# limit lower than the repl-backlog-size config (partial sync will succeed# and then replica will get disconnected).# Such a configuration is ignored (the size of repl-backlog-size will be used).# This doesn't have memory consumption implications since the replica client# will share the backlog buffers memory.## Both the hard or the soft limit can be disabled by setting them to zero.client-output-buffer-limit normal 0 0 0client-output-buffer-limit replica 256mb 64mb 60client-output-buffer-limit pubsub 32mb 8mb 60# Client query buffers accumulate new commands. They are limited to a fixed# amount by default in order to avoid that a protocol desynchronization (for# instance due to a bug in the client) will lead to unbound memory usage in# the query buffer. However you can configure it here if you have very special# needs, such us huge multi/exec requests or alike.## client-query-buffer-limit 1gb# In some scenarios client connections can hog up memory leading to OOM# errors or data eviction. To avoid this we can cap the accumulated memory# used by all client connections (all pubsub and normal clients). Once we# reach that limit connections will be dropped by the server freeing up# memory. The server will attempt to drop the connections using the most # memory first. We call this mechanism "client eviction".## Client eviction is configured using the maxmemory-clients setting as follows:# 0 - client eviction is disabled (default)## A memory value can be used for the client eviction threshold,# for example:# maxmemory-clients 1g## A percentage value (between 1% and 100%) means the client eviction threshold# is based on a percentage of the maxmemory setting. For example to set client# eviction at 5% of maxmemory:# maxmemory-clients 5%# In the Redis protocol, bulk requests, that are, elements representing single# strings, are normally limited to 512 mb. However you can change this limit# here, but must be 1mb or greater## proto-max-bulk-len 512mb# Redis calls an internal function to perform many background tasks, like# closing connections of clients in timeout, purging expired keys that are# never requested, and so forth.## Not all tasks are performed with the same frequency, but Redis checks for# tasks to perform according to the specified "hz" value.## By default "hz" is set to 10. Raising the value will use more CPU when# Redis is idle, but at the same time will make Redis more responsive when# there are many keys expiring at the same time, and timeouts may be# handled with more precision.## The range is between 1 and 500, however a value over 100 is usually not# a good idea. Most users should use the default of 10 and raise this up to# 100 only in environments where very low latency is required.hz 10# Normally it is useful to have an HZ value which is proportional to the# number of clients connected. This is useful in order, for instance, to# avoid too many clients are processed for each background task invocation# in order to avoid latency spikes.## Since the default HZ value by default is conservatively set to 10, Redis# offers, and enables by default, the ability to use an adaptive HZ value# which will temporarily raise when there are many connected clients.## When dynamic HZ is enabled, the actual configured HZ will be used# as a baseline, but multiples of the configured HZ value will be actually# used as needed once more clients are connected. In this way an idle# instance will use very little CPU time while a busy instance will be# more responsive.dynamic-hz yes# When a child rewrites the AOF file, if the following option is enabled# the file will be fsync-ed every 4 MB of data generated. This is useful# in order to commit the file to the disk more incrementally and avoid# big latency spikes.aof-rewrite-incremental-fsync yes# When redis saves RDB file, if the following option is enabled# the file will be fsync-ed every 4 MB of data generated. This is useful# in order to commit the file to the disk more incrementally and avoid# big latency spikes.rdb-save-incremental-fsync yes# Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good# idea to start with the default settings and only change them after investigating# how to improve the performances and how the keys LFU change over time, which# is possible to inspect via the OBJECT FREQ command.## There are two tunable parameters in the Redis LFU implementation: the# counter logarithm factor and the counter decay time. It is important to# understand what the two parameters mean before changing them.## The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis# uses a probabilistic increment with logarithmic behavior. Given the value# of the old counter, when a key is accessed, the counter is incremented in# this way:## 1. A random number R between 0 and 1 is extracted.# 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1).# 3. The counter is incremented only if R < P.## The default lfu-log-factor is 10. This is a table of how the frequency# counter changes with a different number of accesses with different# logarithmic factors:## +--------+------------+------------+------------+------------+------------+# | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |# +--------+------------+------------+------------+------------+------------+# | 0 | 104 | 255 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 1 | 18 | 49 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 10 | 10 | 18 | 142 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 100 | 8 | 11 | 49 | 143 | 255 |# +--------+------------+------------+------------+------------+------------+## NOTE: The above table was obtained by running the following commands:## redis-benchmark -n 1000000 incr foo# redis-cli object freq foo## NOTE 2: The counter initial value is 5 in order to give new objects a chance# to accumulate hits.## The counter decay time is the time, in minutes, that must elapse in order# for the key counter to be divided by two (or decremented if it has a value# less <= 10).## The default value for the lfu-decay-time is 1. A special value of 0 means to# decay the counter every time it happens to be scanned.## lfu-log-factor 10# lfu-decay-time 1########################### ACTIVE DEFRAGMENTATION ######################### What is active defragmentation?# -------------------------------## Active (online) defragmentation allows a Redis server to compact the# spaces left between small allocations and deallocations of data in memory,# thus allowing to reclaim back memory.## Fragmentation is a natural process that happens with every allocator (but# less so with Jemalloc, fortunately) and certain workloads. Normally a server# restart is needed in order to lower the fragmentation, or at least to flush# away all the data and create it again. However thanks to this feature# implemented by Oran Agra for Redis 4.0 this process can happen at runtime# in a "hot" way, while the server is running.## Basically when the fragmentation is over a certain level (see the# configuration options below) Redis will start to create new copies of the# values in contiguous memory regions by exploiting certain specific Jemalloc# features (in order to understand if an allocation is causing fragmentation# and to allocate it in a better place), and at the same time, will release the# old copies of the data. This process, repeated incrementally for all the keys# will cause the fragmentation to drop back to normal values.## Important things to understand:## 1. This feature is disabled by default, and only works if you compiled Redis# to use the copy of Jemalloc we ship with the source code of Redis.# This is the default with Linux builds.## 2. You never need to enable this feature if you don't have fragmentation# issues.## 3. Once you experience fragmentation, you can enable this feature when# needed with the command "CONFIG SET activedefrag yes".## The configuration parameters are able to fine tune the behavior of the# defragmentation process. If you are not sure about what they mean it is# a good idea to leave the defaults untouched.# Active defragmentation is disabled by default# activedefrag no# Minimum amount of fragmentation waste to start active defrag# active-defrag-ignore-bytes 100mb# Minimum percentage of fragmentation to start active defrag# active-defrag-threshold-lower 10# Maximum percentage of fragmentation at which we use maximum effort# active-defrag-threshold-upper 100# Minimal effort for defrag in CPU percentage, to be used when the lower# threshold is reached# active-defrag-cycle-min 1# Maximal effort for defrag in CPU percentage, to be used when the upper# threshold is reached# active-defrag-cycle-max 25# Maximum number of set/hash/zset/list fields that will be processed from# the main dictionary scan# active-defrag-max-scan-fields 1000# Jemalloc background thread for purging will be enabled by defaultjemalloc-bg-thread yes# It is possible to pin different threads and processes of Redis to specific# CPUs in your system, in order to maximize the performances of the server.# This is useful both in order to pin different Redis threads in different# CPUs, but also in order to make sure that multiple Redis instances running# in the same host will be pinned to different CPUs.## Normally you can do this using the "taskset" command, however it is also# possible to this via Redis configuration directly, both in Linux and FreeBSD.## You can pin the server/IO threads, bio threads, aof rewrite child process, and# the bgsave child process. The syntax to specify the cpu list is the same as# the taskset command:## Set redis server/io threads to cpu affinity 0,2,4,6:# server_cpulist 0-7:2## Set bio threads to cpu affinity 1,3:# bio_cpulist 1,3## Set aof rewrite child process to cpu affinity 8,9,10,11:# aof_rewrite_cpulist 8-11## Set bgsave child process to cpu affinity 1,10,11# bgsave_cpulist 1,10-11# In some cases redis will emit warnings and even refuse to start if it detects# that the system is in bad state, it is possible to suppress these warnings# by setting the following config which takes a space delimited list of warnings# to suppress## ignore-warnings ARM64-COW-BUG

与此同时，Redis 7.2 的开发工作也已经在进行当中了。

更多详情可查看 release notes：

​​https://github.com/redis/redis/blob/7.0/00-RELEASENOTES​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。