redis优化优秀文选

Redis是一个单线程的内存数据库。下载地址如下:
http://download.redis.io/releases/redis-2.8.11.tar.gz
在Redis的src目录运行make命令,然后将可执行文件复制到新建的bin目录。可以使用如下的组织形式。

Redis持久化有两种方式 RDB和AOF

1.RDB方式

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。

RDB 是一个非常紧凑(compact)的文件,它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份

RDB 非常适用于灾难恢复(disaster recovery):它只有一个文件,并且内容都非常紧凑

RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

但是RDB方式在故障的时候,不能保证不丢失数据。



2.AOF方式

使用 AOF 持久化会让 Redis 变得非常耐久(much more durable):可以设置不同的 fsync 策略,比如无 fsync ,每秒钟一次 fsync ,或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据。

AOF 文件是一个只进行追加操作的日志文件(append only log), 因此对 AOF 文件的写入不需要进行 seek , 即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满,写入中途停机,等等), redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单: 举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF的缺点是体积通常比RDB文件大。故障恢复的时间也比RDB方式长。

如果开启每次写入都记录日志,而不是每秒记录一次日志,性能会有所下降。但是如果采用每秒写入,一旦故障会丢失最后一秒的数据。

可以通过下面的程序进行简单的测试。



设置Redis参数为appendfsync everysec

写入20w数据需要大概4s


设置Redis参数为appendfsync always

写入同样的20W数据,则需要400s左右


如果要保障数据绝对的安全,则写入的性能会降低100倍。

如果是写入密集的系统,则需要慎重的考虑。因为Redis是单线程的程序。



3.RDB迁移到AOF

RDB是Redis默认的持久化方式。

实验假设程序运行在RDB方式,并且有一定的数据。需要切换到AOF方式。



初始化运行在RDB方式的Redis,配置参数如下:


登陆Redis,输入config set appendonly yes.

这样就开启了 AOF 功能: Redis 会阻塞直到初始 AOF 文件创建完成为止, 之后 Redis 会继续处理命令请求, 并开始将写入命令追加到 AOF 文件末尾。


通过下图可以看到,AOF文件大于RDB的文件。

在配置文件中追加AOF的设置,否则下次启动就失效了。

如果启动了AOF方式,就可以关闭RDB方式了。

关闭的方法如下,将save的配置清空,并删除配置文件中的配置

将RDB迁移到AOF千万不能采用如下的方式,这样会丢失所有的数据

  1. 在配置文件中配置AOF参数
  1. 正常停止Redis
  1. 启动Redis
  1. 会震惊的发现 数据全没了

验证过程如下

开始的时候使用RDB方式,有20W数据。


修改配置文件,增加AOF配置

appendonly yes

appendfilename appendonly.aof

appendfsync always

然后正常关闭Redis



可以看到RDB的文件大小为2M

启动Redis。可以看到所有的数据库数据都被清空了。



这个时候千万别慌,mv dump.rdb到备份位置。

如果再次正常关机,就悲剧了。



正常关机之后,发现Redis dump.rdb已经被清空了。

造成这种情况我猜测是因为Redis启动的时候AOF优先于RDB,但是首次使用AOF里面还没有任何数据.
此时如果关闭Redis,则会将没有数据的redis 快照到dump.rdb,并且覆盖了原来有数据的dump.rdb文件。
所以,将Redis从RDB方式改为AOF方式,一定要在线进行修改。这样会将内存的数据先写入AOF文件,这样就不会造成数据清空的问题。

相关文档:

http://www.cnblogs.com/stephen-liu74/archive/2012/04/16/2370212.html
https://redis.readthedocs.org/en/latest/

http://blog.91gaoqing.com/archives/217.html  一致性哈希

时间: 2024-08-27 09:47:06

redis优化优秀文选的相关文章

Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

一文带你了解Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

Redis优化经验

内存管理优化 Redis Hash是value内部为一个HashMap,如果该Map的成员数比较少,则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销,这个参数控制对应在redis.conf配置文件中下面2项: hash-max-zipmap-entries 64 hash-max-zipmap-value 512 当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储,默认是64,即value内部有64个以下的成员就是使用线性紧凑存储,超过该值自动转成真正的

redis优化配置和redis.conf说明

1. redis.conf 配置参数: #是否作为守护进程运行 daemonize yes #如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid pidfile redis.pid #绑定主机IP,默认值为127.0.0.1 #bind 127.0.0.1 #Redis默认监听端口 port 6379 #客户端闲置多少秒后,断开连接,默认为300(秒) timeout 300 #日志记录等级,有4个可选值,debug,verbose(默认值),notice,warn

【转载】redis优化

原文链接 批量操作优化: 在使用redis的时候,客户端通过socket向redis服务端发起请求后,等待服务端的返回结果. 客户端请求服务器一次就发送一个报文 -> 等待服务端的返回 -> 关闭连接 如果是100个请求.1000个请求,那就得请求100次.1000次 所以使用多个请求的时候使用管道来操作(如果管道打包的命令太多占用的内存也会越大,适量) 以下是使用3种方式进行的测试(循环写入1000次): public static void main(String[] args) { lo

redis优化

https://blog.csdn.net/crisis_hiding/article/details/81490158 生产环境长时间的运行后,经常会有接口返回数据失败的情况,或者是从监控上发现数据库压力某一时间暴增.查看客户端日志发现这样的错误: redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 从错误日志看,是提示无法获取连接.有两种情况: 1.客户

redis启动时的几个报警错误-redis优化

1)The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128 2)WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcomm

mongodb redis 优化 (centos 7)

mongodb (WARNING: soft rlimits too low) 修改配置文件 /etc/security/limits.conf,添加配置信息: [[email protected] ~]# vi /etc/security/limits.conf mongod soft nofile 64000 mongod hard nofile 64000 mongod soft nproc 32000 mongod hard nproc 32000 mongodb & redis 禁用大

redis优化秒杀系统

用redis提高基于mss的秒杀系统 使用背景: 普通的基于mss框架的系统在并发量不是很高的情况下,对redis的需求不是很高.redis在系统中的角色相当于一个对象缓存器,在高并发的系统中(比如秒杀系统),在某一刻对数据库中的一条数据可能是成千上万的用户同时去访问,系统的用户体验度直接受到数据库的性能的影响.为了保证数据的完整性,用户只能串行访问数据库中的某一条记录.redis则是把记录对应的对象序列化存储在自身的容器中,减少数据库的压力.废话不多说,接下来简单介绍redis的使用. red