深圳网站设计灵点网络品牌,商城网站服务器,ih5做自适应网站,网站建设找客户目 录
CONFIG动态修改配置
慢查询
持久化 在上一篇主要对redis的了解入门#xff0c;安装#xff0c;以及基础配置#xff0c;多实例的实现#xff1a;redis的安装看我上一篇#xff1a;
Redis安装部署与使用,多实例
redis是挡在MySQL前面的#xff0c;运行在内存…目 录
CONFIG动态修改配置
慢查询
持久化 在上一篇主要对redis的了解入门安装以及基础配置多实例的实现redis的安装看我上一篇
Redis安装部署与使用,多实例
redis是挡在MySQL前面的运行在内存中的速度就快单线程的。
redis的一些基础配置
在上一篇redis介绍中介绍了bind配置使得远端主机能够登录本机redis。密码requirepass的设置以及多实例基于端口号port的配置pid文件pidfile日志文件logfile工作目录dbfilename配置。 bind 0.0.0.0 #监听地址可以用空格隔开后多个监听IP port 6379 #监听端口,默认6379/tcp tcp-keepalive 300 #tcp 会话保持时间300s daemonize no #默认no,即直接运行redis-server程序时,不作为守护进程运行而是以前台方式运行如果想在后台运行需改成yes,当redis作为守护进程运行的时候它会写一个 pid 到/var/run/redis.pid 文件 pidfile /var/run/redis_6379.pid #pid文件路径,可以修改为/apps/redis/run/redis_6379.pid loglevel notice #日志级别 logfile /path/redis.log #日志路径,示例:logfile /apps/redis/log/redis_6379.logdatabases 16 #设置数据库数量默认0-15共16个库 save 900 1 #在900秒内有1个key内容发生更改,就执行快照机制 save 300 10 #在300秒内有10个key内容发生更改,就执行快照机制 save 60 10000 #60秒内如果有10000个key以上的变化就自动快照备份 rdbcompression yes #持久化到RDB文件时是否压缩yes为压缩no则反之 dbfilename dump.rdb #快照文件名 dir ./ #快照文件保存路径示例dir /apps/redis/data maxclients 10000 #Redis最大连接客户端 appendfilename appendonly.aof #文本文件AOF的文件名存放在dir指令指定的目录中 appendfsync everysec #aof持久化策略的配置 #no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒最多会丢失30s的数据 #always表示每次写入都执行fsync以保证数据同步到磁盘,安全性高,性能较差 #everysec表示每秒执行一次fsync可能会导致丢失这1s数据,此为默认值,也生产建议值 auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小 cluster-enabled yes #是否开启集群模式默认不开启,即单机模式 CONFIG动态修改配置 config命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等 注意不是所有配置都可以动态修改且此方式无法持久保存 CONFIG SET parameter value config set 参数 值 config set 参数值。时间复杂度是O(1)。CONFIG SET 命令可以动态调整redis服务器的配置(confuiguration)而无须重启。
也可以使用它修改配置参数或者改变redis的持久化persistence方式
CONFIG SET 可以修改的配置命令可以使用命令CONFIG GET * 来列出来所有被CONFIG SET 修改的配置参数都会立即生效。
CONFIG GET 命令用于取得运行中的redis服务器的配置参数(configuration parameters)在redis2.4版本中有部分参数没有办法用config get访问但是在最新的Redis2.6版本中所有配置参数都已经可以用config get访问了。
config get 接受单个参数parameter作为搜索关键字查找到所有匹配的配置参数其中参数和值以键值对的方式排列。
比如执行config get s* 命令服务器会返回所有以s开头的配置参数及参数值的。
案例
登录redis
[rootNode1 ~]#:redis-cli使用动态方式查看日志文件路径 查看以lo开头的配置项 显示出了有日志文件路径和日志级别。
相当于Python中以字典的形式存储
{logfile:/apps/redis/log/redis.log,loglevel:notice}
config设置密码
127.0.0.1:6379 config set requirepass 12321
OK可以看到必须使用密码登录-a选项 设置空密码 慢查询
执行命令有发送命令排队等待命令的执行执行命令返回结果。
慢查询发生在第3阶段客户端超时不一定慢查询但是慢查询时客户端超时的一个可能因素。
范例slowlog。修改两条配置 slowlog-log-slower-than 1 #指定为超过1us即为慢的指令 slowlog-max-len 1024 #指定保存1024条慢记录 指定为超过1微妙即为慢的指令
指定保存1024条慢记录 查看慢查询具体情况看前两条 发现记录了我们输入命令查询的语句。
如果get后面不加数字就是查看全部 数据库切换使用select 0,select 1。。。 当前默认是0
进入数据库使用select 1 在当前设置键值 切换到数据库1
获取不到在0上的name。再切换回去就有了 在1上也设置一个name 使用flushdb命令可以清空当前的数据库
flushall清空所有的数据库 这里清空之后我们再重新设置一个name叫python。去0上查看name为linux。执行flushall命令清空所有再回来1上查看namepython是否被清空。 flushdb清空当前数据库flushall清空所有数据库。
持久化
redis虽然是一个内存级别的缓存程序也就是redis是使用内存进行数据的缓存的但是其可以将内存的数据按照一定的策略保存到硬盘上从而实现数据持久保存的目的目前支持redis支持两种不同的方式的数据持久化保存机制分别是RDB和AOF。
持久化的功能redis是内存数据库所有数据都是保存在内存中为了避免服务器断点等原因导致redis进程异常退出后数据永久丢失需要定期将redis中的数据以某种形式(数据或者命令)从内存中保存到硬盘上当下次redis重启时利用持久化文件实现数据恢复除此之外为了进行灾难备份可以持久化将文件拷贝到一个远程位置(如备份服务器)。
redis提供两种方式进行持久化 RDB持久化原理是将redis在内存中的数据库记录定时保存到磁盘上类似于快照。 AOF持久化原理是将redis的操作日志以追加的方式写入文件类似于mysql的binlog 由于AOF持久性实时性更好即发生特殊情况导致数据丢失时丢失的数据更少因此是目前主流的持久化方式不过RDB持久化仍然具有可用性。
保存持久化
当一个键设置了多个值那么get获取键时对应的值就是最近一次的修改。
127.0.0.1:6379 set name linux
OK
127.0.0.1:6379 set name linux1
OK
127.0.0.1:6379 set name linux2
OK
127.0.0.1:6379 get name
linux2
127.0.0.1:6379
那么前面设置的两个值就会残留。占用空间。使用save可以保存持久化。还有一个是bgsave它不会影响操作后台执行不影响操作。重写机制会把最近的记录下载也就是记录linux3。 建议使用bgsave
持久化中 dir ./ #快照文件保存路径示例dir /apps/redis/data。如果不指定在登录redis时save会出现错误 dbfilename dump.rdb #快照文件名 appendfilename appendonly.aof 和rdb文件共用dir aof保存文件的名字 两个保存文件共用dir中指定的目录 AOF默认是关闭的在配置文件中开启appendonly
RDB模式基于时间快照其默认只保留当前最新的一次快照特点是执行速度比较快缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。
RDB bgsave实现快照的具体过程 Redis从master主进程先fork出一个子进程使用写时复制机制子进程将内存的数据保存为一个临时文件比如:tmp-.rdb当数据保存完成之后再将上一次保存的RDB文件替换掉然后关闭子进程这样可以保证每一次做RDB快照保存的数据都是完整的因为直接替换RDB文件的时候,可能会出现突然断电等问题,而导致RDB文件还没有保存完整就因为突然关机停止保存,而导致数据丢失的情况.后续可以手动将每次生成的RDB文件进行备份这样可以最大化保存历史数据 RDB持久化触发条件分为手动触发和自动触发两种
手动触发save命令和bgsave命令都可以生成RDB文件。
save命令会阻塞redis服务器进程直到RDB文件创建完毕为止在redis服务器阻塞期间服务器不能处理任何命令请求。
而bgsave命令会创建一个子进程由子进程来负责创建RDB文件父进程(即redis主进程)则继续处理请求。
bgsave命令执行过程中只有fork子进程时会阻塞服务器而对于save命令整个过程都会阻塞服务器因此save已基本被废弃线上环境要杜绝save的使用。往往生产环境bgsave依然不允许轻易使用。
自动触发
在自动触发RDB持久化时redis也会选择bgsave而不是save来进行持久化。
save m n
自动触发最常见的情况是在配置文件中通过save m n指定当m秒内发生n次变化时会触发bgsave。
自动触发两个条件都要满足在60秒内触发两次数据变化才会启动保存。
相关配置 save 900 1 #900s内修改了1个key即触发保存RDB save 300 10 #300s内修改了10个key即触发保存RDB save 60 10000 #60s内修改了10000个key即触发保存RDB dbfilename dump.rdb dir ./ #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes 备份操作执行save的时候注意配置文件dir指定为/apps/redis/data/下。
可以同时执行保存命令和查看进程可以看到如图所示 自动触发 修改配置文件 #save 900 1 #save 300 10 #save 60 10000 save 60 2 bgsave 在后台备份的时候不知道什么时候完成 [rootNode1 redis]#:redis-cli bgsave ;redis-cli info Persistence |grep rdb_bgsave_in_progress Background saving started rdb_bgsave_in_progress:1 [rootNode1 redis]#: [rootNode1 redis]#:redis-cli info Persistence |grep rdb_bgsave_in_progress rdb_bgsave_in_progress:0 RDB的优缺点 优点 1.RDB快照保存了某个时间点的数据可以通过脚本执行redis指令bgsave(非阻塞后台执行)或者save(会阻塞写操作,不推荐)命令自定义时间点备份可以保留多个备份当出现问题可以恢复到不同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析比如: 可以在最近的24小时内每小时备份一次RDB文件并且在每个月的每一天也备份一个RDB文件。这样的话即使遇上问题也可以随时将数据集还原到不同的版本。 缺点 2.RDB可以最大化Redis的性能父进程在保存 RDB文件时唯一要做的就是fork出一个子进程然后这个子进程就会处理接下来的所有保存工作父进程无须执行任何磁盘 I/O 操作。 3.RDB在大量数据,比如几个G的数据恢复的速度比AOF的快 1.不能实时保存数据可能会丢失自上一次执行RDB备份到当前的内存数据如果你需要尽量避免在服务器故障时丢失数据那么RDB并不适合。虽然Redis允许设置不同的保存点save point来控制保存RDB文件的频率但是因为RDB文件需要保存整个数据集的状态所以它并不是一个轻松快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下一旦发生故障停机你就可能会丢失好几分钟的数据。 2.当数据量非常大的时候从父进程fork子进程进行保存至RDB文件时需要一点时间可能是毫秒或者秒取决于磁盘IO性能在数据集比较庞大时fork()可能会非常耗时造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大并且CPU时间非常紧张的话那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()但无论AOF重写的执行间隔有多长数据的持久性都不会有任何损失。 AOF模式
AOF按照操作顺序依次将操作追加到指定的日志文件末尾。
AOF和RDB一样使用了写时复制机制AOF默认为每秒钟fsync一次即将执行的命令保存到AOF文件当中这样即使redis服务器发生故障最多只丢失1秒中之内的数据也可以设置不同的fsync策略always即设置每次执行命令的时候执行fsyncfsync会在后台执行线程所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的影响。
同时启用RDB和AOF进行恢复时默认AOF文件优先级高于RDB文件即会使用AOF文件进行恢复。
注意AOF模式默认是关闭的第一次开启AOF后并重启服务生效后会因为AOF的优先级高于RDB而先恢复AOF文件
AOF默认没有数据文件存在从而导致所有数据丢失。
是否开启AOF appendonly no #是否开启AOF日志记录默认redis使用的是rdb方式持久化这种方式在许多应用中已经足够用了但是redis如果中途宕机会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)根据save来策略进行持久化Append Only File是另一种持久化方式可以提供更好的持久化特性Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件每次启动时Redis都会先把这个文件的数据读入内存里先忽略RDB文件。默认不启用此功能 开启后重启默认是与RDB在一个路径下 数据发生修改后会自动记录 保存规则 everysec表示每秒执行一次fsync可能会导致丢失这1s数据此为默认值也生产建议值。 重写规则rewrite相关。 no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes 当如果同时开启了AOF和RDB是如何正确恢复
AOF优先级比RDB要高。
同时开启只会同步AOF文件。
AOF重写机制 将一些重复的,可以合并的,过期的数据重新写入一个新的AOF文件,从而节约AOF备份占用的硬盘空间,也能加速恢复过程 可以手动执行 bgrewriteaof 触发AOF,第一次开启AOF功能,或定义自动 rewrite 策略 ---end---
