redis.conf翻译与配置(四)【redis6.0.6】

举报
看,未来 发表于 2020/12/29 23:29:42 2020/12/29
【摘要】 学习redis的途中,碰上了redis.conf,突发奇想,想着来进行一波翻译输出。 源码之前,了无秘密。 文章目录 慢删除原文译文 线程I/O原文译文 追加持久化(只附加模式)原文译文 LUA脚本原文译文 慢删除 原文 ############################# LAZY FREEING #######...

学习redis的途中,碰上了redis.conf,突发奇想,想着来进行一波翻译输出。
源码之前,了无秘密。
在这里插入图片描述

慢删除

原文

############################# LAZY FREEING ####################################

# Redis has two primitives to delete keys. One is called DEL and is a blocking
# deletion of the object. It means that the server stops processing new commands
# in order to reclaim all the memory associated with an object in a synchronous
# way. If the key deleted is associated with a small object, the time needed
# in order to execute the DEL command is very small and comparable to most other
# O(1) or O(log_N) commands in Redis. However if the key is associated with an
# aggregated value containing millions of elements, the server can block for
# a long time (even seconds) in order to complete the operation.
#
# For the above reasons Redis also offers non blocking deletion primitives
# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
# FLUSHDB commands, in order to reclaim memory in background. Those commands
# are executed in constant time. Another thread will incrementally free the
# object in the background as fast as possible.
#
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
# It's up to the design of the application to understand when it is a good
# idea to use one or the other. However the Redis server sometimes has to
# delete keys or flush the whole database as a side effect of other operations.
# Specifically Redis deletes objects independently of a user call in the
# following scenarios:
#
# 1) On eviction, because of the maxmemory and maxmemory policy configurations,
# in order to make room for new data, without going over the specified
# memory limit.
# 2) Because of expire: when a key with an associated time to live (see the
# EXPIRE command) must be deleted from memory.
# 3) Because of a side effect of a command that stores data on a key that may
# already exist. For example the RENAME command may delete the old key
# content when it is replaced with another one. Similarly SUNIONSTORE
# or SORT with STORE option may delete existing keys. The SET command
# itself removes any old content of the specified key in order to replace
# it with the specified string.
# 4) During replication, when a replica performs a full resynchronization with
# its master, the content of the whole database is removed in order to
# load the RDB file just transferred.
#
# In all the above cases the default is to delete objects in a blocking way,
# like if DEL was called. However you can configure each case specifically
# in order to instead release memory in a non-blocking way like if UNLINK
# was called, using the following configuration directives.

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

# It is also possible, for the case when to replace the user code DEL calls
# with UNLINK calls is not easy, to modify the default behavior of the DEL
# command to act exactly like UNLINK, using the following configuration
# directive:

lazyfree-lazy-user-del no

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55

译文

Redis有两个原语来删除键。

一个是DEL,它是对象的阻塞删除。这意味着服务器停止处理新命令,以同步方式收回与一个对象关联的所有内存。
如果删除的键与一个小对象相关联,那么执行DEL命令所需的时间非常小,可以与Redis中的大多数O(1)或O(log_N)命令相媲美。
但是,如果键与包含数百万个元素的聚合值相关联,服务器可能会阻塞很长时间(甚至几秒钟)以完成操作。

基于上述原因,Redis还提供了非阻塞删除原语,如UNLINK(非阻塞DEL)和异步选项的FLUSHALL和FLUSHDB命令,以便在后台回收内存。这些命令在固定的时间内执行。另一个线程将在后台以尽可能快的速度递增地释放对象。

FLUSHALL 和 FLUSHDB 的删除选项(DEL, UNLINK 和 ASYNC)是有使用者选定的。

何时使用哪一种会比较好,这取决于应用程序的设计。
然而,有时由于其他操作的副作用,redis不得不删除或刷新整个数据库。

具体来说,在以下场景,redis将自行删除数据对象:

1)在回收时,由于maxmemory和maxmemory策略配置,为了给新数据腾出空间,而不超过指定的内存限制。
2)因为过期:当必须从内存中删除一个具有关联生存时间的键(参见expire命令)时。
3)由于一个命令的副作用,该命令将数据存储在一个可能已经存在的键上。例如,RENAME命令可能会在用另一个键替换旧键内容时删除它。类似的,SUNIONSTORE或SORT with STORE选项可以删除现有的键。SET命令本身删除指定键的任何旧内容,以便将其替换为指定的字符串。
4)在复制过程中,当一个副本与它的主服务器执行完全的重新同步时,整个数据库的内容被删除,以便加载刚刚传输的RDB文件。

  
 
  • 1
  • 2
  • 3
  • 4

在上述所有情况下,默认情况是以阻塞的方式删除对象,比如调用DEL。但是,您可以具体配置每种情况,以便以非阻塞的方式释放内存,比如在UNLINK被调用时,使用以下配置指令:

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

  
 
  • 1
  • 2
  • 3
  • 4

也有可能,当用UNLINK调用替换用户代码DEL调用不那么顺利的情况下,可以修改DEL命令的默认行为,使其完全像UNLINK一样,使用以下配置指令:

lazyfree-lazy-user-del no

  
 
  • 1

线程I/O

原文

################################ THREADED I/O #################################

# Redis is mostly single threaded, however there are certain threaded
# operations such as UNLINK, slow I/O accesses and other things that are
# performed on side threads.
#
# Now it is also possible to handle Redis clients socket reads and writes
# in different I/O threads. Since especially writing is so slow, normally
# Redis users use pipelining in order to speedup the Redis performances per
# core, and spawn multiple instances in order to scale more. Using I/O
# threads it is possible to easily speedup two times Redis without resorting
# to pipelining nor sharding of the instance.
#
# By default threading is disabled, we suggest enabling it only in machines
# that have at least 4 or more cores, leaving at least one spare core.
# Using more than 8 threads is unlikely to help much. We also recommend using
# threaded I/O only if you actually have performance problems, with Redis
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
# threads, if you have a 8 cores, try to use 6 threads. In order to
# enable I/O threads use the following configuration directive:
#
# io-threads 4
#
# Setting io-threads to 1 will just use the main thread as usually.
# When I/O threads are enabled, we only use threads for writes, that is
# to thread the write(2) syscall and transfer the client buffers to the
# socket. However it is also possible to enable threading of reads and
# protocol parsing using the following configuration directive, by setting
# it to yes:
#
# io-threads-do-reads no
#
# Usually threading reads doesn't help much.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Aso this feature currently does not work when SSL is
# enabled.
#
# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of Redis theads, otherwise you'll not
# be able to notice the improvements.


  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46

译文

Redis大部分是单线程的,但是也有一些线程操作,如解除链接,缓慢的I/O访问和一些其他事情是在侧线程上执行的。
现在它也可以在不同的I/O线程下去处理Redis客户端套接字读写。特别是“写”过程是如此的慢吞吞,通常Redis用户使用管道通信来提高每个核的Redis性能,并衍生多个实例来扩大规模。
使用I/O线程,它可以很容易地加速两倍的Redis没有诉诸于管道或切分的实例。

默认情况下,线程是禁用的,我们建议仅在拥有至少4个或更多核的机器上启用它,至少留下一个备用核。
使用超过8个线程多半没什么用。我们还建议只有在你确实有性能问题的时候才使用线程I/O,因为Redis实例会占用相当大百分比的CPU,所以没事儿开些线程出来玩没必要。
例如,如果你有4核,可以尝试使用2或3个I/O线程,如果你有8核,可以尝试使用6个线程。

以下配置指令开启线程之旅:# io-threads 4

将io-threads设置为1只会像往常一样使用主线程。当启用I/O线程时,我们只使用线程进行写操作,因为对线程来说,write(2)系统调用和传输客户端缓冲区到套接字,然而,也有可能启用线程读取和协议解析使用以下配置指令,通过将它设置为yes:# io-threads-do-reads no

通常情况下线程拿去读没什么意义。

注意1:这个配置指令不能在运行时通过配置设置来改变。当SSL被启用时,这个特性不能用。
注2:如果你想用Redis -benchmark测试Redis加速,请确保你也在线程模式下运行基准测试,使用——threads选项来匹配Redis头的数量,否则你将无法注意到改进。


追加持久化(只附加模式)

原文

############################## APPEND ONLY MODE ###############################

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# 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:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync 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 100
auto-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

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
aof-use-rdb-preamble yes

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128

译文

默认情况下,Redis异步转储数据集到磁盘上。这种模式在许多应用程序中已经足够好了,但Redis进程的问题或断电可能会导致几分钟的写丢失(取决于配置的保存点)。

Append Only文件是另一种持久性模式,它提供了更好的持久性。例如使用默认数据fsync策略配置文件中(见后),Redis可以在一个意外事件中失去一秒的写操作,比如服务器断电,或者如果Redis进程本身发生了什么问题,一个写操作,但操作系统仍然正常运行。

AOF和RDB持久性可以同时启用而没有问题。如果在启动时启用了AOF, Redis将加载AOF,这是一个更好的持久性保障。
详情见:http://redis.io/topics/persistence

append only 文件名:“appendonly.aof”


fsync()调用告诉操作系统在磁盘上实际写入数据,而不是等待输出缓冲区中的更多数据。一些操作系统会真正刷新磁盘上的数据,而另一些操作系统会尝试尽快这么做。

Redis支持以下三种不同的模式:

no: 不fsync,只要让操作系统在需要的时候刷新数据即可。尽快。
always: fsync在每次写入append only日志后执行。慢点,安全第一。
everysec:一秒执行一次fsync,折中。

  
 
  • 1
  • 2
  • 3

默认值是“每秒钟”,因为这通常是速度和数据安全之间的折中。如果你能处理好这个“不”字,让操作系统刷新输出缓冲区时,为了更好的表现(但是如果你可以忍受一些数据丢失的),那你可以选“不”。或相反,使用“总是”非常缓慢但比everysec更安全一点。

更多细节参见:http://antirez.com/post/redis-persistence-demystified.html

当AOF fsync策略设置为always或everysec,并且后台保存进程(后台保存或AOF日志后台重写)对磁盘执行大量I/O操作时,在一些Linux配置中,Redis可能会在fsync()调用上阻塞太长时间。注意,这个问题目前还没有解决办法,因为即使在不同的线程中执行fsync,也会阻塞我们的同步write(2)调用。

为了减轻这个问题,可以使用以下选项来防止在执行BGSAVE或BGREWRITEAOF时在主进程中调用fsync()。
这意味着,当另一个子对象正在保存,Redis的持久性与“appendfsync none”相同。实际上,这意味着在最坏的情况下(使用默认的Linux设置)可能会丢失最多30秒的日志。

如果有延迟问题,请将此选项转换为“yes”。否则,从耐久性的角度来看,这是最安全的选择。


自动重写仅追加的文件:
当AOF日志大小增长指定的百分比时,Redis会隐式调用BGREWRITEAOF,自动重写日志文件。

它的工作模式是:Redis会记住最近一次重写后的AOF文件的大小(如果重启后没有重写,则使用启动时的AOF文件的大小)。

如果当前大小大于指定的百分比,就会触发重写。您还需要指定要重写的AOF文件的最小大小,这有助于避免重写AOF文件,即使达到百分比增长,但它仍然很小。
指定一个百分比为零,以禁用自动AOF重写功能。


在redis启动期间,可能会发现aof文件在结尾处被截断 ,这可能会发生在Redis运行的系统崩溃时,特别是ext4文件系统在没有data=ordered选项的情况下挂载(然而,这不会发生在Redis本身崩溃或中止但操作系统仍然正常工作时)。

发生这种情况时,redis可以退出并返回错误,或者加载尽可能多的数据。
以下选项控制此行为:
如果AOF -load-truncated被设置为yes,出现AOF文件加载被截断时Redis会发送一个日志来提醒用户。否则,如果将该选项设置为no,服务器将以错误终止并拒绝启动。当选项设置为no时,用户需要在重启服务器之前使用“redis-check-aof”程序修复AOF文件。

注意,如果发现AOF文件在中间损坏,服务器仍然会退出并出现错误。这个选项只适用于当Redis将尝试读取更多的数据从AOF文件,但没有足够的字节时生效。


当重写AOF文件,Redis能够使用一个RDB序言将AOF文件更快的重写和恢复。当这个选项被打开时,重写的AOF文件由两个不同的节组成:[RDB file][AOF tail]

加载Redis时,会识别出AOF文件以“Redis”字符串开头并加载带前缀的RDB文件,然后继续加载AOF尾部。


LUA脚本

原文

################################ LUA SCRIPTING  ###############################

# Max execution time of a Lua script in milliseconds.
#
# If the maximum execution time is reached Redis will log that a script is
# still in execution after the maximum allowed time and will start to
# reply to queries with an error.
#
# When a long running script exceeds the maximum execution time only the
# SCRIPT KILL and SHUTDOWN NOSAVE commands are available. The first can be
# used to stop a script that did not yet called write commands. The second
# is the only way to shut down the server in the case a write command was
# already issued by the script but the user doesn't want to wait for the natural
# termination of the script.
#
# Set it to 0 or a negative value for unlimited execution without warnings.
lua-time-limit 5000

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

译文

Lua脚本的最长执行时间(毫秒)。

如果达到最大执行时间,Redis将记录在允许的最长时间之后脚本仍在执行中,并将开始以错误的方式答复查询。

当长时间运行的脚本超过最大执行时间时,只有脚本KILL和SHUTDOWN NOSAVE命令可用。第一个命令可用于停止尚未调用write命令的脚本。第二种方法是在脚本已经发出write命令但用户不想等待脚本自然终止的情况下关闭服务器的唯一方法。

将其设置为0或负值,以无限制地执行而不发出警告。

文章来源: lion-wu.blog.csdn.net,作者:看,未来,版权归原作者所有,如需转载,请联系作者。

原文链接:lion-wu.blog.csdn.net/article/details/108062060

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200