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，你有啥

2. 通过多个映射函数向bitmap中标记
3. 请求的可能被错误标记
4. 但是，一定概率会大量较少放行:穿透
   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