redis

value数据类型

redis 是key-value 类型的内存缓存 key的数据类型是String
value 是二进制安全的，可以理解为数据存储为二进制文件，在展示时和客户端的编码相关。

String byte

字符串

常用命令：
set
get
append
setrange
getrange
strlen

数值

常用命令：
incr 应用场景：抢购秒杀，详情页，点赞，评论，归并并发下对数据库的事务操作，然全由redis内存操作代替

bitmap

应用场景：
日活统计

List

栈
队列
数组
阻塞，单播队列FIFO

Hash

Set

无序随机性
放入的多少不同，元素存储的顺序不同去重

集合操作相当多
随机事件
- SRANDMEMEBER KEY COUNT
  
  SRANDMEMBER key count
  count 是正数：取出一个去重的结果集（不能超过已有集）
  coutnt 是负数：取出一个带重复的结果集，一定满足你要的数量
  如果count 为0 ，不返回

- SPOP

  取出1个

Sorted_set

集合操作：并集交集
- 权重/聚合指令
通过跳表实现排序
zrang/zrevrang

发布订阅（Pub/Sub）

应用场景，聊天室
聊天室数据分为实时和历史数据
实时数据可以通过发布订阅功能
历史数据，假如是近期的数据，如3天之内，用sorted_set
更老的数据需要持久化到数据库中

SUB CHANNEL

PUB CHANNEL CONTENT

管道pipeline

一次性执行多条redis指令

布隆过滤器

bloom概率解决问题
不可能百分之百阻挡
1，你有啥

通过多个映射函数向bitmap中标记
请求的可能被错误标记
但是，一定概率会大量较少放行:穿透
5.而且成本低

元素——》n个映射函数——》bitmap
判断元素是否存在，通过映射函数，比对bitmap相应位置是否为1

映射函数

bitmap

还有布谷鸟过滤器

实现的三种形式

client 实现bloom算法，并自己承载bitmap
client实现bloom算法，redis 承载bitmap
redis 实现bloom算法并承载bitmap

持久化机制

修改配置文件实现

RDB快照

时点性

某一时刻的快照

save

同步阻塞备份，比如关机维护时使用save

bgsave

异步备份，fork创建子进程进行备份

配置文件中给出bgsave的规则：

语法：save seconds changes

save 900 1
save 300 10
save 60 10000

在seconds时有changes个key改变就去备份

dbfilename dump.rdb
dir /var/lib/redis/6379

优/弊端
- 不支持拉链，只有一个dump.rdb
- 丢失数据相对多一些，是时点与时点之间窗口数据容易丢失，场景：8点得到一个rdb,9点要落一个rdb，挂机了。。。。
- 优点：类似于java中的序列化，恢复速度相对较快

AOF （Append Only File）

redis的写操作记录到文件中

丢数据少
redis中，RDB和AOF可以同时开启

如果开启了AOF ,只会用AOF恢复

AOF中包含RDB全量，增加记录新的写操作

弊端：文件体量无限变大，恢复慢
- 日志，优点如果能保住，还是可以用的
  结果：设计一个方案让日志，AOF足够小
  - HFFS, fsimage +edits.log
    让日志只记录增量
    合并的过程
  - 重写：
    将老的数据RDB到aof文件中，
    将增量以指令的方式Append 到AOF

作为缓存/数据库

缓存

缓存数据特点？

缓存数据不重要，不是全量数据，
应该是随着访问变化的热数据

redis里的数据怎么随着业务变化？

只保留热数据，应为内存大小有限，也就是内存瓶颈

缓存有效期
- 业务逻辑驱动
  
  key有效期随着访问延长？不对！！不会延长
  发生写，会剔除过期时间
  倒计时，且redis不能延长，但可以清除后手动设置
  定时（EXPIREAT）
  业务逻辑自己控制过期时间

- 业务运转驱动

  机器内存是有限的，随着访问的变化，应该淘汰掉冷数据
  LFU策略：碰了多少次
  LRU策略: 多久没碰

过期判定

有两种淘汰key的方式：被动方式和主动方式

- 主动方式

  当key超过过期事件后，并不会立即删除key，只会对过期的key执行del、set、getset时才会清除，也就意味着所有对改变key的值的操作都会触发删除动作，当client尝试访问它时，key会被发现并主动的过期
  

- 被动方式

  只靠主动方式是不够的，因为有些过期的keys，永远不会访问他们，那就永远不会过期，所以redis提供了被动方式，被动方式会定时检测过期的key,然后删除：
  每隔100ms 随机抽取20个key进行过期检测
  删除20个key中所有已过期的key
  如果过期key的比例大于25%,重复步骤1
  被动方式采用一种概率算法，对key进行随机抽样，这样就意味着，在任何给定的时刻，最多会清除1/4的过期key。
  牺牲一些内存，保证redis性能为王。

事务

MULTI/EXEC/DISCARD

WATCH

有点类似于volitale的味道

两种错误情况

事务在执行 EXEC 之前，语法错误

即使事务中有某个/某些命令在执行时产生了错误，事务中的其他命令仍然会继续执行。

最重要的是记住这样一条，即使事务中有某条/某些命令执行失败了，事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令。

当命令在入队时产生错误，错误会立即被返回给客户端

命令可能在 EXEC 调用之后失败

事务不回滚

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

XMind - Trial Version

redis基础