Redis

下载安装redis

https://cloud.tencent.com/developer/article/2054619

Nosql

非关系型数据库，以简单的 key-value 模式存储

redis 简介

redis 字符串

一个 redis 中字符串 value 最多可以是 512M

基本命令

keys * : 查看当前库所有的 key
exists key ： 判断 key 是否存在
type key : 查看 key 是什么类型
del key :  删除指定的 key 数据
unlink key : 根据 value 选择非阻塞删除
（仅将 keys 从 keyspace 元数据中删除，真正的删除会在后续中异步操作）
expire key 10 : 10s 为指定 key 设置过期时间
ttl key : 查看还有多少秒过期， -1 表示永不过期， -2 表示已经过期 
select  : 命令切换数据库
dbsize : 查看当前数据库的 key 的数量
flushdb : 清空当前数据库
flushall : 通杀全部库
set k1 v1 : 设置键值 
get k1 : 查询对应的键值
append k1 v1 : 将指定的 value 追加到原值末尾
strlen k1 : 获得的值的长度
setnx k1 v1 : 只有在 key 不存在时 设置 key 的值 【不能覆盖】
incr k1 : 将 key 中储存的数字值增1
（只能对数字值操作 ， 如果为空，新增值为1）
decr k1 : 将 key 中储存的数字值减1
（只能对数字值操作 ， 如果为空，新增值为-1）
incrby/decrby <k1><步长>  : 将 key 中储存的数字值增减。自定义增减数

redis 中的 incr 操作是原子性的。原子性指的是不会被线程调度机制打断的操作。
redis 单命令的原子性主要得益于 redis 的单线程。

数据结构

redis 列表

[单键多值： k1: v1 v2 v3]

常用命令

数据结构

redis 集合

redis 里面 set 和 list 的区别: set 可以自动排重

数据结构

set 的数据结构是 dict 字典。通过哈希表实现

redis 哈希

redis hash 是一个 string 类型的 field 和 value 的映射表，特别适合用于从存储对象。类似 java 里面的 Map<String,Object>

常用命令

数据结构

ziplist 和 hashtable（哈希表）。当 field-value 长度较短且个数较少时，使用 ziplist，否则使用 hashtable。

redis 有序集合 Zset

zSet 和 set 的区别

数据结构

Bitmaps

基本命令

Bitmaps 优势

HyperLogLog

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站 PV（PageView 页面访问量），可以使用 Redis 的 incr、incrby 轻松实现。但像 UV（UniqueVisitor 独立访客）、独立 IP 数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

解决基数问题有很多种方案：

• 数据存储在 MySQL 表中，使用 distinct count 计算不重复个数。

• 使用 Redis 提供的 hash、set、bitmaps 等数据结构来处理。

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。能否能够降低一定的精度来平衡存储空间？Redis 推出了 HyperLogLog。

• Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

• 在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

• 但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数？

比如数据集 {1, 3, 5, 7, 5, 7, 8}，那么这个数据集的基数集为 {1, 3, 5 ,7, 8}，基数 (不重复元素) 为 5。 基数估计就是在误差可接受的范围内，快速计算基数

基本命令

Geospatial

Redis 3.2 中增加了对 GEO 类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的 2 维坐标，在地图上就是经纬度。redis 基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度 Hash 等常见操作。

基本命令

redis 配置文件中的内容

• 只支持 bytes，不支持 bit，大小写不敏感
• include，多实例的情况可以把公用的配置文件提取出来
• 默认 bind = 127.0.0.1 只能接受本机的访问
  （不写的情况下无限制接受任何ip地址访问。生产环境要写自己应用的服务器地址，服务器需要远程访问，所以需要将其注掉。如果开启了 protected-mode【= yes】，那么在没有设定 bind ip 且没有设密码的情况下，redis 只允许接受本机的响应）
  略

发布订阅

jedis 操作

手机验证码案例

springboot 整合 redis

依赖 - yaml配置文件 -RedisConfig 配置类【略】

测试

事务

Redis 事务定义

Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis 事务的主要作用就是串联多个命令防止别的命令插队。

Multi、Exec、discard

Redis 事务中有 Multi、Exec 和 discard 三个指令，在 Redis 中，从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。而组队的过程中可以通过 discard 来放弃组队。

• 成功的情况
  
• 失败的两种情况
  

事务冲突问题

一个请求想给金额减 8000；

一个请求想给金额减 5000；

一个请求想给金额减 1000。

最终我们可以发现，总共金额是 10000，如果请求全部执行，那最后的金额变为 - 4000，很明显不合理。

悲观锁和乐观锁

• 悲观锁
  悲观锁 (Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
  

• 乐观锁
  乐观锁 (Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。

• 操作

  • WATCH key [key …]

  在执行 multi 之前，先执行 watch key1 [key2]，可以监视一个 (或多个) key ，如果在事务执行之前这个 (或这些) key 被其他命令所改动，那么事务将被打断。
  

  • unwatch

  取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。

Redis 事务三特性

单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

没有隔离级别的概念 ：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 。

秒杀案例

public class SecKill_redis {

	public static void main(String[] args) {
		Jedis jedis =new Jedis("192.168.44.168",6379);
		System.out.println(jedis.ping());
		jedis.close();
	}

	//秒杀过程
	public static boolean doSecKill(String uid,String prodid) throws IOException {
		//1 uid和prodid非空判断
		if(uid == null || prodid == null) {
			return false;
		}

		//2 连接redis
		//Jedis jedis = new Jedis("192.168.44.168",6379);
		//通过连接池得到jedis对象
		JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
		Jedis jedis = jedisPoolInstance.getResource();

		//3 拼接key
		// 3.1 库存key
		String kcKey = "sk:"+prodid+":qt";
		// 3.2 秒杀成功用户key
		String userKey = "sk:"+prodid+":user";

		//监视库存
		jedis.watch(kcKey);

		//4 获取库存，如果库存null，秒杀还没有开始
		String kc = jedis.get(kcKey);
		if(kc == null) {
			System.out.println("秒杀还没有开始，请等待");
			jedis.close();
			return false;
		}

		// 5 判断用户是否重复秒杀操作
		if(jedis.sismember(userKey, uid)) {
			System.out.println("已经秒杀成功了，不能重复秒杀");
			jedis.close();
			return false;
		}

		//6 判断如果商品数量，库存数量小于1，秒杀结束
		if(Integer.parseInt(kc)<=0) {
			System.out.println("秒杀已经结束了");
			jedis.close();
			return false;
		}

		//7 秒杀过程
		//使用事务
		Transaction multi = jedis.multi();

		//组队操作
		multi.decr(kcKey);
		multi.sadd(userKey,uid);

		//执行
		List<Object> results = multi.exec();

		if(results == null || results.size()==0) {
			System.out.println("秒杀失败了....");
			jedis.close();
			return false;
		}

		//7.1 库存-1
		//jedis.decr(kcKey);
		//7.2 把秒杀成功用户添加清单里面
		//jedis.sadd(userKey,uid);

		System.out.println("秒杀成功了..");
		jedis.close();
		return true;
	}
}

测试并发性【2000个请求，300个同时操作】，出现超卖和超时问题。

• 超时 -> 连接池
  

连接池参数：

MaxTotal：控制一个 pool 可分配多少个 jedis 实例，通过 pool.getResource () 来获取；如果赋值为 - 1，则表示不限制；如果 pool 已经分配了 MaxTotal 个 jedis 实例，则此时 pool 的状态为 exhausted。

maxIdle：控制一个 pool 最多有多少个状态为 idle (空闲) 的 jedis 实例；

MaxWaitMillis：表示当 borrow 一个 jedis 实例时，最大的等待毫秒数，如果超过等待时间，则直接抛 JedisConnectionException；

testOnBorrow：获得一个 jedis 实例的时候是否检查连接可用性（ping ()）；如果为 true，则得到的 jedis 实例均是可用的。

• 超卖 -> 乐观锁

• 解决乐观锁造成的库存遗留问题 -> lua 脚本语言
  redis是单线程，命令是按序执行的。把多个命令写在lua中相当于变为一个命令，在这个命令执行的时候其它命令不能打断，减少了并发导致的抢购失败

将复杂的或者多步的 redis 操作，写为一个脚本，一次提交给 redis 执行，减少反复连接 redis 的次数，提升性能。

LUA 脚本是类似 redis 事务，有一定的原子性，不会被其他命令插队，可以完成一些 redis 事务性的操作。

但是注意 redis 的 lua 脚本功能，只有在 Redis 2.6 以上的版本才可以使用。

利用 lua 脚本淘汰用户，解决超卖问题，redis 2.6 版本以后，通过 lua 脚本解决争抢问题，实际上是 redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

浅学 lua 脚本

持久化操作

将数据写到硬盘中

RDB （Redis DataBase）

简介

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

备份是如何执行的

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

Fork

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

在 Linux 程序中，fork () 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

AOF（Append Only File）

以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF 持久化流程

客户端的请求写命令会被 append 追加到 AOF 缓冲区内；

AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；

AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；

Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

AOF 默认不开启

可以在 redis.conf 中配置文件名称默认为 appendonly.aof 文件中开启，AOF 文件的保存路径，同 RDB 的路径一致。

AOF 和 RDB 同时开启，redis 听谁的？
AOF 和 RDB 同时开启，系统默认取 AOF 的数据（数据不会存在丢失）。

AOF 启动、修复、恢复

AOF 的备份机制和性能虽然和 RDB 不同，但是备份和恢复的操作同 RDB 一样，都是拷贝备份文件，需要恢复时再拷贝到 Redis 工作目录下，启动系统即加载。

• 正常恢复

修改默认的 appendonly no，改为 yes。
将有数据的 aof 文件复制一份保存到对应目录 (查看目录：config get dir)。
恢复：重启 redis 然后重新加载。

• 异常恢复

修改默认的 appendonly no，改为 yes。
如遇到 AOF 文件损坏，通过 /usr/local/bin/ redis-check-aof–fix appendonly.aof 进行恢复。
备份被写坏的 AOF 文件。
恢复：重启 redis，然后重新加载

AOF 同步频率设置

appendfsync always：始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好。

appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no：redis 不主动进行同步，把同步时机交给操作系统。

重写流程

bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行；

主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；

子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失；

子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件；

使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。

推荐两个都启用：

如果对数据不敏感，可以选单独用 RDB。

不建议单独用 AOF，因为可能会出现 Bug。

如果只是做纯内存缓存，可以都不用

主从复制

主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主，主从复制节点间数据是全量的。

作用：

• 读写分离，性能扩展

• 容灾快速恢复

主从复制三种情况

• 一主二仆
  当从服务器挂掉，在启动，需要重新加入主从。加入之后会从头开始复制数据

主服务器挂掉之后重新启动依然是主服务器，从服务器依然认主服务器。

• 薪火相传
  

• 反客为主
  当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改
  用 slaveof no one 将从机变为主机

主从复制原理

• Slave 启动成功连接到 master 后会发送一个 sync 命令；

• Master 接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到 slave，以完成一次完全同步。

• 全量复制：slave 服务器在接收到数据库文件数据后，将其存盘并加载到内存中。

• 增量复制：Master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。

• 但是只要是重新连接 master，一次完全同步（全量复制) 将被自动执行。

哨兵模式

反客为主自动版

反客为主：当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。用 slaveof no one 指令将从机变为主机。而哨兵模式是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

当主机挂掉，从机选举产生新的主机
哪个从机会被选举为主机呢？

根据优先级别：`slave-priority `。
原主机重启后会变为从机。

复制延时

由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器有一定的延迟，当系统很繁忙的时

候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。

选举

• 优先级：在 redis.conf 中默认 slave-priority 100，值越小优先级越高。

• 偏移量：指获得原主机数据最全的概率。

• runid：每个 redis 实例启动后都会随机生成一个 40 位的 runid。

集群

问题

• 容量不够，redis 如何进行扩容？集群

• 并发写操作， redis 如何分摊？集群

• 另外，主从模式，薪火相传模式，主机宕机，导致 ip 地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

• 之前通过代理主机来解决，但是 redis3.0 中提供了解决方案。就是无中心化集群配置【任何服务器都可以成为集群的入口，服务器之间可以互相连通】。

特点

Redis 集群（包括很多小集群）实现了对 Redis 的水平扩容，即启动 N 个 redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N，即一个小集群存储 1/N 的数据，每个小集群里面维护好自己的 1/N 的数据。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

该模式的 redis 集群特点是：分治、分片。

搭建：

略

集群登录：redis-cli -c -p 6379 采用集群策略连接，设置数据会自动切换到相应的写主机.

redis cluster 如何分配这六个节点？

• 一个集群至少要有三个主节点。
• 选项 –cluster-replicas 1 ：表示我们希望为集群中的每个主节点创建一个从节点。
• 分配原则尽量保证每个主数据库运行在不同的 IP 地址，每个从库和主库不在一个 IP 地址上。

什么是 slots

一个 Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这 16384 个插槽的其中一个。集群使用公式 CRC16 (key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16 (key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：

• 节点 A 负责处理 0 号至 5460 号插槽。
• 节点 B 负责处理 5461 号至 10922 号插槽。
• 节点 C 负责处理 10923 号至 16383 号插槽。

集群的jedis开发

Redis 集群优点

• 实现扩容

• 分摊压力

• 无中心配置相对简单

Redis 集群不足

• 多键操作是不被支持的。

• 多键的 Redis 事务是不被支持的，lua 脚本不被支持。

• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至 redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

应用问题解决

缓存穿透

解决方案

• 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

• 设置可访问的名单（白名单）：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。

• 采用布隆过滤器：布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

• 进行实时监控：当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

缓存击穿

解决方案
key 可能会在某些时间点被超高并发地访问，是一种非常 “热点” 的数据。

• 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长。

• 实时调整：现场监控哪些数据热门，实时调整 key 的过期时长。

• 使用锁：

  • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db。
  • 先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX）去 set 一个 mutex key。
  • 当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key；
  • 当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法。
    

缓存雪崩

解决方案

• 构建多级缓存架构：nginx 缓存 + redis 缓存 + 其他缓存（ehcache 等）。

• 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，该方法不适用高并发情况。

• 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。

• 将缓存失效时间分散开：比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

分布式锁

解决方案

setnx：通过该命令尝试获得锁，没有获得锁的线程会不断等待尝试。

set key ex 3000nx：设置过期时间，自动释放锁，解决当某一个业务异常而导致锁无法释放的问题。但是当业务运行超过过期时间时，开辟监控线程增加该业务的运行时间，直到运行结束，释放锁。

uuid：设置 uuid，释放前获取这个值，判断是否自己的锁，防止误删锁，造成没锁的情况。

代码

解决方法：使用 uuid 防止误删

参考链接