redis

redis相关内容整理，包括nosql数据库出现的背景、redis的应用场景、数据类型及主要特性、redis的其他特性等。

redis

• NoSQL数据库出现的背景
  • 出现的背景
    • 关系型数据库在性能上出现了一些瓶颈，而瓶颈的源头一般是在磁盘的I/O上
  • 解决了什么问题
    • 低延迟的读写速度
    • 支撑海量的数据和流量
    • 大规模集群的管理
    • 运营成本
  • 其他类型的NoSQL数据库
• 应用场景
  • 缓存系统（“热点”数据：高频读、低频写）
    • 计数器/排行榜
    • 共享session
  • 发布订阅
    • redis可以通过pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的缺点，当消费者下线时，生产的消息会丢失。
  • 分布式锁
    • 先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。可以使用redis事务机制 将两条指令合并执行。
  • 延时消息队列
    • 使用sortedset，使用时间戳做score, 消息内容作为key,调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。
• 数据类型及主要特性
  • string类型：它是一个二进制安全的字符串，意味着它不仅能够存储字符串、还能存储图片、视频等多种类型, 最大长度支持512M
  • hash类型：该类型是由field和关联的value组成的map。其中，field和value都是字符串类型的。
  • list类型：该类型是一个插入顺序排序的字符串元素集合, 基于双链表实现。
  • Set类型：Set类型是一种无顺序集合, 它和List类型最大的区别是：集合中的元素没有顺序, 且元素是唯一的。Set类型主要应用于：在某些场景，如社交场景中，通过交集、并集和差集运算，通过Set类型可以非常方便地查找共同好友、共同关注和共同偏好等社交关系。
  • ZSet类型：ZSet是一种有序集合类型，每个元素都会关联一个double类型的分数权值，通过这个权值来为集合中的成员进行从小到大的排序。与Set类型一样，其底层也是通过哈希表实现的。
  • HyperLogLog类型：计数器
  • Bloom过滤器：布隆过滤器是最具代表性的概率数据结构，最大的缺点是无法删除项目
    • 1. 检查用户名可用性2. 欺诈检测和缓解某些类型的网络攻击3. 跟踪已知URL的Web爬虫
  • Cuckoo过滤器：
  • 开启ReBloom插件
    • 布谷鸟 > 布隆
      • 1. 删除项目2. 更快的查找（因为更好的内存位置）3. 空间效率（当目标错误率低于3％时）4. 更快的插入（当过滤器的填充率低于80％时）
    • 布谷鸟 < 布隆
      • 1. 你的填充率超过80％;布谷鸟过滤器的插入速度很快就会低于布隆。2. 你有更宽松的目标错误率（大于3％），使布谷鸟过滤器的空间效率降低3. 你需要高度可预测的行为：布谷鸟过滤器在插入过程中使用随机源来提供性能改进
• redis其他特性
  • 发布订阅(Pub/Sub)
    • “fire and forgot”, 发送即遗忘
    • 命令：Publish/Subscribe/Psubscribe/UnSub
  • Stream（Redis 5.0新增）
    • 等待消费
    • 消费组(组内竞争)
    • 消费历史数据
    • FIFO（先进先出）
  • 通信协议
    • 外部通信协议：RESP
    • 内部通信协议：RECP
  • Redis 4.0版本引入了Lazy Free，将慢操作异步化，这也是在事件处理上向多线程迈进了一步
• 事务
  • 命令序列化，按顺序执行
  • 三阶段: 开始事务 - 命令入队 - 执行事务一个队列中，一次性、顺序性、排他性的执行一系列命令
  • 原子性
    • 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
  • 命令：MULTI/EXEC/DISCARD
  • redisTemplate开启事务两种方式
    • 子主题
    • 子主题
• 使用过程中面临的问题
  • 缓存穿透/击穿
    • 在Redis获取某一key时, 由于key不存在, 而必须向DB发起一次请求的行为, 称为“Redis击穿”
    • 引发击穿的原因及解决方案
      • Key过期
        • 对某些高频访问的Key，设置合理的TTL或永不过期
        • 加锁排队：互斥锁对某个key只允许一个线程查数据写缓存，其他线程等待。
      • 第一次访问
        • 服务器启动时, 提前写入
      • 恶意访问不存在的key
        • 布隆过滤器
        • 规范key的命名, 通过中间件拦截
  • 雪崩
    • Redis缓存层由于某种原因宕机后，所有的请求会涌向存储层，短时间内的高并发请求可能会导致存储层挂机，称之为“Redis雪崩”
    • 缓存时间增加随机值：每个缓存时间不一样，避免集体失效。
  • 缓存数据与数据库不一致性问题解决方案
    • 先更新数据库，再删除缓存
• 为什么单线程还那么快
  • 单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
  • 为什么说redis能够快速执行
    • 绝大部分请求是纯粹的内存操作
    • 采用单线程,避免了不必要的上下文切换和竞争条件
    • 非阻塞IO - IO多路复用
  • 内部实现
    • 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架
    • epoll中的读、写、关闭、连接都转化成了事件
    • 利用epoll的多路复用特性
• 持久化，备份以及集群
  • 持久化方案
    • RDB
    • AOF
  • 集群方案
  • Redis常见性能问题和解决方案
    • Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件；(Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照;AOF文件过大会影响Master重启的恢复速度)
    • 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
    • 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
    • 尽量避免在压力很大的主库上增加从库
    • 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...；这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。