我是靠谱客的博主 勤恳雪碧,最近开发中收集的这篇文章主要介绍Redis如何保证数据安全与性能保障,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

一、持久化

      Redis提供了两种不同的持久化方法来将数据存储到硬盘里。一种叫快照(snapshotting),另一种叫只追加文件(append-only file,AOF) 。这两种持久化方法可以同时使用,也可以单独使用。

1.快照

    redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。

redis持久化配置

#RDB核心规则配置 save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘
中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的
数据快照写入磁盘。若不想用RDB方案,可以用 save ""

save 60 10000

#当RDB持久化出现错误后,是否依然进行继续进行工作,yes:不能进行工作,no:可以继续进行工作,可以通
过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes


#配置存储至本地数据库时是否压缩数据,默认为yes。Redis采用LZF压缩方式,但占用了一点CPU的时间。若关闭该选项,
但会导致数据库文件变的巨大。建议开启。
rdbcompression yes

#指定本地数据库文件名,一般采用默认的 dump.rdb
dbfilename dump.rdb

#数据目录,数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir /usr/local/redis/var

      根据配置,快照被写入dbfilename选项的文件里面。并存储在dir目录下,如果在新的快照文件创建完毕之前,Redis、系统或者硬件其中任意一个崩溃,那么Redis将丢失最近一次创建快照之后写入的所有数据。

创建快照的方法:

  1. 客户端向redis发送BGSAVE命令,会建立子进程将快照写入存储,同时redis可以正常接收命令。

  2. 客户端向redis发SAVE命令,redis在执行写入存储前不接收命令。

  3. 配置文件设置快照,例如save 60 5000,可配置多个。达到条件时触发BGSAVE命令。

  4. SHUTDOWN时,会触发SAVE命令。

  5. slave redis发关SYNC命令后,主启动BGSAVE命令。

       如果系统发生崩溃,用户将对视最近一次生成快照之后更改的所有数据。因此,快照快照持久化只适用于那些丢失一部分数据也不会造成问题的应用程序。

性能

       当Redis内存占用量达到数十个GB,并且剩余的空闲内存并不多,那么执行BGSAVE可能会导致系统长时间地停顿,也可能引发系统大量地使用虚拟内存,从而导致Redis的性能降低至无法使用的程度。

      为了防止Redis因为创建子进程而出现停顿,我们可以考虑关闭自动保存,转而通过手动发送BGSAVE或者SAVE进行之九华。SAVE命令会一直阻塞Redis而导致Redis停顿;并且因为没有子程序在正度资源,所以SAVE创建快照的速度会比BGSAVE创建快照的速度更快一些。

2.AOF持久化

    AOF持久化会将被执行的写命令写到AOF文件的末尾,以此来记录数据发生的变化。Redis只要从头到尾执行一次AOF文件包含的命令,就可以恢复AOF文件记录的数据集。

持久化配置

#Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写
操作,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认redis使用的是rdb方式持久化,这种方式在许多应用中已经足够用了。但是redis如果中途宕机,会导致可
能有几分钟的数据丢失,根据save来策略进行持久化,Append Only File是另一种持久化方式,可以提供更好的
持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件,每次启动时Redis都会先把这
个文件的数据读入内存里,先忽略RDB文件。若开启rdb则将no改为yes
appendonly no


#aof持久化策略的配置
#no表示不执行fsync,由操作系统保证数据同步到磁盘,速度最快
#always表示每次写入都执行fsync,以保证数据同步到磁盘
#everysec表示每秒执行一次fsync,可能会导致丢失这1s数据
#always请谨慎使用,这个选项让Redis每次只写入一个命令,可能会引发严重的写入放大问题
#在某些情况下会导致固态硬盘寿命降低。
appendfsync everysec

 

# 在aof重写或者写入rdb文件的时候,会执行大量IO,此时对于everysec和always的aof模式来说,执行
fsync会造成阻塞过长时间,no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的
应用,这个字段可以设置为yes,否则还是设置为no,这样对持久化特性来说这是更安全的选择。设置为yes表
示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入,默认为no,建议yes。Linux的
默认fsync策略是30秒。可能丢失30秒数据
no-appendfsync-on-rewrite no
 

#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写,即当aof文件
增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得
到AOF文件大小的二倍(设置为100)时,自动启动新的日志重写过程
auto-aof-rewrite-percentage 100
 

#设置允许重写的最小aof文件大小,避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb


#数据目录,数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir /usr/local/redis/var

       随着Redis不断运行,AOF文件体积也会不断增加,为了解决AOF文件不断增大的问题,用户可以发送BGREWRITEAOF命令,这个命令会通过移除AOF文件中的冗余命令。

3.复制

       Redis可以使用一个主服务器(master)和多个从服务器(slave)发送更新,并使用从服务器处理所有读请求,来实现自己的复制特性,并将其作为扩展性能的一种手段。

配置

#从服务器 host主服务器的ip  port主服务器端口
slaveof host port

     从服务器在连接一个主服务器的时候,主服务器会创建一个快照文件并将其发送给从服务器。

步骤:

主服务器从服务器
(等待命令进入)连接(或者重连接)主服务器,发送SYNC命令
开始执行BGSAVE,并使用缓冲区记录BGSAVE之后执行的所有命令根据配置项来决定是继续使用现有的都数据(如果有的话)来处理客户端的命令请求,还是向发送请求的客户端返回错误
BGSAVE执行完毕,向从服务器发送快照文件,并在发送期间继续使用缓冲区记录被执行的写命令丢弃返回旧数据(如果有的话),开始载入主服务器发来的快照文件
快照文件发送完毕,开始向从服务器发送存储在缓冲区里面的写命令完成对快照文件的解释操作,像往常一样开始接受命令请求
缓冲区存储的写命令发送完毕;从现在开始每执行一个写命令,就向从服务器发送相同的写命令执行主服务器发来的所有存储在缓冲区里面的写命令;并从现在开始,接受并执行主服务器传来的每个写命令

        从服务器在同步时,会清空自己的所有数据。

主从服务器--哨兵模式文章推荐:https://www.jianshu.com/p/06ab9daf921d

4.验证持久化文件

     如果遇到系统故障时进行数据恢复的工具。Redis提供了两个命令行程序redis-check-aof和redis-check-dump,他们可以检查文件的状态,并在有需要的情况下对文件进行修复。

5.事务

     所谓事务(Transaction) ,是指作为单个逻辑工作单元执行的一系列操作。事务必须满足ACID原则(原子性、一致性、隔离性和持久性)。简单来说事务其实就是打包一组操作(或者命令)作为一个整体,在事务处理时将顺序执行这些操作,并返回结果,如果其中任何一个环节出错,所有的操作将被回滚。

第一步键入MULTI命令标识事务的开始

第二步执行业务逻辑

第三部 exec执行/DISCARD回滚

需要注意的是:

1.Redis的事务没有关系数据库事务提供的回滚(rollback),所以开发者必须在事务执行失败后进行后续的处理;

2.如果在一个事务中的命令出现错误,那么所有的命令都不会执行;

3.如果在一个事务中出现运行错误,那么正确的命令会被执行。

WATCH

研究过java的J.U.C包的人应该都知道CAS,CAS是一种保证原子性的操作。那么redis也提供了这样的一个机制,就是利用watch命令来实现的。

WATCH命令可以监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执行,监控一直持续到EXEC命令。

6.非事务性流水线

       使用事务的其中一个好处就是底层的客户端会通过使用流水线来提高事务执行时的性能。使用非事务型流水线(non-transactional pipeline)同样可以获得相似的性能提升,并且可以让用户同时执行多个不同的命令。

       MULTI和EXEC也会消耗资源,并且可能会导致其他重要的命令被延迟执行。但也可以在不使用MULTI和EXEC的情况下,获得流水线带来的所有好处。

pipe = conn.pipeline()

       在执行pipeline()时传入True作为参数,或者不传入任何参数,那么客户端将使用MULTI和EXEC包裹起用户要执行的所有命令。如果传入False为参数,那么客户端同样会像执行事务那样收集用户要执行的所有命令,只是不再使用MULTI和EXEC包裹这些命令。如果用户需要向Redis发送多个命令,并且对于这些命令来说,一个命令的执行结果并不会影响另一个命令的输入,而且这些命令也不需要以事务的方式来执行的话,那么我们可以通过向pipeline()方法传入False来进一步提升Redis的整体性能。

最后

以上就是勤恳雪碧为你收集整理的Redis如何保证数据安全与性能保障的全部内容,希望文章能够帮你解决Redis如何保证数据安全与性能保障所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(41)

评论列表共有 0 条评论

立即
投稿
返回
顶部