马哥门徒N57-SRE第三周

2023-10-01 23:22:16

redis服务配置文件详解

Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no
当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

pidfile /var/run/redis.pid
指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字

port 6379
绑定的主机地址

bind 127.0.0.1
当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 300
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose

loglevel verbose
日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null

logfile stdout
设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

databases 16
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

save

Redis默认配置文件中提供了三个条件：

save 900 1

save 300 10

save 60 10000

分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes
指定本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb
指定本地数据库存放目录

dir ./
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

slaveof
当master服务设置了密码保护时，slav服务连接master的密码

masterauth
设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭

requirepass foobared
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

maxclients 128
指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

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

appendonly no
指定更新日志文件名，默认为appendonly.aof

appendfilename appendonly.aof
指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）

appendfsync everysec
指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）

vm-enabled no
虚拟内存文件路径，默认值为/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
Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值

vm-page-size 32
设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。

vm-pages 134217728
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

vm-max-threads 4
设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启

glueoutputbuf yes
指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

hash-max-zipmap-entries 64

hash-max-zipmap-value 512
指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）

activerehashing yes
指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

include /path/to/local.conf
##################################
##################################

RDB、AOF详解及优缺点总结

Redis是一种高级key-value数据库。数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。

Redis为了保证效率，数据缓存在内存中，Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，以保证数据的持久化。

Redis是一个支持持久化的内存数据库，可以将内存中的数据同步到磁盘保证持久化。

Redis的持久化策略：2种
RDB：快照形式是直接把内存中的数据保存到一个 dump 文件中，定时保存，保存策略。
AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。

Redis默认是快照RDB的持久化方式

当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

RDB 持久化
默认 Redis 是会以快照 “RDB” 的形式将数据持久化到磁盘的，一个二进制文件，dump.rdb

工作原理简单介绍一下：当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处就是可以 copy-on-write。

Redis默认情况下，是快照 RDB 的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是 dump.rdb 。当然我们也可以手动执行 save 或者 bgsave（异步）做快照。

Redis.conf配置 ：默认是如下配置

save 900 1
save 300 10
save 60 10000
900秒之内，如果超过1个key被修改，则发起快照保存；
300秒内，如果超过10个key被修改，则发起快照保存；
1分钟之内，如果1万个key被修改，则发起快照保存；

RDB 的优点:

这种文件非常适合用于进行备份：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适用于灾难恢复（disaster recovery）。
RDB 的缺点:

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率，但是，因为RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少 5 分钟才保存一次 RDB 文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
AOF 持久化

使用 AOF 做持久化，每一个写命令都通过write函数追加到 appendonly.aof 中,配置方式：启动 AOF 持久化的方式

Redis.conf配置

appendfsync yes
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

AOF 就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启 AOF 之后，Redis 每执行一个修改数据的命令，都会把它添加到 AOF 文件中，当 Redis 重启时，将会读取 AOF 文件进行“重放”以恢复到 Redis 关闭前的最后时刻。

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

AOF 的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

二者的区别

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB 和 AOF ,我应该用哪一个？
如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久。
AOF 将 Redis 执行的每一条命令追加到磁盘中，处理巨大的写入会降低 Redis 的性能，不知道你是否可以接受。

**数据库备份和灾难恢复：**定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

Redis 支持同时开启 RDB 和 AOF,系统重启后，Redis 会优先使用 AOF 来恢复数据，这样丢失的数据会最少。

#####################################
#####################################

Redis Cluster扩、缩容

（网上搜索内容）

1. Redis Cluster集群扩容
1.1 扩容原理
redis cluster可以实现对节点的灵活上下线控制
3个主节点分别维护自己负责的槽和对应的数据，如果希望加入一个节点实现扩容，就需要把一部分槽和数据迁移和新节点

每个master把一部分槽和数据迁移到新的节点node04

1.2 扩容过程
准备新节点

准备两个配置文件redis_6379.conf和redis_6380.conf

创建目录

新节点启动redis服务
新节点加入集群

在原有集群任意节点内执行以下命令

集群内新旧节点经过一段时间的通信之后，所有节点会更新它们的状态并保存到本地

新节点刚开始都是master节点，但是由于没有负责的槽，所以不能接收任何读写操作，对新节点的后续操作，一般有两种选择：
从其他的节点迁移槽和数据给新节点
作为其他节点的slave负责故障转移

redis-trib.rb工具也实现了为现有集群添加新节点的命令，同时也实现了直接添加为slave的支持：

建议使用redis-trib.rb add-node将新节点添加到集群中，该命令会检查新节点的状态，如果新节点已经加入了其他集群或者已经包含数据，则会报错，而使用cluster meet命令则不会做这样的检查，假如新节点已经存在数据，则会合并到集群中，造成数据不一致。

迁移slot和数据
slot迁移是集群伸缩的最核心步骤
假设原有3个master，每个master负责10384 / 3 ≈ 5461个slot
加入一个新的master之后，每个master负责10384 / 4 = 4096个slot
确定好迁移计划之后，例如，每个master将超过4096个slot的部分迁移到新的master中，然后开始以slot为单位进行迁移
每个slot的迁移过程如下所示：

对目标节点发送cluster setslot {slot_id} importing {sourceNodeId}命令，目标节点的状态被标记为"importing"，准备导入这个slot的数据对源节点发送cluster setslot {slot_id} migrating {targetNodeID}命令，源节点的状态被标记为"migrating"，准备迁出slot的数据源节点执行cluster getkeysinslot {slot_id} {count}命令，获取这个slot的所有的key列表(分批获取，count指定一次获取的个数)，然后针对每个key进行迁移在源节点执行migrate {targetIp} {targetPort} “” 0 {timeout} keys {keys}命令，把一批批key迁移到目标节点(redis-3.0.6之前一次只能迁移一个key)，具体来说，源节点对迁移的key执行dump指令得到序列化内容，然后通过客户端向目标节点发送携带着序列化内容的restore指令，目标节点进行反序列化后将接收到的内容存入自己的内存中，目标节点给客户端返回"OK"，然后源节点删除这个key，这样，一个key的迁移过程就结束了
所有的key都迁移完成后，一个slot的迁移就结束了
迁移所有的slot(应该被迁移的那些)，所有的slot迁移完成后，新的集群的slot就重新分配完成了，向集群内所有master发送cluster setslot {slot_id} node {targetNodeId}命令，通知他们哪些槽被迁移到了哪些master上，让它们更新自己的信息

slot迁移的其他说明
迁移过程是同步的，在目标节点执行restore指令到原节点删除key之间，原节点的主线程处于阻塞状态，直到key被删除成功
如果迁移过程突然出现网路故障，整个slot迁移只进行了一半，这时两个节点仍然会被标记为中间过滤状态，即"migrating"和"importing"，下次迁移工具连接上之后，会继续进行迁移
在迁移过程中，如果每个key的内容都很小，那么迁移过程很快，不会影响到客户端的正常访问
如果key的内容很大，由于迁移一个key的迁移过程是阻塞的，就会同时导致原节点和目标节点的卡顿，影响集群的稳定性，所以，集群环境下，业务逻辑要尽可能的避免大key的产生

手动完成slot迁移的过程

使用redis-trib.rb工具完成slot迁移

检查slot的负载均衡

2. Redis Cluster集群缩容
2.1 缩容原理
如果下线的是slave，那么通知其他节点忘记下线的节点
如果下线的是master，那么将此master的slot迁移到其他master之后，通知其他节点忘记此master节点
其他节点都忘记了下线的节点之后，此节点就可以正常停止服务了

2.2 缩容过程

我们在上面添加了10.0.0.103:6379和10.0.0.103:6380两个节点，现在把这两个节点下线
确认下线节点的角色

下线master节点的slot迁移到其他maste

忘记节点

Redis提供了cluster forget{downNodeId}命令来通知其他节点忘记下线节点，当节点接收到cluster forget {down NodeId}命令后，会把nodeId指定的节点加入到禁用列表中，在禁用列表内的节点不再与其他节点发送消息，禁用列表有效期是60秒，超过60秒节点会再次参与消息交换。也就是说当第一次forget命令发出后，我们有60秒的时间让集群内的所有节点忘记下线节点

线上操作不建议直接使用cluster forget命令下线节点，这需要跟大量节点进行命令交互，建议使用redis- trib.rb del-node {host:port} {downNodeId}命令

另外，先下线slave，再下线master可以防止不必要的数据复制

redis-trib.rb del-node还可以自动停止下线节点的服务。

###########################################
###########################################

LVS调试算法总结

VS/NAT
流程：

客户通过VIP访问网络服务时，请求报文到达调度器，
调度器根据连接调度算法从一组真实服务器中选出一台服务器
将报文的目标地址VIP改写成选定的真实服务器RIP的地址，报文的目标端口改写成选定服务器的相应端口，
将修改后的报文发送给选出的服务器。到真实服务器RS；同时，调度器在连接Hash表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。
当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址RIP和源端口改为VIP和相应的端口，
再把报文发给用户

VS/DR
流程：

客户通过VIP访问网络服务时，请求报文到达调度器
调度器根据连接调度算法从一组真实服务器中选出一台服务器
调度器不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。
因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文
当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文
然后根据路由表将响应报文直接返回给客户
注意：VS/DR的体系结构，调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连，如通过高速的交换机或者HUB相连。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

VS/TUN

调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

流程：

客户通过VIP访问网络服务时，请求报文到达调度器
调度器根据各个服务器的负载情况，动态地选择一台服务器
将请求报文封装在另一个IP报文中添加源地址DIP与目标地址RIP，
再将封装后的IP报文通过路由器转发给选出的服务器
服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求
然后根据路由表将响应报文直接返回给客户

LVS调试算法
ipvs scheduler：根据其调度时是否考虑各RS当前的负载状态

分为两种：静态方法和动态方法
静态方法

仅根据算法本身进行调度

1、RR：roundrobin，轮询

2、WRR：Weighted RR，加权轮询

3、SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定

4、DH：Destination Hashing；目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡，如：宽带运营商
动态方法

主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度

1、LC：least connections 适用于长连接应用

Overhead=activeconns*256+inactiveconns

2、WLC：Weighted LC，默认调度方法

Overhead=(activeconns*256+inactiveconns)/weight

3、SED：Shortest Expection Delay，初始连接高权重优先

Overhead=(activeconns+1)*256/weight

4、NQ：Never Queue，第一轮均匀分配，后续SED

5、LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理

6、LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS
内核版本 4.15 版本后新增调度算法：FO和OVF

FO（Weighted Fail Over）调度算法,在此FO算法中，遍历虚拟服务所关联的真实服务器链表，找到还未过载（未设置IP_VS_DEST_F_OVERLOAD标志）的且权重最高的真实服务器，进行调度

OVF（Overflow-connection）调度算法，基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值最高的真实服务器，直到其活动连接数量超过权重值，之后调度到下一个权重值最高的真实服务器,在此OVF算法中，遍历虚拟服务相关联的真实服务器链表，找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件：

-未过载（未设置IP_VS_DEST_F_OVERLOAD标志）
-真实服务器当前的活动连接数量小于其权重值

-其权重值不为零

###################################################
###################################################