曾志高翔, 江湖人称曾老大。多年互联网运维工作经验,曾负责过大规模集群架构自动化运维管理工作。擅长Web集群架构与自动化运维,曾负责国内某大型金融公司运维工作。 个人博客:"DBA老司机带你删库跑路"
软件说明 |
---|
Redis是一款开源的,ANSI C语言编写的,高级键值(key-value)缓存和支持永久存储NoSQL数据库产品。 Redis采用内存(In-Memory)数据集(DataSet) 。 支持多种数据类型。 运行于大多数POSIX系统,如Linux、*BSD、OS X等。 作者: Salvatore Sanfilippo
软件特性 |
---|
软件获取和帮助 |
---|
软件功能 |
---|
1)高速读写 2)数据类型丰富 3)支持持久化 4)多种内存分配及回收策略 5)支持事物 6)消息队列、消息订阅 7)支持高可用 8)支持分布式分片集群
企业缓存数据库解决方案对比 |
---|
Memcached: 1)优点:高性能读写、单一数据类型、支持客户端式分布式集群、一致性hash多核结构、多线程读写性能高。 2)缺点:无持久化、节点故障可能出现缓存穿透、分布式需要客户端实现、跨机房数据同步困难、架构扩容复杂度高
Redis: 1)优点:高性能读写、多数据类型支持、数据持久化、高可用架构、支持自定义虚拟内存、支持分布式分片集群、单线程读写性能极高 2)缺点:多线程读写较Memcached慢
Tair: 1)优点:高性能读写、支持三种存储引擎(ddb、rdb、ldb)、支持高可用、支持分布式分片集群、支撑了几乎所有淘宝业务的缓存。 2)缺点:单机情况下,读写性能较其他两种产品较慢

图1·memcached、redis、tair单线程写入对比图

图2·memcached、redis、tair单线程读取对比图

图3·memcached、redis、tair多线程写入对比图

图4·memcached、redis、tair多线程读取对比图
对比结论 |
---|
redis一般在企业中,是单机多实例架构
#下载
[root@db01 src]# wget http://download.redis.io/releases/redis-3.2.12.tar.gz
#解压
[root@db01 src]# tar xf redis-3.2.12.tar.gz
#移动到指定目录
[root@db01 src]# mv redis-3.2.12 /application/
#做软链接
[root@db01 src]# ln -s /application/redis-3.2.12 /application/redis
#进入redis目录
[root@db01 src]# cd /application/redis
#编译
[root@db01 redis]# make
#添加环境变量
[root@db01 redis]# vim /etc/profile.d/redis.sh
export PATH="/application/redis/src:$PATH"
#启动redis
[root@db01 redis]# src/redis-server &
#连接redis
[root@db01 redis]# redis-cli
#退出redis
127.0.0.1:6379> quit
#关闭redis连接
[root@db01 redis]# redis-cli
127.0.0.1:6379> shutdown
redis基本配置 |
---|
#创建redis工作目录
[root@db01 redis]# mkdir -p /etc/redis/6379
#创建redis配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
daemonize yes //守护进程模式启动
port 6379 //端口
logfile /etc/redis/6379/redis.log //日志文件位置
dir /etc/redis/6379 //持久化数据文件存储位置
dbfilename dump.rdb //RDB持久化数据文件名称
#指定配置文件启动redis
[root@db01 redis]# redis-server /etc/redis/6379/redis.conf
redis基本操作 |
---|
#连接redis
[root@db01 redis]# redis-cli
#设置键值对
127.0.0.1:6379> set foo bar
OK
#取出值
127.0.0.1:6379> get foo
"bar"
redis安全配置 |
---|
#添加到配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
bind 127.0.0.1 10.0.0.51
#添加配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
requirepass zls
#不加认证,报错
[root@db01 redis]# redis-cli
127.0.0.1:6379> set name zhangsan
(error) NOAUTH Authentication required.
#连接方式1
[root@db01 redis]# redis-cli
127.0.0.1:6379> AUTH zls
127.0.0.1:6379> set name zhangsan
OK
#连接方式2
[root@db01 redis]# redis-cli -a zls
127.0.0.1:6379> set name lisi
OK
redis在线查看和修改配置 |
---|
#查看配置文件中的监听地址
127.0.0.1:6379> CONFIG GET bind
1) "bind"
2) "127.0.0.1 10.0.0.51"
#查看dir
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/etc/redis/6379"
#查看所有配置
127.0.0.1:6379> CONFIG GET *
#修改配置,即时生效
127.0.0.1:6379> CONFIG SET requirepass 123
OK
#测试修改后连接
[root@db01 redis]# redis-cli -a 123
127.0.0.1:6379> set age 18
OK
#查看配置文件
[root@db01 redis]# cat /etc/redis/6379/redis.conf
daemonize yes
port 6379
logfile /etc/redis/6379/redis.log
dir /etc/redis/6379
dbfilename dump.rdb
bind 127.0.0.1 10.0.0.51
requirepass zls //可以看出,配置文件中是没有改变的,只要redis不重启,密码就是新改的
什么是持久化?
持久化:就是将内存中的数据,写入到磁盘上,并且永久存在的。
RDB 持久化介绍 |
---|
可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。
RDB持久化优点:
RDB持久化缺点
RDB持久化优缺点总结
RDB持久化核心配置参数
#编辑配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
#持久化数据文件存储位置
dir /etc/redis/6379
#rdb持久化数据文件名
dbfilename dump.rdb
#900秒(15分钟)内有1个更改
save 900 1
#300秒(5分钟)内有10个更改
save 300 10
#60秒(1分钟)内有10000个更改
save 60 10000
AOF 持久化介绍 |
---|
AOF(append only file)只追加文件,记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。
AOF持久化优点:
AOF持久化缺点:
AOF持久化优缺点总结
AOF持久化核心配置参数
#修改配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
#是否打开AOF日志功能
appendonly yes/no
#每一条命令都立即同步到AOF
appendfsync always
#每秒写一次
appendfsync everysec
#写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到AOF
appendfsync no
RDB 和 AOF ,我应该用哪一个? |
---|
1)一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。
2)如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。
3)有很多用户单独使用AOF,但是我们并不鼓励这样,因为时常进行RDB快照非常方便于数据库备份,启动速度也较之快,还避免了AOF引擎的bug。
4)个人感触:在企业中,通常都使用RDB来做持久化,因为一般redis是在做MySQL的缓存,就算缓存数据丢失,真实的数据还是在MySQL中,之所以用缓存是为了速度,性能而考虑,所以还是建议使用RDB持久化,相对来说会好一些,除非专门用redis来做一个key:value的数据库,而且数据很重要,那么可以考虑使用AOF
注意:基于这些原因,将来我们可能会统一AOF和RDB为一种单一的持久化模型(长远计划)。
RDB快照的工作方式 |
---|
1)默认情况下,Redis保存数据集快照到磁盘,名为dump.rdb的二进制文件。你可以设置让Redis在N秒内至少有M次数据集改动时保存数据集,或者你也可以手动调用SAVE或者BGSAVE命令。
2)在上文中我们已经在配置文件中做过对应的配置: 例如,这个配置会让Redis在每个60秒内至少有1000次键改动时自动转储数据集到磁盘: save 60 1000
3)当 Redis 需要保存 dump.rdb 文件时,服务器执行以下操作:
4)这种方式使得 Redis 可以从写时复制机制中获益。
AOF重写功能介绍 |
---|
1)因为 AOF 的运作方式是不断地将命令追加到文件的末尾,所以随着写入命令的不断增加, AOF 文件的体积也变得越来越大。举个例子,如果你对一个计数器调用了 100 次 INCR ,那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录。然而在实际上,只使用一条 SET 命令已经足以保存计数器的当前值了,其余 99 条记录实际上都是多余的。
2)为了处理这种情况, Redis 支持一种有趣的特性:可以在不断服务客户端的情况下,对 AOF 文件进行重建。执行 BGREWRITEAOF 命令, Redis 将生产一个新的 AOF 文件,这个文件包含重建当前数据集所需的最少命令。
AOF有多持久? |
---|
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。 有三个选项:
推荐(并且也是默认)的措施为每秒 fsync 一次,这种 fsync 策略可以兼顾速度和安全性。
总是 fsync 的策略在实际使用中非常慢,即使在 Redis2.0 对相关的程序进行了改进之后仍是如此。频繁调用 fsync 注定了这种策略不可能快得起来。
如果 AOF 文件出错了,怎么办? |
---|
服务器可能在程序正在对AOF文件进行写入时停机,如果停机造成了AOF文件出错,那么 Redis 在重启时会拒绝载入这个 AOF 文件,从而确保数据的一致性不会被破坏。
当发生 AOF 文件出错时,可以用以下方法来修复出错的 AOF 文件:
RDB 和 AOF 之间的相互作用 |
---|
备份 Redis 数据 |
---|
1)Redis 对于数据备份是非常友好的,因为你可以在服务器运行的时候对 RDB 文件进行复制: RDB 文件一旦被创建,就不会进行任何修改。
2)当服务器要创建一个新的 RDB 文件时,它先将文件的内容保存在一个临时文件里面,当临时文件写入完毕时,程序才使用临时文件替换原来的 RDB 文件。
3)这也就是说,无论何时, 复制 RDB 文件都是绝对安全的。
以下是我们的建议: 1)创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹, 并且每天将一个 RDB 文件备份到另一个文件夹。
2)确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每日快照。
3)至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到你运行 Redis 服务器的物理机器之外。
RDB持久化高级配置 |
---|
#编辑配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
#后台备份进程出错时,主进程停不停止写入? 主进程不停止容易造成数据不一致
stop-writes-on-bgsave-error yes
#导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做
rdbcompression yes
#导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致
rdbchecksum yes
AOF持久化高级配置 |
---|
#编辑配置文件
[root@db01 redis]# vim /etc/redis/6379/redis.conf
#正在导出rdb快照的过程中,要不要停止同步aof
no-appendfsync-on-rewrite yes/no
#aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候,会重复重写多次
auto-aof-rewrite-percentage 100
#aof文件,至少超过64M时,重写
auto-aof-rewrite-min-size 64mb