redis概述，细节可自寻查看相关资料

 一.Redis支持五种数据类型：

string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

 String： 表名 主键名 主键值 字段名

               set user:id:001:fans  12345

               set user:id:001:blogs 12

               set user:id:001 {fans:1234,blogs:12}

 二.应用场景：

  1.热点信息：热点资讯、新闻、商品等高访问量信息  

  2.任务队列：秒杀、抢购

  3.及时信息：排行榜、访问统计、在线人数等

  4.时效信息 验证码、投票等

三.持久化

  1.RDP(数据快照)
      命令：save，bgsave

RDB启动方式 —— save指令相关配置

 dbfilename dump.rdb
说明：设置本地数据库文件名，默认值为 dump.rdb
经验：通常设置为dump-端口号.rdb
 dir
说明：设置存储.rdb文件的路径
经验：通常设置成存储空间较大的目录中，目录名称data
 rdbcompression yes
说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
 rdbchecksum yes
说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

RDB启动方式 ——save配置

 配置
 作用
满足限定时间范围内key的变化数量达到指定数量即进行持久化
 参数
second：监控时间范围
changes：监控key的变化量
 位置
在conf文件中进行配置
 范例
save second changes
save 900 1
save 300 10
save 60 10000

RDB启动方式 —— bgsave指令相关配置

 dbfilename dump.rdb
 dir
 rdbcompression yes
 rdbchecksum yes
 stop-writes-on-bgsave-error yes
说明：后台存储过程中如果出现错误现象，是否停止保存操作
经验：通常默认为开启状态

RDB三种启动方式对比

方式                            save指令  bgsave指令  
读写                                 同步           异步
阻塞客户端指令                是               否
额外内存消耗                    否               是
启动新进程                        否               是

RDB优点：

 RDB是一个紧凑压缩的二进制文件，存储效率较高
 RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
 RDB恢复数据的速度要比AOF快很多
 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

Rdb缺点：

 RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
 bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
 Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF(记录操作日志)

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令
达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
 AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据三种策略(appendfsync)

 always(每次）
每次写入操作均同步到AOF文件中，数据零误差，性能较低
 everysec（每秒）
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
在系统突然宕机的情况下丢失1秒内的数据
 no（系统控制）
由操作系统控制每次同步到AOF文件的周期，整体过程不可控

 

AOF功能开启

 配置
是否开启AOF持久化功能，默认为不开启状态  appendonly yes|no
 配置
AOF写数据策略 appendfsync always|everysec|no

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重
写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结
果转化成最终结果数据对应的指令进行记录。
AOF重写作用
 降低磁盘占用量，提高磁盘利用率
 提高持久化效率，降低持久化写时间，提高IO性能
 降低数据恢复用时，提高数据恢复效率

AOF重写规则

 进程内已超时的数据不再写入文件
 忽略无效指令，重写时使用进程内数据直接生成，这样新的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个元素

AOF重写方式

 手动重写bgrewriteaof
 自动重写 auto-aof-rewrite-min-size size   auto-aof-rewrite-percentage percentage

 

持久化方式                           RDB                                  AOF
占用存储空间            小（数据级：压缩）           大（指令级：重写）
存储速度                                慢                                      快
恢复速度                                快                                       慢
数据安全性                     会丢失数据                         依据策略决定
资源消耗                           高/重量级                           低/轻量级
启动优先级                            低                                        高

RDB与AOF的选择之惑

 对数据非常敏感，建议使用默认的AOF持久化方案
 AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出
现问题时，最多丢失0-1秒内的数据。
 注意：由于AOF文件存储体积较大，且恢复速度较慢
 数据呈现阶段有效性，建议使用RDB持久化方案
 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段
点数据恢复通常采用RDB方案
 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
 综合比对
 RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
 灾难恢复选用RDB
 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

四：事务

事务的基本操作：

 开启事务   multi
 作用
设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
 执行事务   exec
 作用
设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行

 取消事务  discard

 作用
终止当前事务的定义，发生在multi之后，exec之前

五：锁

基于特定条件的事务执行——分布式锁
解决方案
 使用 setnx 设置一个公共锁
 setnx lock-key value
利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
对于返回设置失败的，不具有控制权，排队或等待
 操作完毕通过del操作释放锁
注意：上述解决方案是一种设计概念，依赖规范保障，具有风险性

基于特定条件的事务执行——分布式锁改良
解决方案
 使用 expire 为锁key添加时间限定，到时不释放，放弃锁
由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。
 例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
 锁时间设定推荐：最大耗时*120%+平均网络延迟*110%
 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可

六：删除策略

定时删除

 创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作
 优点：节约内存，到时就删除，快速释放掉不必要的内存占用
 缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
 总结：用处理器性能换取存储空间（拿时间换空间）

惰性删除

 数据到达过期时间，不做处理。等下次访问该数据时
 如果未过期，返回数据
 发现已过期，删除，返回不存在
 优点：节约CPU性能，发现必须删除的时候才删除
 缺点：内存压力很大，出现长期占用内存的数据
 总结：用存储空间换取处理器性能 

定期删除

两种方案都走极端，有没有折中方案？
 Redis启动服务器初始化时，读取配置server.hz的值，默认为10
 每秒钟执行server.hz次serverCron()
 activeExpireCycle()对每个expires[*]逐一进行检测，每次执行250ms/server.hz
 对某个expires[*]检测时，随机挑选W个key检测
 如果key超时，删除key
 如果一轮中删除的key的数量>W*25%，循环该过程
 如果一轮中删除的key的数量≤W*25%，检查下一个expires[*]，0-15循环
 W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行
 如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行

 周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度
 特点1：CPU性能占用设置有峰值，检测频度可自定义设置
 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
 总结：周期性抽查存储空间（随机抽查，重点抽查）

删除策略比对

1. 定时删除      节约内存，无占用       不分时段占用CPU资源，频度高            拿时间换空间
2. 惰性删除      内存占用严重              延时执行，CPU利用率高                        拿空间换时间
3. 定期删除      内存定期随机清理       每秒花费固定的CPU资源维护内存           随机抽查，重点抽查

 

逐出算法

影响数据逐出的相关配置
 最大可使用内存    maxmemory
占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上。
 每次选取待删除数据的个数 maxmemory-samples
选取数据时并不会全库扫描，导致严重的性能消耗，降低读写性能。因此采用随机获取数据的方式作为待检测删除数据
 删除策略   maxmemory-policy
达到最大内存后的，对被挑选出来的数据进行删除的策略

影响数据逐出的相关配置
 检测易失数据（可能会过期的数据集server.db[i].expires ）
① volatile-lru：挑选最近最少使用的数据淘汰（最好配置这个）
② volatile-lfu：挑选最近使用次数最少的数据淘汰
③ volatile-ttl：挑选将要过期的数据淘汰
④ volatile-random：任意选择数据淘汰
 检测全库数据（所有数据集server.db[i].dict ）
⑤ allkeys-lru：挑选最近最少使用的数据淘汰
⑥ allkeys-lfu：挑选最近使用次数最少的数据淘汰
⑦ allkeys-random：任意选择数据淘汰
 放弃数据驱逐
⑧ no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）