基础类型
管道
发布订阅
- 场景
事务
Bloom
有效期
- Redis如何淘汰过期的keys
RDB 快照
AOF
- 内核写数据
缺点

基础类型

每连接内命令顺序

string

图片.png
EX：过期时间
NX：不存在才能设置
XX：存在才能设置

OBJECT encoding k1（值为数字，则输出int)

bitpos
bitpos k1 1 0 0 // 在k1的值的第一个字节(0 0代表第一个字节)查找第一次出现的1
bitop and andkey k1 k2 // k1 k2 二进制and的值存进andkey

HyperLogLog

HyperLogLog的统计结果并不是一个精确的值，误差在0.81%左右，但是对于统计用户数这种场景来说足够了。

127.0.0.1:6379> pfadd login.2019_06_17 user1
(integer) 1
127.0.0.1:6379>  pfadd login.2019_06_17 user2
(integer) 1
127.0.0.1:6379>  pfadd login.2019_06_17 user3
(integer) 1
127.0.0.1:6379>  pfadd login.2019_06_17 user4
(integer) 1
127.0.0.1:6379> pfcount login.2019_06_17
(integer) 4

二进制安全

按字节流存取

List

栈（同向命令）

队列（反响命令）

数组（用Index）

单播队列（FIFO）

blpop
如果有10个客户端在阻塞获取数据，当新增一条数据被一个客户端消费后，剩下的客户端依旧阻塞

hash

对filed进行计算，点赞，收藏，详情页

set

随机事件

SRANDMEMBER key count
正数：取出一个去重的结果集（不能超过已有集）
负数：取出一个带重复的结果集，一定满足你要的数量
如果：0，不返回
spop 取出1个

sorted_set

物理内存左小右大,不随命令发生变化,zrang,zrevrang
集合操作并集，交集 ZUNIONSTORE
排序是怎么实现的增删改查的速度？
skip list 跳跃表
图片.png

管道

一次发送多个命令，节省往返时间

发布订阅

sub（监听后）才能收到pub消息

场景

qq的聊天功能，可查看历史聊天记录
关键点：三天前的数据
图片.png
用另一台redis sub消息存入sorted_set

图片.png

事务

将一组命令放在同一个事务中进行处理
图片.png
watch可以在执行事务时判断key值是否改变，若变了则不执行，事务执行失败

Bloom

缓存穿透时
redis-server —loadmodule /xx/xx/redisbloom.so /etc/redis/6379.conf
布隆过滤器：一个key由多个hash函数计算得出对应的bitmap位置

有效期

不会随着访问增加过期时间

发生写时，会剔除过期时间
可以定时 EXPIREAT

Redis如何淘汰过期的keys

Redis keys过期有两种方式：被动和主动方式。
当一些客户端尝试访问它时，key会被发现并主动的过期。
当然，这样是不够的，因为有些过期的keys，永远不会访问他们。无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从密钥空间删除。
具体就是Redis每秒10次做的事情：

测试随机的20个keys进行相关过期检测。
删除所有已经过期的keys。
如果有多于25%的keys过期，重复步奏1.

这是一个平凡的概率算法，基本上的假设是，我们的样本是这个密钥控件，并且我们不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除1/4的过期keys。

RDB 快照

开一个线程 fork（系统调用），数据修改时，触发内核机制写时复制（copy on write）

配置文件 SHAPSHOTTING

save

save 900 1
save 300 10
save 60 1000
900秒内更改了1次就写入RDB
3000秒内更改了10次就写入RDB
60秒内更改了1000次就写入RDB

bgsave

fork()子进程

弊端

不支持拉链只有一个dump.rdb
丢失数据相对多一些，时点与时点之间窗口数据容易丢失，8得到一个rdb，9纲要洛一个rdb，挂机了

优点

类似java序列化，恢复的速度快

AOF

丢失数据少
AOF中包含RDB全量，增加记录新的写操作
redis中，RDB和AOF可以同时开启，如果开启了AOF，只会用AOF恢复

appendonly yes
appendfilename "appendonly.aof"

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync always
appendfsync everysec
appendfsync no

内核写数据

图片.png buffer满了就写到磁盘
appendfsync no：buffer什么时候满了，什么时候写数据到AOF
appendfsync always：每次写操作都会写到磁盘
appendfsync everysec：每秒写buffer到磁盘

缺点

文件无限变大，恢复慢

Redis