失眠网 > Redis 学习 - 2.Redis高级：RDB AOF 事务锁删除策略 Bitmaps HyperLogLog GEO

Redis 学习 - 2.Redis高级：RDB AOF 事务锁删除策略 Bitmaps HyperLogLog GEO

时间：2018-09-24 22:48:08

2. Redis高级2.1 Redis Linux安装047-Linux安装redis048-指定端口启动服务049-指定配置文件启动服务050-配置文件启动目录管理 2.2 持久化2.2.1 持久化简介051-持久化-持久化简介 2.2.2 RDB052-持久化-save指令053-持久化-RDB相关配置054-持久化-数据恢复过程演示055-持久化-save指令工作原理056-持久化-bgsave指令与工作原理057-持久化-save配置与工作原理058-持久化-RDB三种启动方式对比与优缺点分析 2.2.3 AOF059-持久化-AOF简介060-持久化-AOF持久化策略基本操作061-持久化-AOF重写概念与命令执行062-持久化-AOF自动重写配置063-持久化-AOF重写工作原理 2.2.4 RDB与AOF区别064-持久化-RDB与AOF方案比对 2.2.5 持久化应用场景065-持久化-持久化应用场景分析 2.3 事务2.3.1 事务简介066-事务-redis事务简介 2.3.2 事务基本操作067-事务-事务的基本操作（定义，取消，执行）068-事务-事务的工作流程069-事务-事务操作的注意事项 2.3.3 锁070-事务-锁 Tips 18：071-事务-分布式锁 Tips 19072-事务-死锁解决方案 2.4 删除策略2.4.1 过期数据073-删除策略-过期数据的概念 2.4.2 数据删除策略074-删除策略-过期数据的底层存储结构075-删除策略-定时删除与惰性删除076-删除策略-定期删除 2.4.3 逐出算法077-删除策略-逐出策略 2.5 redis.conf078-服务器配置-redis.conf配置 2.6 高级数据类型2.6.1 Bitmaps079-高级数据类型-bitmaps介绍与基本操作080-高级数据类型-bitmaps扩展操作 Tips 21:2.6.2 HyperLogLog081-高级数据类型-HyperLogLog 2.6.3 GEO082-高级数据类型-GEO Tips 23:

2. Redis高级

2.1 Redis Linux安装

047-Linux安装redis

CentOS7安装Redis下载安装包wget http://download.redis.io/releases/redis-?.?.?.tar.gz解压tar -zxvf 文件名.tar.gz编译make安装make install

048-指定端口启动服务

redis-server --port 6380redis-cli -p 6380

049-指定配置文件启动服务

过滤掉注释信息、过滤掉空白行，只留下有用的代码cat redis.conf|grep -v "#" |grep -v "^$"cat redis.conf |grep -v "#" |grep -v "^$" > redis-6379.conf

我们的配置文件内容如下：redis-6379.confport 6379# 以守护进程方式启动，后台启动，启动时不在终端上打印日志信息daemonize yes # 生成的日志文件的名字logfile "6379.log" # 生成的日志文件，放在哪个位置dir /usr/local/redis-5.0.6/log6379Data

以配置文件方式启动redis-server /usr/local/redis-5.0.6/redis-6379.conf //启动redis-serverredis-cli -p 6379//client连接serverps -ef |grep redis- //查看redis-开头的所有进程kill -s 9 进程号//杀死redis-server进程

050-配置文件启动目录管理

把redis-6379.conf文件，放到专门的目录下方便管理，放到conf文件夹下/usr/local/redis-5.0.6/conf/redis-6379.conf

想再启动一个redis-server：redis-6379.confport 6380# 以守护进程方式启动，后台启动，启动时不在终端上打印日志信息daemonize yes # 生成的日志文件的名字logfile "6380.log" # 生成的日志文件，放在哪个位置dir /usr/local/redis-5.0.6/conf/logData [root@lwh log6379Data]# redis-server /usr/local/redis-5.0.6/conf/redis-6380.conf [root@lwh log6379Data]# ps aux|grep redisroot10560 0.2 0.2 153892 2180 ? Ssl 22:58 0:00 redis-server *:6380root10566 0.0 0.0 112712 964 pts/1 S+ 22:58 0:00 grep --color=auto redis[root@lwh log6379Data]# redis-cli -p 6380//client连接server

总结Redis服务启动默认配互启动redis-server redis-server --port 6379redis-server --port 6380……指定配置文件启动redis-server redis.conf redis-server redis-6379.confredis-server redis-6380.conf redis-server conf/redis-6379 cont redis-server conf/redis-6380.conf……Redis客户端连接默认连接redis-cli连接指定服务器redis-cli -h 127.0.0.1redis-cli -p 6379redis-cli -h 127.0.0.1 -p 6379配置文件模板：redis-6379.conf# 设置当前服务器启动端口port 6379# 以守护进程方式启动，使用本启动方式，redis讲义服务的形式存在，日志将不再打印到命令窗口daemonize yes # 设定日志文件名，便于查阅logfile "6379.log" # 设定当前服务文件保存的位置，包含日志文件、持久化文件等dir /usr/local/redis-5.0.6/conf/log6379Data

2.2 持久化

2.2.1 持久化简介

051-持久化-持久化简介

持久化简介1. 意外的断电、软件崩溃2. “自动备份”：其实就是将内存中的数据和硬盘中的数据做了一个关联什么是持久化利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化为什么要进行持久化防止数据的意外丢失，确保数据安全性持久化过程保存什么将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据数据(快照) RDB将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程过程(日志) AOF

2.2.2 RDB

052-持久化-save指令

RDB启动方式谁、什么时间、干什么事情命令执行谁：redis操作者（用户）什么时间：即时（随时进行）干什么事情：保存数据

RDB启动方式—save指令命令save作用手动执行一次保存操作

127.0.0.1:6379> keys *(empty list or set)127.0.0.1:6379> set name zhangsanOK127.0.0.1:6379> save //手动执行保存指令OK[root@lwh logData]# pwd/usr/local/redis-5.0.6/conf/logData //在设置好的文件保存目录下[root@lwh logData]# lltotal 8-rw-r--r--. 1 root root 1455 Apr 5 13:54 6379.log-rw-r--r--. 1 root root 112 Apr 5 13:54 dump.rdbXXX.rdb就是持久化文件，保存了当前的快照信息

053-持久化-RDB相关配置

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

更改后的redis-6379.conf文件内容如下

054-持久化-数据恢复过程演示

启动服务客户端连接服务端，并发送指令，并save关闭服务端启动客户端，启动服务端，并连接keys *发下，上一次存储的数据，都已经加载上来了(服务启动的时候，加载了.rdb里的数据)

055-持久化-save指令工作原理

RDB启动方式-save指令工作原理注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。--> 线上环境中不建议使用save这种指令，因为很拉服务器的性能效率，有可能造成长时间的阻塞

056-持久化-bgsave指令与工作原理

RDB启动方式数据量过大，单线程执行方式造成效率过低，如何处理？后台执行谁：redis操作者（用户）发起指令；reds服务器控制指令执行什么时间：即时（发起）；合理的时间（执行）干什么事情：保存数据

RDB启动方式— bgsave指令命令bgsave注释：bg-background作用手动启动后台保存操作，但不是立即执行

RDB启动方式— bgsave指令工作原理

127.0.0.1:6379> bgsaveBackground saving started127.0.0.1:6379>

查看我们的日志文件

注意：bgsave命令是针对save阻塞问题做的优化，(save是马上执行，并且加入到任务执行序列中)Redis内部所有涉及到RDB操作都来用bgsave的方式，save命令可以放弃使用

RDB启动方式 — bgsave指令相关配置dbfilenane dump.rdbdirrdbcompression yes rdbchecksum yes stop-writes-on-bgsave-error yes说明：后台存储过程中如果出现错误现象，是否停止保存操作经验：通常默认为开启状态

redis-6379.conf配置文件更新后

# 设置当前服务器启动端口port 6379# 以守护进程方式启动，使用本启动方式，redis讲义服务的形式存在，日志将不再打印到命令窗口daemonize yes # 设定日志文件名，便于查阅logfile "6379.log" # 设定当前服务文件保存的位置，包含日志文件、持久化文件等dir /usr/local/redis-5.0.6/conf/logData # 设置 .rdb文件名 (RDB持久化文件名)dbfilename dump-6379.rdb# 开启压缩(持久化文件)rdbcompression yes# 开启加载检测rdbchecksum yes# bgsave后台存储过程中，如果出现错误现象，是否停止保存操作stop-writes-on-bgsave-error yes

057-持久化-save配置与工作原理

RDB启动方式反复执行保存指令，忘记了怎么办？不知道数据产生了多少变化，何时保存？自动执行谁：redis服务器发起指令（基于条件）什么时间：满足条件干什么事情：保存数据

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

注意：save配要根据实际业务情兄进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系save配置启动后执行的是bgsave操作

redis-6379.conf

058-持久化-RDB三种启动方式对比与优缺点分析

rdb特殊启动形式全复制在主从复制中详细讲解服务器运行过程中重启debug reload关闭服务器时指定保有数据shutdown save //可以关闭redis-server

RDB优点RDB是一个紧凑压缩的二进制文件，存效率较高RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景RDB恢复数据的速度要比AOF快很多应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复RDB缺点RDB方式无论是执行指令还是利用五，无法到实时持久化，具有较大的可能性丢失数据bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

2.2.3 AOF

059-持久化-AOF简介

RDB存储的弊端存储数据量较大，效率较低基于快照思想，每次读写都是全部据，当数据量巨大时，效率非常低大数据量下的IO性能较低基于fok创建子进程，内存产生额外消耗宕机带来的数据丢失冈脸解决思路不写全数据，仅记录部分数据改记录数据为记录操作过程对所有操作均进行记录，排除丢失数据的风险

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

060-持久化-AOF持久化策略基本操作

AOF写数据三种策略（appendfsync）always(每次)每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用everysec(每秒)毎秒将缓冲区中的指令同步到AOF文件中，数据准确性铰高，性能铰高，建议使用，也是默认配置在系统突然宕机的情况下丢失1秒内的数据no(系统控制)由操作系统控制每次同步到AOF文件的周期，整体过程不可控

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

AOF相关配置配置appendfilename filename作用AOF持久化文件名，默认文件名末 appendonly.aof，建议配置为 appendonly-端口号.aof配置dir作用AOF持久化文件保存路径，与RDB持久化文件保持一致即可

redis-6379.conf

##################################################### 设置当前服务器启动端口port 6379# 以守护进程方式启动，使用本启动方式，redis讲义服务的形式存在，日志将不再打印到命令窗口daemonize yes # 设定日志文件名，便于查阅logfile "6379.log" # 设定当前服务文件保存的位置，包含日志文件、持久化文件等dir /usr/local/redis-5.0.6/conf/logData ##################################################### 设置 .rdb文件名 (RDB持久化文件名)dbfilename dump-6379.rdb# 开启压缩(持久化文件)rdbcompression yes# 开启加载检测rdbchecksum yes##################################################### bgsave后台存储过程中，如果出现错误现象，是否停止保存操作stop-writes-on-bgsave-error yes# 指定时间内，key的更改达到指定的数量，Redis自动进行gbsave操作# 此处设置的是每300s发生10次变化，就进行一次bgsavesave 900 1save 300 10save 60 10000##################################################### 开启对AOF的支持appendonly yes# 指定AOF写数据的策略appendfsync everysec# 设置AOF持久化文件名appendfilename appendonly-6379.aof ####################################################

061-持久化-AOF重写概念与命令执行

AOF写数据遇到的问题如果连续执行如下指令该如何处理127.0.0.1:6379> set name zs127.0.0.1:6379> set name Is127.0.0.1:6379> set name wv //只有这一次最终生效 --> 127.0.0.1:6379> set name ww127.0.0.1:6379> incr num127.0.0.1:6379> Incr nun127,0.0.1:6379> Incr nun //假设num刚开始不存在--> 127.0.0.1:6379> set nun3

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

AOF重写规则进程内已超时的数据不再写入文件忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令如del key1、 hdel key2、 srem key3、 set key4111、 set key4222等对同一数据的多条写命令合并为一条命令如 Push list1 a、 Push list1 b、 Push list1 c可以转化为：Push list1 a b c为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式手动写bgrewriteaof自动重写auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percentage

062-持久化-AOF自动重写配置

AOF自动重写方式自动重写触发条件设置auto-aof-rewrite-min-size size //配置的：aof自动重写的临界值auto-aof-rewrite-percentage percent//：aof自动重写的百分比自动重写触发比对参数（运行指令 info Persistence获取具体信息）aof_current_size //aof缓存中，当前已经缓存了多少，当大于size时，就进行重写aof base size自动重写触发条件aof_current_size>auto-aof-rewrite-min-size ( (aof_current_size-aof_base_size) / aof_base_size ) > auto-aof-rewrite-percentage AOF自动重写方式自动重写触发条件设置：auto-aof-rewrite-min-size size //配置的：aof自动重写的临界值自动重写触发比对参数：aof_current_size//aof缓存中，当前已经缓存了多少，当大于size时，就进行重写自动重写触发条件：aof_current_size>auto-aof-rewrite-min-size //当缓存大于size时，就进行重写AOF自动重写方式自动重写触发条件设置：auto-aof-rewrite-percentage percent//：aof自动重写的百分比自动重写触发比对参数：aof_base_size自动重写触发条件：( (aof_current_size-aof_base_size) / aof_base_size ) > auto-aof-rewrite-percentage

063-持久化-AOF重写工作原理

2.2.4 RDB与AOF区别

064-持久化-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来恢复数据，降低丟失数据的量

2.2.5 持久化应用场景

065-持久化-持久化应用场景分析

Tips1：redis用于控制数据库表主键id，为数据库表主键ID提供生成策略，保障教据库表的主键唯一性不建议使用持久化，因为可能导致ID重复直接从数据库中找到最大的那个ID，然后从ID+1直接往下用就行了Tips2：redis控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作Tips3：redis应用于各种结构型和非结构型高热度数据访问加速不使用持久化Tips4：redis应用于购物车数据存储设计不使用持久化Tips5：redis应用于抢购、限购类、限量发放优患卷、激活码等业务的数据存储设计对于这种快速存储，快速消失的数据建议使用持久化Tips6：redis应用于具有操作先后顺序的数据控制对于这种临时的任务，如果量不是特别大的话，建议使用持久化Tips7：redis应用于最新消息展示对于这种临时的任务，如果量不是特别大的话，建议使用持久化Tips8：redis应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等Tips9：redis应用于同类信息的关联搜索，一度关联搜索，深度关联搜索从MySQL数据库里读取就行，不使用Redis持久化Tips10：redis应用于同类型不重复数据的合并、取交集操作Tips11：redis应用于同类型数据的快速去重Tips12：redis应用于基于黑名单与白名单设定的服务控制黑名单：长期策略的话，数据库里肯定要存储黑名单：不是长期策略，短期策略，建议使用Redis持久化白名单：数据库里肯定有存储，一般不需要Redis持久化Tips13：redis应用于计数器组合排序功能对应的排名建议Redis持久化Tips14：redis应用于定时任务执行顺序管理或任务过期管理Tips15：redis应用于及时任务/消息队列执行管理任务队列、消息队列：不建议使用Tips16：redis应用于按次结算的服务控制不重要时，不使用重要，使用Tips17：redis应用于基于时间顺序的数据操作，而不关注具体时间

总结Redis持久化什么是持久化RDBsave //save指令bgsave //bgsave指令配置//使用的是bgsaveAOF持久化写策略//三种：always second 重写//AOF文件会很大，所以要使用这种优化策略

2.3 事务

2.3.1 事务简介

066-事务-redis事务简介

什么是事务Redis执行指令过程中，多条连续执行的指令被干扰，打断，插队Redis事务就是一个命令执行的队列，将一系列预定义命令，包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被断或者干扰一个队列中，一次性、顺序性、排他性的执行一系列命令

2.3.2 事务基本操作

067-事务-事务的基本操作（定义，取消，执行）

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

争事务定义过程中发现出了问题，怎么办？取消事务discard作用：终止当前事务的定义，发生在multi之后，exec之前

068-事务-事务的工作流程

当事务中遇到discard指令时

069-事务-事务操作的注意事项

定义事务的过程中，命令格式输入错误怎么办？语法错误：命令书写格式有误处理结果：如果定义的事务中所包含的命令存在语法错误，整体事务中所有命令均不会执行。包括那些语法正确的命令。

定义事务的过程中，命令执行出现错误怎么办？运行错误：命令格式正确(但是指令的语法错误)，无法正确的执行。例对list进行incr操作处理结果：能够正确运行的命令会执行，运行错误的命令不会被执行注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。

手动进行事务回滚记录操作过程中被影响的数据之前的状态单数据：string多数据：hash、list、set、zset设置指令恢复所有的被修改的项单数据：直接set（注意周边属性，例如时效）多数据：修改对应值或整体克隆复制

2.3.3 锁

070-事务-锁

基于特定条件的事务执行业务场景天猫双11热卖过程中，对已经售罄的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系列的操作，牵扯到多个连续操作，如何保障不会重复操作？业务分析多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作在操作之前锁定要操作的数据，一旦发生变化，终止当前操作

基于特定条件的事务执行—锁解决方案对key添加监视锁，在执行exec前如果key发生了变化，终止事务执行watch key1 key2…… //在开启事务之前去watch取消对所有key的监视unwatchwatch指令监控的东西一旦发生改变，下面定义的事务就不会再执行了

Tips 18：

Tips 18：redis应用于基于状态控制的批量任务执行

071-事务-分布式锁

基于特定条件的事务执行业务场景天猫双11热卖过程中，对已经售罄的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购买完毕。本次补货已经将库存全部清空，如冋避免最后一件商品不被多人同时购买？【超卖问题】业务分析使用 watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据虽然 Redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避兔不被同时修改？

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

Tips 19

Tips 19redis应用：基于分布式锁对应的场景控制

072-事务-死锁解决方案

上图：上着厕所的人，上锁了，但是睡着了，那外面等待的人得有多崩溃啊实际：上锁了，正用着呢，但是宕机了；或者忘记打开了

基于特定条件的事务执行业务场景依赖分布式锁的机制，某个用户操作时，对应的客户端宕机，且此时已经获取到锁。如何解决？业务分析由于锁操作由用户控制加锁解锁，必定会存在加锁后未解锁的风险需要解锁操作不能仅依赖用户控制，系统級别要给出对应的保底处理方案

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

127.0.0.1:6379> set name 123ok 127.0.0.1:6379> setnx lock-name 1integer) 1127.0.0.1:6379> expire lock-name 20integer) 1127.0.0.1:6379> get name"123"127.0.0.1:6379> del lock-name integer) 1127.0.0.1:6379>

2.4 删除策略

2.4.1 过期数据

073-删除策略-过期数据的概念

Redis中的数据特征Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态XX：具有时效性的数据1：永久有效的数据2：已经过期的数据或被删除的数据或未定义的数据过期的数据真的删除了吗？

过期数据删除策略1.定时删除2.惰性删除3.定期删除

2.4.2 数据删除策略

074-删除策略-过期数据的底层存储结构

过期数据删除策略的目标在内存占用与CPU占用之间寻找一种平衡，顾比失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露

075-删除策略-定时删除与惰性删除

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

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

076-删除策略-定期删除

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

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

2.4.3 逐出算法

077-删除策略-逐出策略

逐出算法新数据进入检测当新数据进入redis时，如果内存不足怎么办？Redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令凊理存储空间。清理数据的策略称为逐出算法。注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。（error）OOM command not allowed when used memory >'maxmemory'

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

影响数据逐出的相关配置检测易失数据（可能会过期的数据集 server.db[i].expires）volatile-lru：挑选最近最少使用的数据淘汰volatile-lfu：挑选最近使用次数最少的数据淘汰volatile-ttl：挑选将要过期的数据淘汰volatile-random：任意选择数据匋汰LRU:Least Recently Used -- 最近，'最长时间没使用'的(规定时间内)LFU Least Frequently Used- 最近，'最少使用次数'的(规定时间内)检测全库数据（所有数据集 server.db[i].dict）allkeys-lru：挑选最近最少使用的数据淘汰allkeys-lfu：挑选最近使用次数最少的数据淘汰allkeys-random：任意选择数据淘汰放弃数据驱逐no- eviction（驱逐）：禁止驱逐数据倨（redis4.0中默认策略），会引发错误OOM（Out Of Memory）

.conf配置文件中-配置逐出策略maxmemory-policy volatile-lru

数据逐出策略配置依据使用info命令输出监控信息，查询缓存hit和miss的次数，根据业务需求调优Redis配置

Redis删除策略数据删除策略(过期数据)定时刪除惰性删除定期删除数据逐出策略(时效性数据和永久性数据)8种策略加速运行效率减少无效的key的存储为我们释放出一些更加有用的空间来达到数据的快速操作与利用平衡是你需要把握的核心操作

2.5 redis.conf

078-服务器配置-redis.conf配置

服务器基础配置服务器端设定设置服务器以守护进程的方式运行daemonize yes|no绑定主机地址bind 127.0.0.1设置服务器端口号port 6379设置数据库数量databases 16日志配置设置服务器以指定日志记录级别loglevel debug|verbose|notice|warning日志记录文件名1ogfi1e端囗号.1og注意：日志级别开发期设互为 verbose即可，生产环境(上线运行的)中配互为 notice，简化日志输出量，降低写日志IO的频度客户端配置设置同一时间最大客户端连接数，默认无限制。当客户端连接到达上限， Redis会关闭新的连接，0表示不限制上限maxclients 0客户端闲置等待最大时长，达到最大值后关闭连接。如需关闭该功能，设置为0。 (多长时间不用，自动断掉与client的连接)timeout 300多服务器快捷配置导入并加载指定配置文件信息，用于快速创建redis公共配置较多的redis实例配置文件，便于维护 (有点类似于继承，用于加速配置)相对路径用的比较多，绝对路径用的少一些主的配置文件，起一个特殊的名字；其他的用端口号起名字就行了inc1ude /path/ server-端口号.conf

redis-6379.conf

#####################################################绑定IPbind 127.0.0.1# 设置当前服务器启动端口port 6379# 数据库个数databases 16# 以守护进程方式启动，使用本启动方式，redis讲义服务的形式存在，日志将不再打印到命令窗口daemonize yes # 设定日志文件名，便于查阅logfile "6379.log" # 设定当前服务文件保存的位置，包含日志文件、持久化文件等dir /usr/local/redis-5.0.6/conf/logData ##################################################### 设置 .rdb文件名 (RDB持久化文件名)dbfilename dump-6379.rdb# 开启压缩(持久化文件)rdbcompression yes# 开启加载检测rdbchecksum yes##################################################### bgsave后台存储过程中，如果出现错误现象，是否停止保存操作stop-writes-on-bgsave-error yes# 指定时间内，key的更改达到指定的数量，Redis自动进行gbsave操作# 此处设置的是每300s发生10次变化，就进行一次bgsavesave 900 1save 300 10save 60 10000##################################################### 开启对AOF的支持appendonly yes# 指定AOF写数据的策略appendfsync everysec# 设置AOF持久化文件名appendfilename appendonly-6379.aof ####################################################

2.6 高级数据类型

2.6.1 Bitmaps

079-高级数据类型-bitmaps介绍与基本操作

bitmaps并不是一个全新的数据类型只是对string中存储对的数，进行二进制位(即以字节为单位进行操作)操作的接口作用：快速的做状态统计用的，用bit保存数据

Bitmaps类型的基础操作获取指定key对应偏移量上的bit值getbit key offset设置指定key对应偏移量上的bit值，value只能是1或0setbit key offset valuea

080-高级数据类型-bitmaps扩展操作

Bitmaps类型的扩展操作业务场景电影网站统计每天某一部电影是否被点播统计每天有多少部电被点播统计每周/月/年有多少部电影被点播统计年度哪部电彯没有被点播

Bitmaps类型的扩展操作对指定key按位进行交、并、非、异或操作，并将结果保存到 deskey中bitop operator deskey key1 [key2...]operator 类型：and：交or：并not：非xor：异或destkey：运算结果存放的地方统计指定key中1的数量 (不填范围，就是统计全部的)bitcount key [start end]

Tips 21:

Tips 21:Redis应用于信息状态统计

2.6.2 HyperLogLog

081-高级数据类型-HyperLogLog

HyperLogLog作用：统计不重复数据的数量作用：做基数统计的比如：统计独立UV原始方案：set存储每个用户的id（字符串）改进方案：Bitmaps存储每个用户状态（bit）全新的方案：Hyperloglog

基数基数就是数据集合去重后元素的个数HyperLogLog是用来做基数统计的，运用了LogLog算法

HyperLogLog类型的基本操作添加数据pfadd key element [element ..]统计数据pfcount key [key ..]合并数据pfmerge deskey sourcekey [sourcekey...]

Tips 22:Redis 应用于独立信息统计

HyperLogLog相关说明用于进行基数统计，不是集合，不保存数据，只记录数量而不是具体数据核心是基数估算算法，最终数值存在一定误差误差范围：基数估计的结果是一个带有0.81%标准错误的近似值耗空间极小，每个hyperloglog key占用了12K的内存用于标记基数pfadd命令不是一次性分配12K内存使用，会随着基数的增加内存逐渐増大pfmerge命令合并后占用的存储空间为12K，无论合并之前数据量多少

2.6.3 GEO

082-高级数据类型-GEO

作用：根据点的位置(经纬度)，计算点之间的距离等作用：做地理位置信息计算的GEO类型的基本操作添加坐标点geoadd key longitude latitude member [longitude latitude member ..]key 把这些点放到一个容器中longitude latitude 经纬度信息member 这个点的名称获取坐标点geopos key member [member ..]计算坐标点距离geodist key member member2 [unit]unit：单位 m-米 km-千米根据坐标求范围内的数据(指定范围内有多少个点)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...]