Redis
在linux下安装
下载安装
wget http://download.redis.io/releases/redis-??.tar.gz
解压
tar -xvf 文件名.tar.gz
编译
make
安装
make install
持久化
1、持久化介绍
持久化过程保存什么，
数据（快照）直接的数据 RDB ，操作过程（日志）AOF
2、RDB
RDB启动命令-save指令
命令
save
作用
手动执行一次保存操作
单线程任务执行序列
注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
RDB启动方式-bgsave指令，
手动启动后台操作，但不是立即执行的
注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。
bgsave指令工作的原理
RDB启动方式 ——save配置, 自动执行的使用的是配置文件里加上一个保存指令
配置
save second changes
作用
满足限定时间范围内key的变化数量达到指定数量即进行持久化
参数
second：监控时间范围
changes：监控key的变化量
位置
在conf文件中进行配置
例如
save 900 1
save 300 10
save 60 10000
注意：
save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系，second小changes大，或者second大 changes小
save配置启动后执行的是bgsave操作
RDB三种启动方式对比
RDB特殊的启动形式
全量复制，在主从复制中详细讲解
服务器运行过程中重启
debug reload
关闭服务器时指定保存数据
shutdown save
RDB的优点
1）、RDB是一个紧凑压缩的二进制文件，存储效率较高
2）、RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
3）、RDB恢复数据的速度要比AOF快很多
4）、应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
RDB的缺点
1）、RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
2）、bgsave指令每次运行要执行fork操作创建子进程，内存产生额外消耗
3）、Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象
3、AOF
1）存储数据量较大，效率较低 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
2）大数据量下的IO性能较低
3）基于fork创建子进程，内存产生额外消耗
4）宕机带来的数据丢失风险
解决思路，
不写全数据，仅记录部分数据
改记录数据为记录操作过程
对所有操作均进行记录 ，排除丢失数据的风险
AOF概念
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
AOF写数据过程
AOF写数据三种策略
always（每次）
每次写入操作均同步到AOF文件中，数据零误差，性能较低
everysec（每秒）
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
在系统突然宕机的情况下丢失1秒内的数据
no（系统控制）
由操作系统控制每次同步到AOF文件的周期，整体过程不可控
AOF功能开启，在配置文件里添加这两个配置 就是代表开启AOF
配置 打开
appendonly yes | no
作用
是否开启AOF持久化功能，默认为不开启状态
配置 策略
appendfsync always | everysec| no
作用
AOF写数据策略
AOF的相关配置
appendfilename filename 。AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
AOF重写
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。
AOF重写作用
1）、降低磁盘占用量，提高磁盘利用率
2）、提高持久化效率，降低持久化写时间，提高IO性能
3）、降低数据恢复用时，提高数据恢复效率
AOF重写指令的原理
跟bgsave有点类似，也是返回消息，只不过这是是Background append only file rewriting started
4、RDB和AOF的区别
RDB与AOF的选择之惑
1)、对数据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
2）、数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB 方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
3）、综合比对
RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
灾难恢复选用RDB
双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
5、持久化应用的场景
事务
1、事务的介绍
redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。
2、事务基本操作
开启事务
multi
执行事务
exec
取消事务
discard
3、锁
1）基于特定条件的事务执行——锁
解决方案
对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行
watch key1
取消对所有 key 的监视
unwatch key
2）基于特定条件的事务执行——分布式锁
解决方案
使用 setnx 设置一个公共锁，解决业务类型是超卖的
setnx lock-key value
例如 setnx lock-num 1
清除锁用
del lock-key 例如del lock-num
基于特定条件的事务执行——分布式锁改良
使用 expire 为锁key添加时间限定，到时不释放，放弃锁
expire lock-key second
pexpire lock-key milliseconds
删除策略
1）过期数据
Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态
XX:具有时效性的数据
-1：永久有效的数据
-2：已经过期的数据或被删除的数据或未定义的数据
2）数据删除策略
定时删除
创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作
优点：节约内存，到时就删除，快速释放掉不必要的内存占用
缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
总结：用cpu性能换取存储空间（拿时间换空间），不管cpu是否繁忙，到点就删除
惰性删除
数据到达过期时间，不做处理。等下次访问该数据时
如果未过期，返回数据
发现已过期，删除，返回不存在
优点：节约CPU性能，发现必须删除的时候才删除
缺点：内存压力很大，出现长期占用内存的数据
总结：用存储空间换取处理器性能（拿空间换时间）
以上两种都是比较极端的
定期删除
周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度
特点1：CPU性能占用设置有峰值，检测频度可自定义设置
特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
总结：周期性抽查存储空间（随机抽查，重点抽查）
删除策略比对
1.定时删除 节约内存，无占用 不分时段占用CPU资源，频度高 拿时间换空间
2.惰性删除 内存占用严重 延时执行，CPU利用率高 拿空间换时间
3.定期删除 内存定期随机清理 每秒花费固定的CPU资源维护内存 随机抽查，重点抽查
在redis里 惰性删除 和定期删除都会用
3）逐出算法
当新数据进入redis时，如果内存不足怎么办？
Redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。
(error) OOM command not allowed when used memory >'maxmemory'
redis.conf
高级数据类型
