【缓存篇】Redis大全

数据结构

　　redis 相比 memcached 来说，拥有更多的数据结构，能支持更丰富的数据操作。如果需要缓存能够支持更复杂的结构和操作， redis 会是不错的选择。

　　redis 主要有以下几种数据类型：string、hash、list、set、sorted set

　　字符串表示：

　　众所周知，Redis是用C语言来实现的，在C语言中，String这个类型，其实就是一个char数组，比如char data[]="xxx\0"，但是，客户端往Redis发送set命令，是可以发任意的字符串的，是没有校验的，所以假如我们发了一个字符串xx\0xx，那么\0后面的xx是不会读的，只会读前面的xx（C语言中用"\0"表示字符串结束，如果字符串本身就有"\0"字符，字符串就会被截断）。

　　所以Redis自实现了一个string叫sds，sds中记录了一个len和一个char buf[]，len用来记录buf的长度，比如char buf[] = "xx\0xx"，那么len就是5，sds中还有一个比较重要的属性就是free，表示还剩余多少。

过期策略

　　redis 过期策略是：定期删除+惰性删除+内存淘汰机制。

　　定期删除：指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。假设 redis 里放了 10w 个 key，都设置了过期时间，你每隔几百毫秒，就检查 10w 个 key，那 redis 基本上就死了，cpu 负载会很高的，消耗在你的检查过期 key 上了。注意，这里可不是每隔 100ms 就遍历所有的设置过期时间的 key，那样就是一场性能上的灾难。实际上 redis 是每隔 100ms 随机抽取一些 key 来检查和删除的。

　　但是问题是，定期删除可能会导致很多过期 key 到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。

　　惰性删除：这就是说，在你获取某个 key 的时候，redis 会检查一下 ，这个 key 如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

获取 key 的时候，如果此时 key 已经过期，就删除，不会返回任何东西。

　　但是实际上这还是有问题的，如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，咋整？

　　内存淘汰机制：redis 内存淘汰机制有以下几个：

  • noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
  • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。
  • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。
  • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
  • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

　　如果你是一个老程序员，有一定积累，那么可能知道实现LRU算法有个现成的工具LinkHashMap，下面给一个LinkHashMap的LRU实现；

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int CACHE_SIZE;

    /**
     * 传递进来最多能缓存多少数据
     *
     * @param cacheSize 缓存大小
     */
    public LRUCache(int cacheSize) {
        // true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        // 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
        return size() > CACHE_SIZE;
    }
}

 

持久化策略

　　RDB：RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

　　优点：

  • RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照，非常适合用于备份，全量复制等场景。
  • Redis加载RDB恢复数据远远快于AOF方式
  • RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化

　　缺点：

  • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
  • RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB，存在老版本Redis服务无法兼容新版RDB格式的问题。 针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决
  • 如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据

 　　AOF：(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

　　优点：

  • AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
  • AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
  • AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。
　　缺点：
  • 对于同一份文件AOF文件比RDB数据快照要大。
  • AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的
  • 数据恢复比较慢，不适合做冷备。

　　决择：

  • 不要仅仅使用RDB这样会丢失很多数据。
  • 也不要仅仅使用AOF，因为这一会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。
  • 综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。

集群模式

　　在 redis3.x 版本中，便能支持 cluster 模式，而 memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。

　　如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个 G，单机就足够了，可以使用 replication，一个 master 多个 slaves，要几个 slave 跟你要求的读吞吐量有关，然后自己搭建一个 sentinel 集群去保证 redis 主从架构的高可用性。

　　redis cluster，主要是针对海量数据+高并发+高可用的场景。redis cluster 支撑 N 个 redis master node，每个 master node 都可以挂载多个 slave node。这样整个 redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。

　　另外，保障Redis缓存系统的高可用和高并发的原理，主要包括两个内容：主从架构模式，哨兵集群

性能对比

　　由于 redis 只使用单核，而 memcached 可以使用多核，所以平均每一个核上 redis 在存储小数据时比 memcached 性能更高。而在 100k 以上的数据中，memcached 性能要高于 redis。虽然 redis 最近也在存储大数据的性能上进行优化，但是比起 memcached，还是稍有逊色。

线程模型

　　redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

　　文件事件处理器的结构包含 4 个部分，本质是类React模型及状态机和调度模型的结合：

  • 多个 socket，socket不同状态有不同的事件，如果用NIO的话就支持面向channel编程
  • IO 多路复用程序，多路复用这里特指对多个IO，复用同一个线程通道去处理，多路复用程序效率高可能和0拷贝技术相关，但多路复用也是NIO的最大特点，也可以实现伪NIO或者AIO，
  • 文件事件分派器，多路复用之后的分派点，所有事件和实例状态都会分派给不同的处理器
  • 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

　　多个 socket 每个都可能同时有各自的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

 

　　首先，redis 服务端进程初始化的时候，会将 server socket 的 AE_READABLE 事件与连接应答处理器关联。这里先分清server socket是专门建立链接的一个特殊的socket；

　　客户端 socket01 向 redis 进程的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该 socket 压入队列中。文件事件分派器从队列中获取 socket，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

　　假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将 socket01 压入队列，此时事件分派器从队列中获取到 socket01 产生的 AE_READABLE 事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

　　如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。

这样便完成了一次通信。

单线程模型

  • 纯内存操作
  • 核心是基于非阻塞的 IO 多路复用机制
  • 单线程反而避免了多线程的频繁上下文切换问题

缓存设计三架构

　　1、Cache Aside Pattern（常用） Cache Aside Pattern（旁路缓存），是最经典的缓存+数据库读写模式。

  • 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
  • 更新的时候，先更新数据库，然后再删除缓存。
  • 为什么是删除缓存，而不是更新缓存呢？  
    • 缓存的值是一个结构，hash、list等更新数据需要遍历；  
    • 懒加载，使用的时候才更新缓存，也可以采用异步的方式填充缓存。    
  • 存在问题：高并发脏读的三种情况：
    • 先更新数据库，再更新缓存；update与commit之间，更新缓存，commit失败，则DB与缓存数据不一致。
    • 先更新缓存，再更新数据库；如果有两个事务同时进行着，那么顺序不一致性可能会导致数据被覆盖而导致的数据库缓存不一致。
    • 先删除缓存，再更新数据库 ；update与commit之间，有新的读，缓存空，读DB数据到缓存，数据是旧的数据；commit后DB为新的数据；  则DB与缓存数据不一致。
    • 先更新数据库，再删除缓存（推荐）；该方法适用性高，但也是有问题的。但配合延时双删出事概率会很低
    • /**
*
*延时双删除，第一个删除可以放在不同位置
*
**/
public void write(String key,Object data){
    redis.delKey(key);
    db.updateData(data);
    Thread.sleep(1000);
    redis.delKey(key);
}
    • 绝对的方案：串行化，但效率极低，所以要根据业务场景选择以上方案；
  • 2、Read/Write Through Pattern
    • 应用程序只操作缓存，缓存操作数据库；  Read-Through（穿透读模式/直读模式）：应用程序读缓存，缓存没有，由缓存回源到数据库，并写入缓存；  Write-Through（穿透写模式/直写模式）：应用程序写缓存，缓存写数据库。该种模式需要提供数据库的handler，开发较为复杂。    
  • 3、Write Behind Caching Pattern
    • 应用程序只更新缓存；  缓存通过异步的方式将数据批量或合并后更新到DB中，不能时时同步，甚至会丢数据。

相关文章：

猜你喜欢
相关资源
相似解决方案
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode