redis配置详解(redis安装配置)

1.软文推荐

2.软文推荐

3.软文推荐

目录： 1、Redis配置文件参数说明 2、Redis-cli详解 3、Redis详解——概述/下载安装 4、Redis使用——Redis的redis.conf配置注释详解（三） 5、Redis 配置参数详解 6、010.Redis 主从架构搭建及原理详解 Redis配置文件参数说明

为安全起见，最好指定内网固定的网卡适配器作为绑定对象。

tcp_max_syn_backlog控制处于半连接SYN_RECV状态的连接数量。

somaxconn控制处于全连接ESTABLISHED状态的连接数量

有关这两个参数可以参考这篇 文章 ，写的比较详细。

我们在使用的时候要知道，tcp-backlog和somaxconn这两者的最小值会起作用。我们把somaxconn调整为1024，然后看看实际效果。

tcp-backlog起作用了。

是否配置upstart或者systemd来管理Redis服务器

如果我们需要使用systemd来管理和使用Redis服务器，我们就将设置该参数为supervised systemd

然后，我们添加redis.service 到/etc/systemd/system下。编辑内容如下几可以了。

就可以实现systemd对 redis的管理。

这个backlog感觉更像是一个cache，复制节点断网后，在连接重新建立后，将这个backlog中的数据复制过去。也称为部分同步。

条件允许，可以定义大一些。没有坏处。

既然类似于cache，就有生存期

在使用NAT时候是，master和复制节点连接信息中的ip和port可能是经过NAT后的信息，我们这里使用该参数将真正的IP和PORT信息汇报给主节点

可以将一些重要系统命令，重新命名为不容易猜测的名字。

命令重命名后再同步到别的节点，可能会引起一些问题。

Redis默认删除时是处于一种阻塞状态，自从有了异步删除方式。我们现在可以配置不同情况下的删除方式

lazyfree-lazy-eviction:达到最大内存时

lazyfree-lazy-expire：过期时

lazyfree-lazy-server-del ：内部删除时

replica-lazy-flush no：复制节点执行全部同步时

同步刷新可能会带来阻塞的现象，没有其他任何办法。

通过启用本选项，在BGSAVE和BGREWRITEAOF过程中能禁止fsync的调用。

-配置AOFRewrite策略

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

这个配置表明aof增长了百分百，而且增长的大小超过了64mb，就启动bgrewriteaof。

-是否支持rdb和aof的混合持久化

启用rdb和aof的混合持久化后，aof文件跟在rdb后面，既能利用上rdb快速读取的优点，有能利用aof的安全持久能力。

如果在同一个系统中，这个配置文件不要重名Redis-cli详解

-r（repeat）选项代表将命令执行多次，例如下面操作将会执行三次ping

命令：

redis-cli -r 3 ping 

PONG

PONG 

PONG

-i（interval）选项代表每隔几秒执行一次命令，但是-i选项必须和-r选 项一起使用，下面的操作会每隔1秒执行一次ping命令，一共执行5次：

注意-i的单位是秒，不支持毫秒为单位，但是如果想以每隔10毫秒执行 一次，可以用-i0.01

redis-cli -r 5 -i 0.01 ping

例如下面的操作利用-r和-i选项，每隔1秒输出内存的使用量，一共输出 100次

redis-cli -r 100 -i 1 info | grep used_memory_human 

used_memory_human:2.95G 

used_memory_human:2.95G

-x选项代表从标准输入（stdin）读取数据作为redis-cli的最后一个参 数，例如下面的操作会将字符串world作为set hello的值

$ echo "world" | redis-cli -x set hello 

OK

-c（cluster）选项是连接Redis Cluster节点时需要使用的，-c选项可以防 止moved和ask异常

如果Redis配置了密码，可以用-a（auth）选项，有了这个选项就不需要 手动输入auth命令

--scan选项和--pattern选项用于扫描指定模式的键，相当于使用scan命令

--slave选项是把当前客户端模拟成当前Redis节点的从节点，可以用来 获取当前Redis节点的更新操作

下面开启第一个客户端，使用--slave选项，看到同步已完成：

$ redis-cli --slave 

SYNC with master, discarding 72 bytes of bulk transfer... 

SYNC done. Logging commands from master.

--rdb选项会请求Redis实例生成并发送RDB持久化文件，保存在本地。 可使用它做持久化文件的定期备份

--pipe选项用于将命令封装成Redis通信协议定义的数据格式，批量发送 给Redis执行

例如下面操作 同时执行了set hello world和incr counter两条命令：

echo -en '*3 $3 SET $5 hello $5 world *2 $4 incr n$7 counter ' | redis-cli --pipe

--bigkeys选项使用scan命令对Redis的键进行采样，从中找到内存占用比

较大的键值，这些键可能是系统的瓶颈

--eval选项用于执行指定Lua脚本，有关Lua脚本的使用将在3.4节介绍。

latency有三个选项，分别是--latency、--latency-history、--latency-dist。 它们都可以检测网络延迟，对于Redis的开发和运维非常有帮助。

该选项可以测试客户端到目标Redis的网络延迟，例如当前拓扑结构如 图3-4所示。客户端B和Redis在机房B，客户端A在机房A，机房A和机房B是

跨地区的

客户端B：

redis-cli -h {machineB} --latency 

min: 0, max: 1, avg: 0.07 (4211 samples)

客户端A：

redis-cli -h {machineB} --latency 

min: 0, max: 2, avg: 1.04 (2096 samples)

可以看到客户端A由于距离Redis比较远，平均网络延迟会稍微高一些

--latency的执行结果只有一条，如果想以分时段的形式了解延迟信息， 可以使用--latency-history选项：

redis-cli -h 10.10.xx.xx --latency-history 

min: 0, max: 1, avg: 0.28 (1330 samples) -- 15.01 seconds range… 

min: 0, max: 1, avg: 0.05 (1364 samples) -- 15.01 seconds range

可以看到延时信息每15秒输出一次，可以通过-i参数控制间隔时间。

（3）--latency-dist

该选项会使用统计图表的形式从控制台输出延迟统计信息。

--stat选项可以实时获取Redis的重要统计信息，虽然info命令中的统计信 息更全，但是能实时看到一些增量的数据（例如requests）对于Redis的运维还是有一定帮助的

--no-raw选项是要求命令的返回结果必须是原始的格式，--raw恰恰相反，返回格式化后的结果。

在Redis中设置一个中文的value：

$redis-cli set hello "你好" 

OK

如果正常执行get或者使用--no-raw选项，那么返回的结果是二进制格式：

如果使用了--raw选项，将会返回中文：

$redis-cli --raw get hello

你好

Redis详解——概述/下载安装

互联网需求的3高： 高并发，高可扩，高性能。

Redis 是一种运行速度很快，并发性能很强，并且运行在内存上的NoSql（not only sql）数据库

NoSQL数据库 和 传统数据库 相比的优势：

NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。

而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段 简直就是一个噩梦。

Redis的常用使用场景：

缓存 ，毫无疑问这是Redis当今最为人熟知的使用场景。在提升服务器性能方面非常有效；一 些频繁被访问的数据，经常被访问的数据如果放在关系型数据库，每次查询的开销都会很 大，而放在redis中，因为redis 是放在内存中的可以很高效的访问

排行榜 ，在使用传统的关系型数据库（mysql oracle 等）来做这个事儿，非常的麻烦，而利 用Redis的SortSet(有序集合)数据结构能够简单的搞定；

好友关系 ，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好 友、共同爱好之类的功能；

Session共享 ，以jsp为例，默认Session是保存在服务器的文件中，如果是集群服务，同一个 用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论 用户落在那台机器上都能够获取到对应的Session信息。

下载： redis： 图形工具：

安装（Linux）

上传tar.gz包，并解压：tar -zxvf redis-5.0.4.tar.gz

安装gcc：yum -y install gcc （忘记是否安装过，可以使用 gcc -v 命令查看gcc版本，如果没有安装过，会提示命令不存在）

进入redis目录，进行编译：make

编译之后，开始安装：make install

后台运行方式—— redis默认不会使用后台运行，如果你需要，修改配置文件daemonize=yes，当你后台服务启动的 时候，会写成一个进程文件运行

vim /opt/redis-5.0.4/redis.conf

以配置文件的方式启动:

cd /usr/local/bin

redis-server /opt/redis-5.0.4/redis.conf

关闭数据库:

单实例关闭 ——redis-cli shutdown

多实例关闭 ——dis-cli -p 6379 shutdown 默认的端口6379，如改过，更换端口

Redis使用——Redis的redis.conf配置注释详解（三）

日常我们开发时，我们会遇到各种各样的奇奇怪怪的问题（踩坑o(╯□╰)o），这个常见问题系列就是我日常遇到的一些问题的记录文章系列，这里整理汇总后分享给大家，让其还在深坑中的小伙伴有绳索能爬出来。

同时在这里也欢迎大家把自己遇到的问题留言或私信给我，我看看其能否给大家解决。

本节对于其Redis的redis.conf配置进行注释翻译，确定各个配置的主要用途，便于日后配置使用，由于redis.conf中的配置较多，因此我们拆分为四节进行，话不多说下面开始。

更多内容详见 Redis使用——Redis的redis.conf配置注释详解（四）

Redis 配置参数详解

client-output-buffer-limit normal

client-output-buffer-limit slave

client-output-buffer-limit pubsub

bind

port

daemonize

-是否以后台守护的方式运行。

loglevel

logfile

timeout

maxclients

maxmemory

maxmemory-policy

slowlog-log-slower-than

slowlog-max-len

tcp-backlog

tcp-keepalive

requirepass

masterauth

rename-command CONFIG ""

dir

dbfilename

save

stop-writes-on-bgsave-error

rdbcompression

rdbchecksum

appendonly

appendfilename

appendfsync

aof-use-rdb-preamble

auto-aof-rewrite-percentage

auto-aof-rewrite-min-size

aof-load-truncated

no-appendfsync-on-rewrite

slave-serve-stale-data

slave-read-only

repl-diskless-sync

repl-diskless-sync-delay

repl-disable-tcp-nodelay

repl-backlog-size

repl-backlog-ttl

slave-prority

min-slaves-to-write N

min-slaves-max-lag M

cluster-enabled

cluster-config-file

cluster-node-timeout

cluster-replica-validity-factor 5

cluster-migration-barrier 1

cluster-require-full-coverage

cluster-replica-no-failover no

010.Redis 主从架构搭建及原理详解

在redis主从架构中，Master节点负责处理写请求，Slave节点只处理读请求。对于写请求少，读请求多的场景，例如电商详情页，通过这种读写分离的操作可以大幅提高并发量，通过增加redis从节点的数量可以使得redis的QPS达到10W+。

Master节点接收到写请求并处理后，需要告知Slave节点数据发生了改变，保持主从节点数据一致的行为称为主从同步，所有的Slave都和Master通信去同步数据也会加大Master节点的负担，实际上，除了主从同步，redis也可以从从同步，我们在这里统一描述为主从同步。

redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了 (偏移量，这是redis-2.8之后才有的特性)。从节点同步数据的时候不会影响主节点的正常工作，也不会影响自己对外提供读服务的功能，从节点会用旧的数据来提供服务，当同步完成后，需要删除旧数据集，加载新数据，这个时候才会暂停对外服务。

因为内存的 buffer 是有限的，所以 redis 主节点不能将所有的指令都记录在内存 buffer 中。redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满

了，就会从头开始覆盖前面的内容。

如果节点间网络通信不好，那么当从节点同步的速度不如主节点接收新写请求的速度时，buffer 中会丢失一部分指令，从节点中的数据将与主节点中的数据不一致，此时将会触发快照同步。

快照同步是一个非常耗费资源的操作，它首先需要在主节点上进行一次 bgsave 将当前内存的数据全部快照到RDB文件中，然后再将快照文件的内容全部传送到从节点。从节点将RDB文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以需要配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。

主节点在进行快照同步时，会进行大量的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照复制，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是主节点会一边遍历内存，一遍将序列化的内容发送到从节点，而不是生成完整的 RDB 文件后才进行 IO 传输从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

(1) 在从节点的配置文件中的 slaveof 配置项中配置了主节点的IP和port后，从节点就知道自己要和那个主节点进行连接了。

(2) 从节点内部有个定时任务，会每秒检查自己要连接的主节点是否上线，如果发现了主节点上线，就跟主节点进行网络连接。注意，此时仅仅是取得连接，还没有进行主从数据同步。

(3) 从节点发送ping命令给主节点进行连接，如果设置了口令认证（主节点设置了requirepass），那么从节点必须发送正确的口令（masterauth）进行认证。

(4) 主从节点连接成功后，主从节点进行一次快照同步。事实上，是否进行快照同步需要判断主节点的 run id ，当从节点发现已经连接过某个 run id 的主节点，那么视此次连接为重新连接，就不会进行快照同步。相同IP和port的主节点每次重启服务都会生成一个新的 run id ，所以每次主节点重启服务都会进行一次快照同步，如果想重启主节点服务而不改变 run id ，使用 redis-cli debug reload 命令。

(5) 当开始进行快照同步后，主节点在本地生成一份rdb快照文件，并将这个rdb文件发送给从节点，如果复制时间超过60秒（配置项：repl-timeout），那么就会认为复制失败，如果数据量比较大，要适当调大这个参数的值。主从节点进行快照同步的时候，主节点会把接收到的新请求命令写在缓存 buffer 中，当快照同步完成后，再把 buffer 中的指令增量同步到从节点。如果在快照同步期间，内存缓冲区大小超过256MB，或者超过64MB的状态持续时间超过60s（配置项： client-output-buffer-limit slave 256MB 64MB 60 ），那么也会认为快照同步失败。

(6) 从节点接收到RDB文件之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，在这个过程中基于旧的数据对外提供服务。如果主节点开启了AOF，那么在快照同步结束后会立即执行BGREWRITEAOF，重写AOF文件。

(7) 主节点维护了一个backlog文件，默认是1MB大小，主节点向从节点发送全量数据（RDB文件）时，也会同步往backlog中写，这样当发送全量数据这个过程意外中断后，从backlog文件中可以得知数据有哪些是发送成功了，哪些还没有发送，然后当主从节点再次连接后，从失败的地方开始增量同步。这里需要注意的是，当快照同步连接中断后，主从节点再次连接并非是第一次连接，所以进行增量同步，而不是继续进行快照同步。

(8) 快照同步完成后，主节点后续接收到写请求导致数据变化后，将和从节点进行增量同步，遇到 buffer 溢出则再触发快照同步。

(9) 主从节点都会维护一个offset，随着主节点的数据变化以及主从同步的进行，主从节点会不断累加自己维护的offset，从节点每秒都会上报自己的offset给主节点，主节点也会保存每个从节点的offset，这样主从节点就能知道互相之间的数据一致性情况。从节点发送 psync runid offset 命令给主节点从而开始主从同步，主节点会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制。

(10) 主从节点因为网络原因导致断开，当网络接通后，不需要手工干预，可以自动重新连接。

(11) 主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

(12) 从节点不会处理过期key，当主节点处理了一个过期key，会模拟一条del命令发送给从节点。

(13) 主从节点会保持心跳来检测对方是否在线，主节点默认每隔10秒发送一次heartbeat，从节点默认每隔1秒发送一个heartbeat。

(14) 建议在主节点使用AOF+RDB的持久化方式，并且在主节点定期备份RDB文件，而从节点不要开启AOF机制，原因有两个，一是从节点AOF会降低性能，二是如果主节点数据丢失，主节点数据同步给从节点后，从节点收到了空的数据，如果开启了AOF，会生成空的AOF文件，基于AOF恢复数据后，全部数据就都丢失了，而如果不开启AOF机制，从节点启动后，基于自身的RDB文件恢复数据，这样不至于丢失全部数据。RDB和AOF机制可以参考 详解 redis-4.x 持久化机制

使用3个虚拟机搭建一主二从的redis主从架构集群。首先参考 redis-4.0.12单节点安装 在每台机器上安装redis，然后修改redis配置文件，其中一个master节点的配置如下（未列出的保持默认即可）：

两个slave节点的配置如下：

启动3个redis服务：

查看master日志：

看日志发现一个问题，我们在原理中介绍说：

主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

然而这里master的日志显示写了两次RDB文件，这里我查一些资料再来更新。（！！！待完善）

查看slave日志（这里只列出一个slave的日志）：

测试主从架构：

(1) 使用 redis-cli 访问3个redis服务

(2) 在 master 节点上 set 一个数据

(3) 从节点上获取数据

(4) 尝试在slave上写入数据

redis主从架构搭建成功！

wait 提供两个参数，第一个参数是从节点的数量 m，第二个参数是时间 t，以毫秒

为单位。它表示等待 wait 指令之前的所有写操作同步到 n 个子节点 (也就是确保

m 个子节点的同步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到

N 个从库同步完成达成一致。

假设此时某个子节点与主节点网络断开，wait 指令第二个参数时间 t = 0，主从同步无法继续

进行，wait 指令会永远阻塞，redis 服务器将丧失可用性。