redisyoyoll

1、整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。2、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。3、我们默认的就是RDB，一般情况下不需要修改这个配置！ 有时候在生产环境我们会将这个文件进行备份！

多线程中进行CPU的切换是要耗时的

Jedis

maxclients 10000                           # 设置能连接上redis的最大客户端的数量maxmemory <bytes>                    # redis 配置最大的内存容量maxmemory-policy noeviction      # 内存到达上限之后的处理策略1、volatile-lru：                             只对设置了过期时间的key进行LRU（默认值）2、allkeys-lru ：                             删除lru算法的key3、volatile-random：                     随机删除即将过期key4、allkeys-random：                      随机删除5、volatile-ttl ：                             删除即将过期的6、noeviction ：                             永不过期，返回错误 

原理

hyperloglog基数统计

优缺点

zset

好处

1.设置热点数据永不过期这样就不会出现热点数据过期的情况，但是当Redis内存空间满的时候也会清理部分数据，而且此种方案会占用空间，一旦热点数据多了起来，就会占用部分空间。

应用场景: 签到统计、状态统计

而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

全量复制

事务中每条命令都会被序列化，执行过程中按顺序执行，不允许其他命令进行干扰。Redis事务没有隔离级别的概念Redis单条命令是保证原子性的，但是事务不保证原子性！

缺点

工作原理

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

Slave

CLIENTS

Redis

退出redis

复制原理

Redis主从复制

lpush left pushlrange 显示list 范围rangerpush right pushRpop right popLpop left popLlen listlengthlrem remove指定下标ltrim trim截取Rpoplpush pop再push到别的listlset 设置指定下表值exists 存在Linsert 将某个具体的value插入到某个元素的前面或后面

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！

误区

lex

RDB 

一次请求若在缓存和数据库中都没找到，就在缓存中方一个空对象用于处理后续这个请求。

悲观锁

缓存穿透

生成

Z

list

rev

操作

redis高可用这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群

# 如果900s内，如果至少有一个1 key进行了修改，我们及进行持久化操作save 900 1# 如果300s内，如果至少10 key进行了修改，我们及进行持久化操作save 300 10# 如果60s内，如果至少10000 key进行了修改，我们及进行持久化操作save 60 10000# 我们之后学习持久化，会自己定义这个测试！stop-writes-on-bgsave-error yes                     # 持久化如果出错，是否还需要继续工作！rdbcompression yes                                         # 是否压缩 rdb 文件，需要消耗一些cpu资源！rdbchecksum yes                                              # 保存rdb文件的时候，进行错误的检查校验！dir ./                                                                  # rdb 文件保存的目录！

狂神说

缓存雪崩

Redis是使用C实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能。每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；默认情况下， Redis 将数据库快照保存在名字为dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。

RDB

String

比如热搜排行上，一个热点新闻被同时大量访问就可能导致缓存击穿。

ZADD key score member1 [score2 member2] 向有序集合添加一个或多个成员，或者更新已存在成员的分数ZCARD key                                                        获取有序集合的成员数ZCOUNT key min max                                      计算在有序集合中指定区间score的成员数ZINCRBY key n member                                   有序集合中对指定成员的分数加上增量 nZSCORE key member                                        返回有序集中，成员的分数值ZRANK key member                                          返回有序集合中指定成员的索引ZRANGE key start end                                       通过索引区间返回有序集合成指定区间内的成员ZRANGEBYLEX key min max                              通过字典区间返回有序集合的成员ZRANGEBYSCORE key min max                         通过分数返回有序集合指定区间内的成员==-inf 和 +inf分别表示最小最大值，                                                                             只支持开区间()==ZLEXCOUNT key min max                                  在有序集合中计算指定字典区间内成员数量ZREM key member1 [member2..]                       移除有序集合中一个/多个成员ZREMRANGEBYLEX key min max                        移除有序集合中给定的字典区间的所有成员ZREMRANGEBYRANK key start stop                   移除有序集合中给定的排名区间的所有成员ZREMRANGEBYSCORE key min max                   移除有序集合中给定的分数区间的所有成员ZREVRANGE key start end                                  返回有序集中指定区间内的成员，通过索引，分数从高到底ZREVRANGEBYSCORRE key max min                 返回有序集中指定分数区间内的成员，分数从高到低排序ZREVRANGEBYLEX key max min                         返回有序集中指定字典区间内的成员，按字典顺序倒序ZREVRANK key member                                      返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序ZINTERSTORE destination numkeys key1 [key2 ..] 计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key                                                                                    中，numkeys：表示参与运算的集合数，将score相加作为结果的scoreZUNIONSTORE destination numkeys key1 [key2..] 计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中ZSCAN key cursor [MATCH pattern\\] [COUNT count] 迭代有序集合中的元素（包括元素成员和元素分值）

1、Redis 调用forks。同时拥有父进程和子进程。2、子进程将数据集写入到一个临时 RDB 文件中。3、当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件

解决

redis-check-aof --fixaof文件修复工具

card

代码语法错误（编译时异常）所有的命令都不执行

watch

订阅我的所有小伙伴

一次性

bitmaps

AOF

Redis订阅发布

自定义RedisTemplate

缓存击穿

优点

开启事务multi

事务错误

乐观锁

持久化规则

score

incrby

序列化

hash

后台发布文章

1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。2、故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式3、负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。5、高可用基石：主从复制还是哨兵和集群能够实施的基础。

rank

range

相较于缓存穿透，缓存击穿的目的性更强，一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。这就是缓存被击穿，只是针对其中某个key的缓存不可用而导致击穿，但是其他的key依然可以使用缓存响应。

APPEND ONLY 模式 aof配置 

add

1、每一次修改都会同步，文件的完整性会更加好2、每秒同步一次，可能会丢失一秒的数据3、从不同步，效率最高

PSUBSCRIBE pattern [pattern..] 订阅一个或多个符合给定模式的频道。PUNSUBSCRIBE pattern [pattern..] 退订一个或多个符合给定模式的频道。PUBSUB subcommand [argument[argument]] 查看订阅与发布系统状态。PUBLISH channel message 向指定频道发布消息SUBSCRIBE channel [channel..] 订阅给定的一个或多个频道。UNSUBSCRIBE channel [channel..] 退订一个或多个频道

取消事务discurd

缺陷

BY

Slave 启动成功连接到 master 后会发送一个sync同步命令。Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

触发机制

geoadd key longitud(经度) latitude(纬度) member [..] 将具体经纬度的坐标存入一个有序集合geopos key member [member..] 获取集合中的一个/多个成员坐标geodist key member1 member2 [unit] 返回两个给定位置之间的距离。默认以米作为单位。georadius key longitude latitude radius m|km|mi|ft [WITHCOORD][WITHDIST] [WITHHASH] [COUNT count] 以给定的经纬度为中心， 返回集合包含的位置元素当中， 与中心的距离不超过给定最大距离的所有位置元素。GEORADIUSBYMEMBER key member radius... 功能与GEORADIUS相同，只是中心位置不是具体的经纬度，而是使用结合中已有的成员作为中心点。geohash key member1 [member2..] 返回一个或多个位置元素的Geohash表示。使用Geohash位置52点整数编码。

SLAVEOF no one

应用场景

SLAVEOF host port

单线程

appendonly.aof

1、哨兵集群，基于主从复制模式，所有主从复制的优点，它都有2、主从可以切换，故障可以转移，系统的可用性更好3、哨兵模式是主从模式的升级，手动到自动，更加健壮 缺点：4、Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦5、实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！appendfilename \"appendonly.aof\"                          # 持久化的文件的名字# appendfsync always                                              # 每次修改都会 sync。消耗性能appendfsync everysec                                      # 每秒执行一次 sync，可能会丢失这1s的数据！# appendfsync no                         # 不执行 sync，这个时候操作系统自己同步数据，速度最快！

用watch开启乐观锁，如果事务中，存在被watch监控的属性被其他线程改动了，那么在事务提交的时候就会失败当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

........................

5大数据类型

loglevel noticelogfile \"\"                              # 日志的文件位置名databases 16                       # 数据库的数量，默认是 16 个数据库always-show-logo yes        # 是否总是显示LOGO

AOF 

远程字典服务

dump.rdb

哨兵模式自动选master

bind  127.0.0.1        ip绑定protected-moid     保护模式 默认开启port                        端口

排他性

SECURITY

keys * 查询全部keyselect 3 切换数据库3dbsize 查看数据库大小flushdb 清空当前库flushall 清空所有数据exists 判断某个key是否存在move 移除keyexpire 设置过期时间，可以用作单点登录ttl 查看过期时间type 查看key的类型config set requirepass XXX 设置密码config set requirepass “” 取消密码auth xxx 登录

执行事务exec

Master

话费12kb内存就可以计算2^64个不同元素的基数因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

Geospatial

缓存空对象

复制3个配置文件，然后修改对应的信息1、端口2、pid名字3、log文件名4、dump.rdb名字

顺序性 

基于内存操作

对所有可能查询的参数以Hash的形式存储，以便快速确定是否存在这个值，在控制层先进行拦截校验，校验不通过直接打回，减轻了存储系统的压力。 

产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

存储空对象也需要空间，大量的空对象会耗费一定的空间，存储效率并不高。解决这个缺陷的方式就是设置较短过期时间即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

2.加互斥锁(分布式锁)在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。保证同时刻只有一个线程访问。这样对锁的要求就十分高。

网络配置

以日志的形式来记录每个写的操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

三种特殊数据类型

在默认情况下，用户请求数据时，会先在缓存(Redis)中查找，若没找到即缓存未命中，再在数据库中进行查找，数量少可能问题不大，可是一旦大量的请求数据（例如秒杀场景）缓存都没有命中的话，就会全部转移到数据库上，造成数据库极大的压力，就有可能导致数据库崩溃。网络安全中也有人恶意使用这种手段进行攻击被称为洪水攻击。

限流降级这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

实例

1、RDB的缺点是最后一次持久化后的数据可能丢失。

多次读写在一个cpu上，在内存情况下效率就是最高的

flushall

1、相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！2、Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

命令入队

1、高性能服务器一定是多线程的2、多线程一定比单线执行效率高

选择

redis事务

流程

增量复制

fork子进程

代码逻辑错误 (运行时异常) **其他命令可以正常执行 ** >>> 所以不保证事务原子性 

基础操作

PFADD key element1 [elememt2..]                             添加指定元素到 HyperLogLog中PFCOUNT key [key]                                                     返回给定 HyperLogLog 的基数估算值。PFMERGE destkey sourcekey [sourcekey..]                 将多个 HyperLogLog 合并为一个 HyperLogLog

日志

RedisTemplate

set

布隆过滤器

默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能由一个主节点。

redis.config

日志输入级别debugverbosenoticewaring     

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

redis-benchmark（性能测试）

数据预热数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

appendonly no yes则表示启用AOF

CPU不是redis的瓶颈，内存和网络带宽才是，可以用单线程实现每秒10w+的QPS，完全不必使用key-value的Memecache差

自定义redis类

REM

Master 继续将新的所有收集到的修改命令依次传给slave，完成同步

为什么快？

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

save