Redis

云隐智者

已于 2025-02-26 14:54:01 修改

阅读量1k

点赞数 8

分类专栏： redis 文章标签：数据库 redis

于 2025-02-26 14:53:33 首次发布

本文链接：https://blog.youkuaiyun.com/2302_77582029/article/details/145878963

版权

redis 专栏收录该内容

6 篇文章

订阅专栏

一、 Redis简介

随着互联网+和大数据时代的来临，传统的关系型数据库已经不能满足中大型网站日益增长的访问量和数据量，这个时候就需要一种能够快速存取数据的组件来缓解数据库服务I/O的压力，来解决系统性能上的瓶颈。

数据库应用的发展历史：

1：在互联网大数据时代来临前，企业的一些内部信息管理系统，一个单个数据库实例就可以应付系统的需求

单数据库实例

2：随着系统访问量用户的增多，数据量的增大，单个数据库实例已经满足不了系统读取数据的需求

缓存(ehCache/MemCached)+数据库实例

3：缓存可以缓解数据库的读取压力，但是数据量的写入压力持续增大，可以采取数据库主从进行读写分离

缓存+主从数据库+读写分离

4: 数据量再次增大，读写分离以后，主数据库的写库压力出现瓶颈

缓存+主从数据库集群+读写分离 +分库分表

5 ：互联网+大数据时代来临，关系型数据库不能很好的存取一些并发性大，实时性高而且格式不固定的数据

NoSql数据库 +主从数据库集群+读写分离 +分库分表

什么是redis?

Redis是当前比较热门的NOSQL数据库系统之一，它是一个开源的使用C语言编写的键值对（key-value）数据存储系统（区别于MySQL的二维表格的形式存储。）

lNoSql: Not Only Sql 泛指非关系型数据库，如：Redis / MongoDB/Hbase

l关系型数据库： Oracle/ Mysql/ SqlServer

左边rdbms右边nosql很多以json格式进行存储数据的(mongodb，redis)

Redis和Memcache类似，但很大程度补偿了Memcache的不足，Redis数据都是缓存在计算机内存中，不同的是，Memcache只能将数据缓存到内存中，无法自动定期写入硬盘，这就表示，一断电或重启，内存清空，数据丢失。所以Memcache的应用场景适用于缓存无需持久化的数据。而Redis不同的是它会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，实现数据的持久化.

1.1、 Redis的特点

1、Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

2、Redis不仅仅支持简单的key-value类型的数据，同时还提供字符串（strings）、lists（列表）、sets（集合）和zsets（有序集合）、散列（hash）等数据结构的存储。

3、Redis支持数据的备份，即master-slave模式的数据备份。

4、性能极高：Redis能读的速度是110000次/s,写的速度是81000次/s 。

5、原子性：Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。

6、丰富的特性：Redis还支持 publish(发布)/subscribe（订阅）, 通知, key 过期等等特性。

Redis与memcache的区别：

1、Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等。

2、数据结构：Memcache仅能支持简单的K-V形式，Redis不仅仅支持简单的k/v类型的数据，同时还提供字符串（strings）、lists（列表）、sets（集合）和zsets（有序集合）、散列（hash）等数据结构的存储。

3、虚拟内存：Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘。Memcache当内存用完之后，会根据LRU策略，计算最近没有使用过的数据，将其进行替换。

4、过期策略：memcache在set时就指定，例如set key 1008,即永不过期。Redis可以通过例如expire 设定，例如expire name 10

5、分布式：redis可以做一主多从。Memcached的分布式不是在服务器端实现的，而是在客户端应用中实现的，即通过内置算法制定目标数据的节点，如下图所示

6、存储数据安全：memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）

7、灾难恢复：memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复

8、Redis支持数据的备份，即master-slave模式的数据备份。

9、Memcache支持多线程,Redis支持单线程，CPU利用方面，Memcache利用率更高。

10、应用场景： Memcache做缓存，适合多读少写，大数据量的情况（如人人网大量查询用户信息、好友信息、文章信息等），减轻数据库负载，提升性能。Redis适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统（如新浪微博的计数和微博发布部分系统，对数据安全性、读写要求都很高）。

Redis服务端的默认端口是：6379

持久化的两种方式：

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化：

一种是RDB持久化，原理是将Reids在内存中的数据定时dump到磁盘上。性能高，但可能会引起一定程度的数据丢失。

另外一种是AOF（append only file）持久化，原理是将Reids的操作日志以追加的方式写入文件，类似mysql的binlog，记录每次更新的日志。

Redis的应用场景：

以电商平台为例，Redis在系统架构中的一个位置

单点登陆/直播平台里面在线好友列表/抢购、秒杀/商品的排行榜/点赞/数据过期

Redis的应用场景：

1、缓存（热点数据的缓存）

热点数据（经常会被查询，但是不经常被修改或者删除的数据），由于redis访问速度快、支持的数据类型比较丰富，首选是使用redis缓存。

Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis

update或者delete数据前，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据

缓存现在几乎是所有中大型网站都在用的，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。另外结合expire，我们可以设置过期时间然后再进行缓存更新操作。所以，现在Redis用在缓存的场合非常多。

2、排行榜

很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据结构能实现各种复杂的排行榜应用。

3、计数器

什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。

4、消息系统

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

还有其他应用场景，就不一一介绍了。

Redis部署方案

Redis的几种常见使用方式包括：

1、 redis单机模式

Redis单机模式，采用单个Redis节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

• 架构简单，部署方便；

• 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务；

缺点：

• 不保证数据的可靠性；

• 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务；

• 高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用Memcached替代。

2、 Redis多副本（主从）

Redis多副本，采用主从（replication）部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

3、 Redis sentinel（哨兵模式） sentinel [ˈsentɪnl]

当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)没有实现自动进行主备切换，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

Redis Sentinel是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。

而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行切换。redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案。

sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台（Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个，官方建议至少3个），防止某一台sentinel无法连接到master导致误切换。其结构如下:

Sentinel由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

例如下图所示：

在Server1 掉线后：

升级Server2 为新的主服务器：

选出新的master节点，redis sentinel会选一个合适的slave来升级为master，那么，如何选择一个合适的slave呢？顺序如下：

1). 选择slave-priority最高的slave节点（默认是相同）。

2). 选择复制偏移量最大的节点。

3). 如果以上两个条件都不满足，选runId最小的（启动最早的）。

Sentinel的作用

这里的哨兵有两个作用：

l通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

l当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

注：然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

sentinel哨兵通过如下功能实现故障切换：

描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时（大于等于配置文件指定的值），那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。当客户端试图连接失效的主服务器时，sentine集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

（1）monitoring:监控redis是否正常运行

（2）notification：通知application错误信息

（3）failover:当某个master死掉，选择另外一个slave升级为master,更新master-slave关系。

（4）configuration provider：client通过sentinel获取redis地址，并在failover时更新地址。

注：主观下线和客观下线

　　主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

　　客观下线：Objectively Down，简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover。

　　从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip（流言）协议，如果一个sentinel收到了足够多的sentinel发来消息告诉它某个master已经down掉了，SDOWN状态就会变成ODOWN状态。

redis-cluster(集群模式)

Redis Sentinel集群模式中，随着业务量和数据量增加，性能达到redis单节点瓶颈，垂直扩容受机器限制，水平扩容涉及对应用的影响以及数据迁移中数据丢失风险。针对这些痛点,Redis3.0推出cluster分布式集群方案，当遇到单节点内存，并发，流量瓶颈时，采用cluster方案实现负载均衡。

Redis Cluster有效地解决了 Redis 分布式方面的需求。分布式数据存储方案中最为重要的一点就是数据分片，也就是所谓的 Sharding。

为了使得集群能够水平扩展，首要解决的问题就是如何将整个数据集按照一定的规则分配到多个节点上，常用的数据分片的方法有：范围分片，哈希分片，一致性哈希算法，哈希槽等。

Redis Cluster 采用虚拟哈希槽分区，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，计算公式：slot = CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。

下图展现一个五个节点构成的集群，每个节点平均大约负责3276个槽，以及通过计算公式映射到对应节点的对应槽的过程。

Redis Cluster 一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群，其中三个为主节点，三个为从节点。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。

一般来说，主 Redis 节点会处理 Clients 的读写操作，而从节点只处理读操作。

官网地址

https://redis.io

二、安装reids

2.1、上传软件包

[root@cong11 ~]# ls

redis-7.4.1.tar.gz

[root@cong11 ~]# tar -zxvf redis-7.4.1.tar.gz

2.2、安装gcc

[root@cong11 ~]# yum install -y gcc

2.3、编译安装

[root@cong11 ~]# cd redis-7.4.1

[root@cong11 redis-7.4.1]# make

[root@cong11 redis-7.4.1]# cd src/

[root@cong11 src]# make install PREFIX=/usr/local/redis

2.4、移动配置文件到指定位置

[root@cong11 src]# cd ..

[root@cong11 redis-7.4.1]# mkdir /usr/local/redis/etc

[root@cong11 redis-7.4.1]# cp redis.conf /usr/local/redis/etc/

2.5、启动redis服务

[root@cong11 ~]# /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

以上警告信息的解决方法：

执行ulimit -n查看当前用户打开的最大文件数

[root@cong11 ~]# ulimit -n

1024

修改/etc/security/limits.conf文件，在文件末尾添加下面的两行：

* soft nofile 10032

* hard nofile 10032

修改/etc/pam.d/login文件，在文件末尾添加下面的内容：

session required /usr/lib64/security/pam_limits.so

重新登录使修改生效

执行ulimit -n查看：

[root@cong11 ~]# ulimit -n

10032

在/etc/sysctl.conf文件中添加下面的两行内容：

net.core.somaxconn = 511

vm.overcommit_memory = 1

执行sysctl -p使内核参数修改生效

执行下面的命令：

[root@cong11 ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled

再次启动redis服务：

[root@cong11 ~]# /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

注：默认redis服务是在前台终端运行。

2.6、把redis调入后台运行

默认情况，Redis不是在后台运行，我们需要把redis放在后台运行

[root@cong11 ~]# vim /usr/local/redis/etc/redis.conf

daemonize yes #修改no为yes

bind 127.0.0.1 192.168.1.11 #默认监控127.0.0.1 添加本机IP 192.168.1.11

[root@cong11 ~]# /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

执行netstat和ps命令查看redis监听和进程信息

2.7、客户端连接redis

[root@cong11 ~]# /usr/local/redis/bin/redis-cli

127.0.0.1:6379>

2.8、停止redis实例

[root@cong11 ~]# /usr/local/redis/bin/redis-cli shutdown

或者：

[root@cong11 ~]# pkill redis-server

2.9、 /usr/local/redis/bin目录下的几个文件是什么

redis-benchmark：redis性能测试工具，测试Redis在你的系统及你的配置下的读写性能

redis-check-aof：检查aof日志的工具

redis-check-rdb：检查rdb日志的工具

redis-cli：连接用的客户端

redis-server：redis服务进程

2.10、添加path环境变量

[root@cong11 ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

2.11、添加开机自启动

[root@cong11 ~]# chmod +x /etc/rc.d/rc.local

[root@cong11 ~]# echo " /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf" >> /etc/rc.d/rc.local

2.12、 redis配置文件详解

#是否作为守护进程运行

daemonize yes

#如以后台进程运行，则需指定一个pid，默认为/var/run/redis.pid

pidfile redis.pid

#绑定主机IP，默认值为127.0.0.1

#bind 127.0.0.1

#为了保护redis服务的安全，redis默认启用了保护模式，当保护模式启用时，redis只允许本地连接，即只能在redis服务器所在的主机上进行连接和操作，这就意味着，如果需要从远程主机上访问redis服务器，就需要关闭保护模式。

#方法一：修改配置文件redis.conf，找到protected-mode 选项，并将其值修改为no，保存后，重新启动redis服务。

#方法二：通过命令行参数关闭，在启动redis服务时指定--protected-mode no参数，例如：/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf --protected-mode no

protected-mode yes

#Redis默认监听端口

port 6379

#客户端闲置多少秒后，断开连接，默认为300（秒）

timeout 300

#日志记录等级，有4个可选值，debug，verbose（默认值），notice，warning

Verbose 这种形式可以比较详细的记录redis中产生的信息

Waring 警告信息

Debug 调试

什么时候用debug？

你redis出现bug后，你可以开启debug debug会清晰的告诉你错误的位置以及你做了哪些错误的操作

loglevel verbose

#指定日志输出的文件名，默认值为stdout，也可设为/dev/null屏蔽日志

logfile stdout

Stdout 标准输出设备

你的日志文件，会默认输出到你的屏幕上

#可用数据库数，默认值为16，默认数据库为0

自带数据库16个第一个数据库从0开始

databases 16

#保存数据到disk的策略

#当至少有一条Key数据被改变时，900秒刷新到disk一次

save 900 1

#当至少有10条Keys数据被改变时，300秒刷新到disk一次

save 300 10

#当至少有1w条keys数据被改变时，60秒刷新到disk一次

save 60 10000

#当dump .rdb数据库的时候是否压缩数据对象

rdbcompression yes

#存储和加载rdb文件时校验

rdbchecksum yes

#本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb

#后台存储错误停止写。

stop-writes-on-bgsave-error yes

他有两种执行方式一个是save 一个是bgsave

当你为bgsave策略时，如果遇到错误，他就不会刷写到磁盘呗

#本地数据库存放路径，默认值为 ./ =/usr/local/redis/

dir /var/lib/redis/ ./data/aaa/ =/usr/local/redis/data/aaa/

########### Replication #####################

#Redis的复制配置

# replicaof <masterip> <masterport> 当本机为从服务时，设置主服务的IP及端口

# masterauth <master-password> 当本机为从服务时，设置主服务的连接密码

#连接密码

# requirepass foobared

#最大客户端连接数，默认不限制

# maxclients 128

#最大内存使用设置，达到最大内存设置后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，一旦到达最大内存设置，将无法再进行写入操作。

# maxmemory <bytes>

#是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认值为no

appendonly no

#更新日志文件名，默认值为appendonly.aof

#appendfilename

#更新日志条件，共有3个可选值。

no表示等操作系统进行数据缓存同步到磁盘，

always表示每次更新操作后调用fsync()将数据写到磁盘，

everysec表示每秒同步一次（默认值）。

# appendfsync always

appendfsync everysec

# appendfsync no

#当slave失去与master的连接，或正在拷贝中，如果为yes，slave会响应客户端的请求，数据可能不同步甚至没有数据，如果为no，slave会返回错误"SYNC with master in progress"

replica -serve-stale-data yes

#如果为yes，slave实例只读，如果为no，slave实例可读可写。

replica -read-only yes

# 在slave和master同步后（发送psync/sync），后续的同步是否设置成TCP_NODELAY . 假如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致假如设置成no，则redis master会立即发送同步数据，没有延迟

repl-disable-tcp-nodelay no

#如果master不能再正常工作，那么会在多个slave中，选择优先值最小的一个slave提升为master，优先值为0表示不能提升为master。

replica-priority 100

#### LIMITS ####

maxclients 10000 #客户端并发连接数的上限是10000，到达上限，服务器会关闭所有新连接并返回错误"max number of clients reached"

maxmemory 15G #设置最大内存，到达上限，服务器会根据驱逐政策(eviction policy)删除某些键值，如果政策被设置为noeviction，那么redis只读，对于增加内存的操作请求返回错误。

#### APPEND ONLY MODE ####

appendonly no #redis默认采用快照(snapshotting)异步转存到硬盘中，它是根据save指令来触发持久化的，当Redis异常中断或停电时，可能会导致最后一些写操作丢失。AOF(Append Only File，只追加文件)可以提供更好的持久性，结合apendfsync指令可以把几分钟的数据丢失降至一秒钟的数据丢失，它通过日志把所有的操作记录下来，AOF和RDB持久化可以同时启动。

appendfilename appendonly.aof #指定aof的文件名。

apendfsync always|everysec|no #调用fsync()写数据到硬盘中，always是每一次写操作就马上同步到日志中，everysec是每隔一秒强制fsync，no是不调用fsync()，让操作系统自己决定何时同步。

no-appendfsync-on-rewrite no #如果为yes，当BGSAVE或BGREWRITEAOF指令运行时，即把AOF文件转写到RDB文件中时，会阻止调用fsync()。

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb #Redis会将AOF文件最初的大小记录下来，如果当前的AOF文件的大小增加100%并且超过64mb时，就会自动触发Redis改写AOF文件到RDB文件中，如果auto-aof-rewrite-percentage为0表示取消自动rewrite功能。重点讲解

#### LUA SCRIPTING ####

lua-time-limit 5000 #一个Lua脚本最长的执行时间为5000毫秒（5秒），如果为0或负数表示无限执行时间。

#### SLOW LOG ####

slowlog-log-slower-than 10000 #当某个请求执行时间（不包括IO时间）超过10000微妙（10毫秒），把请求记录在慢日志中，如果为负数不使用慢日志，如果为0强制记录每个指令。

slowlog-max-len 128 #慢日志的最大长度是128，当慢日志超过128时，最先进入队列的记录会被踢出来，慢日志会消耗内存，你可以使用SLOWLOG RESET清空队列回收这些内存。

#### ADVANCED CONFIG ####

hash-max-ziplist-entries 512

hash-max-ziplist-value 64 #较小的hash可以通过某种特殊的方式进行编码，以节省大量的内存空间，我们指定最大的条目数为512，每个条目的最大长度为64。

list-max-ziplist-entries 512

list-max-ziplist-value 64 #同上。

zset-max-ziplist-entries 128

zset-max-ziplist-value 64 #同上。

activerehashing yes #重新哈希the main Redis hash table(the one mapping top-level keys to values)，这样会节省更多的空间。

client-output-buffer-limit normal 0 0 0 #对客户端输出缓冲进行限制可以强迫那些就不从服务器读取数据的客户端断开连接。对于normal client，第一个0表示取消hard limit，第二个0和第三个0表示取消soft limit，normal client默认取消限制，因为如果没有寻问，他们是不会接收数据的。

client-output-buffer-limit slave 256mb 64mb 60 #对于slave client和MONITER client，如果client-output-buffer一旦超过256mb，又或者超过64mb持续60秒，那么服务器就会立即断开客户端连接。

client-output-buffer-limit pubsub 32mb 8mb 60 #对于pubsub client，如果client-output-buffer一旦超过32mb，又或者超过8mb持续60秒，那么服务器就会立即断开客户端连接。

#### INCLUDES ####

include /path/to/conf #包含一些可以重用的配置文件。

hz 10 #Redis 调用内部函数来执行后台task，比如关闭已经timeout连接，删除过期的keys并且永远不会被访问到的，执行频率根据 hz 后面的值来确定。在Redis 比较空闲的时候，提高这个值，能充分利用CPU，让Redis相应速度更快，可取范围是1-500 ，建议值为 1--100

aof-rewrite-incremental-fsync yes # 当子进程重写AOF文件，以下选项开启时，AOF文件会每产生32M数据同步一次。这有助于更快写入文件到磁盘避免延迟

################ VIRTUAL MEMORY ###########

#是否开启VM功能，默认值为no

vm-enabled no

# vm-enabled yes

#虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

#将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的 (Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0。

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

############# ADVANCED CONFIG ###############

glueoutputbuf yes

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

#是否重置Hash表

activerehashing yes

2.13、 redis数据存储

redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。

save seconds updates:save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。在哪设置的呀？

就是在咱们上面的配置文件上指定的那条策略，你如何知道如何设置？

查看redis的主配置文件，查找save即可

appendonly yes/no :appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。 ##指的就是你redis当中执行的每一条操作是否记录到你这个aof日志文件中，如果为no 将不会保存，如果为yes，将会保存，

这里面也说了他是按照save的策略来执行的，通过这句话你就能知道，它默认用的就是rbd持久化，因为你salve策略就是rbd持久化策略的其中一种

如果redis默认主从同步的话和该选项有无关系？

有关系

和save seconds updates:save选项有无关系

有关系

为什么和他俩都有关系

如果你只采用rbd持久话来进行数据同步，难免造成数据的丢失，

如果你只采用aof日志记录，又会造成日志文件的增大

那么我两个选项都开启，先做rbd快照文件，剩下的内容由aof日志做记录

最大程度上保证数据的不丢失，主从同步的时候，从节点去主节点上拿到主节点的这俩文件，进行同步，最大程度保证数据不丢失

appendfsync no/always/everysec :appendfsync配置，

no表示等操作系统进行数据缓存同步到磁盘，