Redis 梳理

基础知识

NoSQL

• NoSQL（Not Only SQL），泛指非关系型数据库。

为了解决大规模数据几何多重数据种类带来的挑战，尤其是大数据应用，包括超大规模数据的存储。

这些类型的数据存储不需要固定的模式，无需多余操作就可以横向发展。

• 易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。

数据之间无关系，这样就非常容易扩展，在架构的层面上带来了可扩展的能力。

• 大数据量高性能

NoSQL数据库具有非常高的读写性能，尤其在大数据量下，同样表现优秀。

• 多样灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是非常麻烦的，如果是非常大的数据量的表，增加字段十分麻烦。

redis基础

• Redis速度非常快，单机可支持每秒10几万的并发，是MySQL的十几倍；
  • 内存操作；
  • C语言实现，优化了很多数据结构，性能极高；
  • 执行命令是单线程的，无上下文切换成本；（尽管在Redis6.0引入了多线程，此处是为了处理网络IO，处理数据的读写和协议解析）
• 高性能的KV键值对分布式内存数据库
• 端口：6379

特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候再次加载进行使用。
• Redis支持多种类型数据，key-value类型，list，set，zset，hash等数据结构的存储
• Redis支持数据备份，即master-slave模式的数据备份

功能：

• 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务。
• 取最新N个数据的操作，如：可以将最新的10条评论的ID放在redis的list集合里面
• 模拟类似于HTTPSession这种需求设定过期时间的功能
• 发布、订阅消息系统
• 定时器、计数器

五大数据类型：

• String 字符串，字符串value最大是512M；
• Hash 哈希，类似java中的map，
• List 列表，底层是链表；
• Set 集合，底层是hashTable实现；
• Zset（sorted set 有序集合），每个元素关联一个double类型的分数；

Redis持久化：

• RDB（Redis DataBase）

  • 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是snapshot快照，它恢复时将快照文件直接读到内存里。

  • Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，却对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。

  • RDB缺点：最后一次持久化后的数据可能丢失。

  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是这是一个全新的进程，并作为原进程的子进程。

  • fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

  • 保存的是fump.rbd文件

• AOF（Append Only File）

  • 以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
  • 启动先加载appendonly.aof
  • 每次发生数据变更会被立即记录到磁盘中，性能较差，但是数据完整性较好；

主从复制：

• 主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主；

  • 从机只读；
  • 主机挂了，重新连上，不受影响；
  • 从机挂了，需要重新配置从机，除非配置到了redis.cong文件

• 哨兵模式（sentinel）：主机挂了，自动的反客为主，从机上位，成为master，当主机恢复，主机变为了从机；

  • redis主从复制时，当主服务器宕机，从服务器不能自动切换为主服务器，为了解决这个问题，就有了哨兵模式；

  • 多个从机，如何选举出新的master？

    • 从 slave 节点中选出一个合适的 节点作为新的master节点.这里的合适包括如下几点:

    　　　　1.选择 slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续下一步判断.

    　　　　2.选择复制偏移量最大的 slave 节点(复制的最完整),如果存在则返回,不存在则继续.

    　　　　3.选择runId最小的slave节点(启动最早的节点)

常见问题

Redis如何实现分布式锁？

1.使用setnx (Set if Not eXists) 命令加锁，Key根据业务场景自定义，value可以放入临时生成的唯一键，如UUID或当前线程的ID，用于标识这把锁的拥有者。代码实现：

public boolean tryLock(String lockKey, String value, long expire)  {
		  RedisCallback<Boolean> callback = (connection) -> connection.set(lockKey.getBytes(StandardCharsets.UTF_8), value.getBytes(StandardCharsets.UTF_8), Expiration.milliseconds(expire), RedisStringCommands.SetOption.SET_IF_ABSENT);
          return redisTemplate.execute(callback);
	}

以上代码实现基于RedisTemplate的execute方法，其中参数callback为使用函数式编程思想初始化的RedisCallback对象。lambda表达式处为重写RedisCallback Interface中的doInRedis方法。

2.释放锁时，需要先校验Redis中的锁是否属于当前线程，即使用get命令校验锁Value，校验通过后使用del命令删除锁。采用redistemplate.excute方法来实现在一次连接中执行多个操作命令，代码实现：

public static final String UNLOCK_LUA;
	 
/**
 * 释放锁脚本，原子操作
 */
static {
  	StringBuilder sb = new StringBuilder();
  	sb.append("if redis.call(\"get\",KEYS[1]) == ARGV[1] ");
  	sb.append("then ");
  	sb.append("    return redis.call(\"del\",KEYS[1]) ");
  	sb.append("else ");
  	sb.append("    return 0 ");
  	sb.append("end ");
  	UNLOCK_LUA = sb.toString();
}

public boolean releaseLock(String lockKey, String value) {
      List<String> keys = new ArrayList<>();
      keys.add(lockKey);
      List<String> args = new ArrayList<>();
      args.add(value);
      Long result = redisTemplate.execute((RedisCallback<Long>) connection -> {
			Object nativeConnection = connection.getNativeConnection();
			// 集群模式和单机模式虽然执行脚本的方法一样，但是没有共同的接口，所以只能分开执行
			// 集群模式
			if (nativeConnection instanceof JedisCluster) {
				return (Long) ((JedisCluster) nativeConnection).eval(UNLOCK_LUA, keys, args);
			}
			// 单机模式
			else if (nativeConnection instanceof Jedis) {
				return (Long) ((Jedis) nativeConnection).eval(UNLOCK_LUA, keys, args);
			}
			return 0L;
		});
		return result != null && result > 0;
}

解决缓存与数据库一致性问题

1.3.1. 缓存双淘汰法

写操作流程：

(1) 删除缓存；

(2) 写数据库；

(3) 异步删除缓存，此处可以采用消息队列，在步骤(2)结束后将需要删除的数据信息发送到消息队列中，对应的消费者监听到消息后延时一段时间再删除缓存。（避免在写的过程中，又产生新的脏缓存）

1.3.2. 异步淘汰缓存法

思路：

MySQL binlog增量发布订阅消耗+消息队列+增量数据更新到redis

(1) 读取请求转到Redis：热数据基本上在Redis

(2) 写入请求转到MySQL：增加删除和 修改MySQL

(3) 更新Redis数据：MySQ数据操作binlog更新为Redis

Redis更新：

这样，一旦MySQL中发生新的写入，更新，删除和其他操作，就可以将与Binlog相关的消息推送到Redis，然后Redis会根据binlog中的记录来更新Redis。 无需处理业务线中的缓存内容。

热点Key问题

• 影响：导致热点key的机器，面对大量请求时宕机，最终机器雪崩，所有请求打到DB上；
• 解法：
  • 拆分热点key，分散到不同机器上；
  • 二级缓存；
  • 限流策略；