redis防止重复消费什么时候set

转载

技术领航探索者 2024-10-11 05:06:42

文章标签 redis防止重复消费什么时候set redis Redis 数据 文章分类 Redis 数据库

前言

Redis持久化分为两种方式，RDB(默认开启)和AOF(Append Only File, 默认关闭).

RDB

默认(代码)配置中就有对于备份的策略,位于SNAPSHOTTING模块下:

################################ SNAPSHOTTING  ################################
#
# 将数据库数据保存在磁盘上:
#   save <seconds> <changes>
#   是否触发操作取决于设置的秒数和期间的操作次数
#
#   以下所举的例子的保存触发条件描述如下:
#    15分钟内至少操作了1次
#    5分钟内至少操作了10次
#    1分钟内至少操作了10000次
# 注: 你可以通过注释掉所有“保存”行来完全禁用保存。
#
#   也可以删除所有先前配置的保存
#   通过添加带有单个空字符串参数的save指令来覆盖
#   如以下示例所示：
#   save ""
save 900 1
save 300 10
save 60 10000

# 默认情况下，如果启用RDB快照（至少一个保存点）并且最新的后台保存失败，则Redis将停止接受写入。
# 这将使用户很难意识到数据不能正确地持久存储在磁盘上，可能也会因此发生一些灾难。
# 如果后台保存过程将再次开始工作，则Redis将自动允许再次写入。
# 但是，如果您设置了对Redis服务器和持久性的适当监视，则可能要禁用此功能，以便即使磁盘，权限等出现问题，Redis也将继续照常工作。
stop-writes-on-bgsave-error yes

# 是否使用LZF压缩rdb文件
rdbcompression yes

#从RDB版本5开始，CRC64校验和位于文件末尾。 这使得该格式更能抵抗损坏，但是在保存和加载RDB文件时会付出一定的性能损失（大约10％），因此可以禁用该格式以实现最佳性能。
#在禁用校验和的情况下创建的RDB文件的校验和为零，这将指示加载代码跳过该校验。
rdbchecksum yes

# 备份文件名,默认是dump.rdb,可以用端口后缀来区分
dbfilename dump-${port}.rdb

# 工作目录,也就是备份的目录.默认是./
dir /usr/local/backup/redis/

一般建议禁用配置文件中的save,而是在运行的实例中使用save或bgsave.

命令	IO类型	阻塞	复杂度	优点	缺点
save	同步	是		不会消耗额外内存	阻塞
bgsave	异步	是(发生在fork)		不阻塞客户端命令	消耗额外内存

AOF

将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。AOF相对可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串，非常容易阅读和解析。

配置

代码中默认关闭了,因此需要在.conf文件中开启.

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

# 开启AOF模式
appendonly yes

# aof名字,这里只能写文件名,路径取决与SNAPSHOTING中的dir
appendfilename "appendonly-6379.aof"

# AOF fsync 策略
# no: 不进行fsync操作, 操作系统在需要时刷新数据即可。 速度比较快。
# always: 默认的持久化模式.每次写入都进行fsync. 慢但是安全.
# everysec: 每秒进行fsync操作. 平衡了性能与安全.
appendfsync everysec


# 当AOF fsync策略设置为always或everysec时，并且后台保存进程（后台保存或AOF日志后台重写）对磁盘执行大量I/O时，在某些Linux配置中，Redis可能会在磁盘上阻塞太长时间。 
# 为了缓解此问题，可以使用以下选项来防止在BGSAVE或BGREWRITEAOF进行时在主进程中调用fsync。

# 这意味着当另一个孩子正在保存时，Redis的持久性与“ appendfsync none”相同。 实际上，这意味着在最坏的情况下（使用默认的Linux设置）可能会丢失多达30秒的日志。
# 如果有延迟问题，请将其设置为“yes”。 否则，从耐久性的角度来看，将其保留为“否”是最安全的选择。
no-appendfsync-on-rewrite no
# 如果AOF 文件一直被追加，这就可能导致AOF文件过于庞大。因此，为了避免这种状况，Redis新增了重写机制，当AOF文件的大小超过所指定的阈值时，Redis会自动启用AOF文件的内容压缩，只保留可以恢复数据的最小指令集，也可以随时使用命令bgrewiteaof。

# 当AOF的体积大于64M，并且比上一次重写之后的体积大了至少一倍(100%)的时候，Redis将执行BGREWRITEAOF命令。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题
# (突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败.
# 也可以使用redis-check-aof --fix appendonly.aof来修复aof文件
aof-load-truncated yes

# 重写AOF文件时，Redis可以使用AOF文件中的RDB前同步码来更快地进行重写和恢复。 启用此选项后，重写的AOF文件由两节组成：
#   [RDB file][AOF tail]
# 加载时，Redis会识别出AOF文件以“REDIS”字符串开头并加载带前缀的RDB文件，并继续对AOF尾部进行赋值。
aof-use-rdb-preamble yes

优缺点

优点: 可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。

缺点:AOF文件比RDB文件大，且恢复速度慢。