AOF
基于RDB的缺点，提出解决方法
1、不写全数据，仅记录部分数据。
2、改记录数据未记录操作过程
3、对所有操作均进行记录，排除丢失数据的风险
AOF概念
-
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令，以达到恢复数据的目的。与RDB相比可以简单描述为改 记录数据为记录数据产生的过程
-
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
AOF写数据过程
AOF写数据的三种策略
-
always（每次）
每次写入操作均同步到AOF中，数据零误差，性能低
-
everysec(每秒)
每秒将缓冲区的指令同步到AOF中，数据的准确性较高，性能较高，
-
no（系统控制）
有操作系统控制，每次同步到AOF文件周期不可控。
AOF配置
--是否开启AOF持久化功能，默认为不开启状态
appendonly yes|no
--指定策略
appendfsync always|everysec|no
--配置存储路径
dir
Copy
持久化后会在data文件夹中出现.aof文件。
AOF重写
aof内部的一些机制。
作用
-
降低磁盘占用量，提高磁盘利用率
-
提高持久化效率，降低持久化写时间，提高IO性能
-
降低数据恢复用时，提高数据恢复效率
规则
-
进程内已超时的数据不再写入文件
-
忽略
无效指令
，重写时使用进程内数据直接生成，这样新的AOF文件
只保留最终数据的写入命令
-
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
-
-
对同一数据的多条写命令合并为一条命令
-
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c
-
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
-
如何使用
--手动重写
bgrewriteaof
--自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
Copy
接上图三。在进行3-3步骤后被替换为重写后的aof
缓冲策略
AOF缓冲区同步文件策略，由参数appendfsync控制
-
write操作会触发延迟写（delayed write）机制，Linux在内核提供页缓冲区用 来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依 赖于系统调度机制，列如：缓冲区页空间写满或达到特定时间周期。同步文件之 前，如果此时系统故障宕机，缓冲区内数据将丢失。
-
fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞知道 写入硬盘完成后返回，保证了数据持久化
RDB和AOF
-
对数据非常
敏感
建议使用默认的
AOF
持久化方案
-
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
-
注意：由于AOF文件存储体积较大，且恢复速度较慢
-
-
数据呈现
阶段有效性
，建议使用RDB持久化方案
-
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
-
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低
-
-
综合比对
-
RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
-
如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
-
如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
-
灾难恢复选用RDB
-
双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据
-
持久化场景
这些场景，视频中大部分都分散在每个数据类型中的应用场景中，用以熟练理解数据类型。视频传送门见顶部。
Redis事务
Redis事务的定义
redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰
事务的操作
--开启事务，执行此命令后，所有的命令都会加入到事务队列中直到事务开启
multi
--执行事务 设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
exec
--取消事务 终止当前事务的定义，在multi之后，exec之前
discard
Copy
事务的工作流程
事务操作的注意事项
-
如果在定义事务的过程中，语法格式输入错误，
本次定义全部失效。
-
指命令格式正确，但是无法正确的执行。例如对list进行incr操作
能够正确运行的命令会执行，运行错误的命令不会被执行
注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。
锁
基于特定条件的事务执行
业务场景补货不重复
天猫双11热卖过程中，对已经售罄的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系 列的操作，牵扯到多个连续操作，如何保障不会重复操作？
业务分析
-
多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
-
在操作之前锁定要操作的数据，一旦发生变化，终止当前操作
解决方案
对key添加监视锁，在执行前key发生变化，终止执行，
即使你监控的是name zs，在事务里添加的是 age 12，当你更改name的值，事务添加age 12也会失效
--监控 key1
watch key1 [key2……]
--取消监控
unwatch
Copy
业务场景不超卖
本次补货已经将库存全部清空，如何避免最后一件商品不被多人同时购买？【超卖问题】
业务分析
-
使用watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据
-
虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？
解决方案
--使用setnx设置公共锁
setnx lock-key value
Copy
利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
-
对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
-
对于返回设置失败的，不具有控制权，排队或等待
-
操作完毕通过del lock-key操作释放锁
业务场景死锁
依赖分布式锁的机制，某个用户操作时对应客户端宕机，且此时已经获取到锁。
业务分析
由于锁操作由用户控制加锁解锁，必定会存在加索后未解锁
解锁操作不能只依赖于用户，
解决方案
--设置锁的时限
expire lock-key second
pexpire lock-key milliseconds
Copy
由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。
-
例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
-
测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
-
锁时间设定推荐：最大耗时120%+平均网络延迟110%
-
如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可
Redis中的删除策略
数据删除策略
-
定时删除
-
惰性删除
-
定期删除
时效性数据的存储结构
在内存占用和cpu占用找一个平衡。
定时删除
创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作
优点：节约内存
缺点：可能cpu压力大，要删除数据时，无论此时cpu的负载多高，均占用
用cpu换内存
惰性删除
数据到达过期时间，不做处理，等下次访问数据时，如果未过期，返回数据，如果已过期，删除返回不存在，
优点：节约cpu，发现必须删除才会删除
缺点：内存压力比较大，出现长期占用内存的数据
拿空间换cpu性能
定期删除
特点1：cpu性能占用设置有峰值，检测频度可以自定义设置
特点2：内存压力不是很大，长期占用内存的冷数据将被清除
逐出算法
当新数据进入redis时，内存不足怎么办。
redis在执行每个命令前，会调用freeMemoryIfNeeded（）检测内存是否充足，如果内存不满足新加入数据的最低要求，redis要临时删除一些数据为当前指令清理存储空间，清理数据的策略称为逐出算法。
注意：逐出数据的过程不是100%能够清理出足够可使用的内存空间，如果不成功则反复执行，反复执行不成功，则报错
--最大可使用内存配置 0不限制，生产环境通常50%以上
maxmemory
--每次选取待删除的个数，随机获取数据的方式
maxmemory-samples
--删除策略 达到最大内存后删除方法
maxmemory-policy
Copy
LRU：最长时间没被使用的数据
LFU：一段时间内使用次数最少的数据
数据逐出策略配置依据
使用INFO命令输出监控信息，查询缓存 hit 和 miss 的次数，根据业务需求调优Redis配置
服务器基础配置
--设置服务器以守护进程的方式运行
daemonize yes|no
--绑定主机地址
bind 127.0.0.1
--设置服务器端口号
port 6379
--设置数据库数量
databases 16
--设置服务器以指定日志记录级别
loglevel debug|verbose|notice|warning
-- 日志记录文件名
logfile 端口号.log
--设置同一时间最大客户端连接数，默认 0无限制。当客户端连接到达上限，Redis会关闭新的连接
maxclients 0
--客户端闲置等待最大时长，达到最大值后关闭连接。如需关闭该功能，设置为 0
timeout 300
--导入并加载指定配置文件信息，用于快速创建redis公共配置较多的redis实例配置文件，便于维护
include /path/server-端口号.conf
Copy
注意：日志级别开发期设置为verbose即可，生产环境中配置为notice，简化日志输出量，降低写日志IO的频度
Redis高级数据类型
这几种类型主要是解决某个业务场景的业务类型。
Bitmaps
其实这个就是string 中二进制位的操作接口。
利用二进制位保存数据，0否，1是，出现这种能够充分利用内存的结构。
--获取指定位上的值
getbit key offset
--设置指定位上的值 value只能是0或者是1
setbit key offset value
Copy
扩展操作
对指定key按位进行交、并、非、操作，并将结构
--对指定key按位进行 and：交 or：并 not：非xor：异或
bitop op destKey key1 [key2...]
--统计指定key中1的数量
bitcount key [start end]
Copy
如果不指定开始结束，就统计全部
HyperLogLog
统计不重复的数据的数量
例：统计独立UV
原始方案：set 存储每个用户id
基数：数据集去重后的元素个数。
HyperLogLog是做基数统计的
--添加数据
pfadd key value
--合并操作
pfmerge destkey sourcekey [sourcekey...]
--统计数据
pfcount key1 key2....
Copy
-
用于进行基数统计，不是集合，不保存数据，只记录数量而不是具体数据
-
核心是基数估算算法，最终数值存在一定误差
-
误差范围：基数估计的结果是一个带有 0.81% 标准错误的近似值
-
耗空间极小，每个hyperloglog key占用了12K的内存用于标记基数
-
pfadd命令不是一次性分配12K内存使用，会随着基数的增加内存逐渐增大
-
Pfmerge命令合并后占用的存储空间为12K，无论合并之前数据量多少
GEO
地图信息操作，点与点数据的关联操作。注意他要计算他，假设两点间是水平的。
--添加坐标点
geoadd key longitude latitude member [longitude latitude member ...]
--获取坐标点
geopos key member [member ...]
--计算坐标点的距离
geodist key member1 member2 [unit]
--根据坐标求范围内数据
georadius key longitude latitude radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]
--根据点求范围内数据
georadiusbymember key member radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]
--计算hash值
geohash key member [member ...]
Copy
Redis集群
互联网三高架构，高并发，高可用，高性能。 $$ 可用性=运行时长/全年时长 $$ 追求99.999%五个九，每年崩溃时长大概在5分钟作用。
单机redis的风险与问题
问题1.机器故障
-
现象：硬盘故障、系统崩溃
-
本质：数据丢失，很可能对业务造成灾难性打击
-
结论：基本上会放弃使用redis.
问题2.容量瓶颈
-
现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
-
本质：穷，硬件条件跟不上
-
结论：放弃使用redis
结论： 为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服 务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续 提供服务，实现Redis的高可用，同时实现数据冗余备份。
主从复制简介
提供数据方:master 主节点
接收数据方:slave 从节点，
需要解决的问题
数据同步。
主从复制即将master中的数据即时、有效的复制到slave中
特征：一个master可以拥有多个slave，一个slave只对应一个master
职责：
-
master:
-
写数据
-
执行写操作时，将出现变化的数据自动同步到slave
-
读数据（可忽略）
-
-
slave:
-
读数据
-
写数据（禁止）
-
主从复制作用
-
读写分离：master写、slave读，提高服务器的读写负载能力
-
负载均衡：基于主从结构，配合读写分离由slave分担master负载，并根据需求的变化，改变slave的数 量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
-
故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复。
-
数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
-
高可用基石：基于主从复制，构建哨兵模式与集群实现redis的高可用。
主从复制工作流程
阶段一：建立连接
建立slave到master的连接，使master能够识别slave，并保存slave端口号
步骤1：设置master的地址和端口，保存master信息
步骤2：建立socket连接
步骤3：发送ping命令（定时器任务）
步骤4：身份验证
步骤5：发送slave端口信息
状态：
salve：保存master的地址与端口
master：保存slave的端口
总体：之间创建了连接的socket
主从连接slave连接到master
--方式一：客户端发送命令
--连接成功后，就可以测试，在主节点添加数据从节点读数据了
slaveof <masterip> <masterport>
Copy
--方式二启动时直接指定
redis-server -slaveof <masterip> <masterport>
Copy
--方式三，修改配置文件
slaveof <masterip> <masterport>
Copy
连接成功后可以在，info，查看当前节点的角色，
--主从断开连接，客户端发送命令，从
slaveof no one
Copy
slave断开连接后，不会删除已有的数据，只是不再接受master发送的数据。
授权访问
--master配置文件设置密码
requirepass <password>
--master客户端发送命令设置密码
config set requirepass <password>
config get requirepass
Copy
主设置密码后从通过以下放式访问，
--slave客户端发送命令设置密码
auth <password>
--slave配置文件设置密码
masterauth <password>
--启动客户端设置密码
redis-cli -a <password>
Copy
阶段二：数据同步阶段工作流程
在slave初次连接master后，复制master中的所有数据到slave
将slave的数据库状态更新成master当前的数据库状态
步骤1：请求同步数据
步骤2：创建RDB同步数据
步骤3：恢复RDB同步数据
步骤4：请求部分同步数据
步骤5：恢复部分同步数据
当前状态：
slave
具有master端全部数据，包含RDB过程接收的数据。
Master
保存slave当前数据同步的位置。
总体：
完成数据克隆。
注意事项
1.如果master 数据量巨大，数据同步策略要避开流量高峰期，避免master阻塞，影响业务执行。
2.复制缓冲区大小设定不合理， 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已 经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。
repl-backlog-size 1mb
Copy
3.master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执 行bgsave命令和创建复制缓冲区
数据同步阶段slave说明
-
避免slave进行全量复制，部分复制时，服务器阻塞或数据不同步，建议关闭此期间的对外服务。
slave-serve-stale-data yes|no
Copy
-
数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送 命令
-
多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果 master带宽不足，因此数据同步需要根据业务需求，适量错峰
-
slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟 较大，数据一致性变差，应谨慎选择
阶段三：命令传播阶段
当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的 状态，同步的动作称为命令传播
master将接收到的数据变更命令发送给slave，slave接收命令后执行命令
该阶段可能出现的问题
命令传播阶段出现了断网现象
网络闪断闪连 忽略
短时间网络中断 部分复制
长时间网络中断 全量复制
部分复制的核心要素
-
服务器的运行id
-
主服务器的复制积压缓冲区
-
主从服务器的复制偏移量
服务器运行id
概念：服务器运行id是其身份的标识码。多次运行生产多个运行id
组成：40位16进制的随机字符
作用：用来服务器进行传输，识别服务器
实现方式：id在服务器启动自动生成，master在首次连接slave时，会将自己的运行ID发送给slave，slave保存ID，通过info server命令 查看节点的runid
复制缓冲区
概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命 令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
复制缓冲区的内部工作原理
通过offerset偏移量，区分不同的slave当前数据传播的差异
这个offerset，偏移量，
master记录已发数据的偏移量
slave记录已接受信息的偏移量。
复制缓冲区默认数据存储空间大小是1M，由于存储空间大小是固定的，当入队元素的数量大于队 列长度时，最先入队的元素会被弹出，而新元素会被放入队列
由来：每台服务器启动时，如果开启AOF或被连接成为master节点，创建复制缓冲区
作用：保存master收到的所有指令（影响数据变更的指令）
数据来源：当master接受到主客户端指令时，将指令执行，并将指令存储到缓冲区中
复制偏移量
概念：一个数字，描述复制缓冲区中的指令字节位置
-
master端：发送一次记录一次
-
slave端：接收一次记录一次
同步信息，比对master与slave的差异，当slave断线后，恢复数据使用
数据同步+整体流程总结
心跳机制
进入命令传播阶段，master与slave间要进行信息交换，使用心跳机制进行维护，实现双方保持在线，
master心跳：
-
指令：PING
-
周期：由repl-ping-slave-period决定，默认10秒
-
作用：判断slave是否在线
-
查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
slave心跳任务：
-
指令：REPLCONF ACK {offset}
-
周期：1秒
-
作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
-
作用2：判断master是否在线
注意事项
当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作。
min-slaves-to-write 2
min-slaves-max-lag 8
Copy
slave数量少于2个，或者所有slave的延迟都大于等于10秒时，强制关闭master写功能，停止数据同步
slave数量由slave发送REPLCONF ACK命令做确认
slave延迟由slave发送REPLCONF ACK命令做确认
主从复制工作流程整体
主从复制常见问题
频繁的全量复制，master重启引发
伴随系统的运行，master的数据量会越来越大，一旦master重启，runid将会发生变化，会导致全部的slave的全量复制
内部优化调整方案：
master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave
在master关闭时执行命令 shutdown save，进行RDB持久化,将runid与offset保存到RDB文件中
-
repl-id repl-offset
-
通过redis-check-rdb命令可以查看该信息
master重启后加载RDB文件，恢复数据 重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中
-
master_repl_id = repl master_repl_offset = repl-offset
-
通过info命令可以查看该信息
作用： 本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master
频繁的全量复制，网络中断引发
问题现象
-
网络环境不佳，出现网络中断，slave不提供服务
问题原因
-
复制缓冲区过小，断网后slave的offset偏移量越界，触发全量复制
结果
-
slave反复进行全量复制
解决方案
--修改复制缓冲区大小
repl-backlog-size
Copy
建议设置如下’
-
测算从master到slave的重连平均时长second /测算回信息的时长
-
获取master平均每秒产生写命令数据总量write_size_per_second
-
最优复制缓冲区空间 = 2 * second * write_size_per_secon
频繁的网络中断1
问题现象
-
master的cpu占用过高，或slave频繁断开连接
问题原因
-
slave每1秒发送REPLCONF ACK命令到master
-
当slave接到了慢查询时（keys * ，hgetall等），会大量占用CPU性能
-
master每1秒调用复制定时函数replicationCron()，比对slave发现长时间没有进行响应
结果
-
master各种资源（输出缓冲区、带宽、连接等）被严重占用
解决方案
-
通过设置合理的超时时间，确认是否释放slave
repl-timeout
Copy
频繁的网络中断2
问题现象
-
slave与master连接断开
问题原因
-
master发送ping指令频度较低
-
master设定超时时间较短
-
ping指令在网络中存在丢包
解决方案
-
提高ping指令发送的频度
repl-ping-slave-period
Copy
建议
超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时
数据不一致
问题现象
-
多个slave获取相同数据不同步
问题原因
-
网络信息不同步，数据发送有延迟
解决方案
-
优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象
-
监控主从节点延迟（通过offset）判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问
slave-serve-stale-data yes|no
Copy
开启后仅响应info、slaveof等少数命令（慎用，除非对数据一致性要求很高）主要调试用。
