数据库学习笔记MySql&&Redis

一. MySql

学习资料为黑马程序员Mysql

1.SQL通用语法及分类

1.1 DML 数据操作语言

1.2. DQL 数据查询语言

1.3. DDL 数据定义语言

1.4. DCL 数据控制语言

二. Redis6

学习资料为 尚硅谷redis6教程

1. NoSQL数据库介绍

1.1 概述

** (1) 定义**
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。
NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。
• 不遵循SQL标准。
• 不支持ACID。
• 远超于SQL的性能。
（2) NoSql适用场景
• 对数据高并发的读写
• 海量数据的读写
• 对数据高可扩展性的
(3) 常用NoSql数据库

1.2 Redis相关知识介绍

端口6379
Redis是单线程+多路IO复用技术

2. 常用五大数据类型

2.1 键 key

（1）常用命令

• **keys *** 查看当前库所有key (匹配：keys *1)
• exists key 判断某个key是否存在
• type key 查看你的key是什么类型
• del key 删除指定的key数据
• unlink key 根据value选择非阻塞删除
  仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。
• expire key 10 10秒钟：为给定的key设置过期时间
• ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期
  （2）数据库的操作
• select 命令切换数据库
• dbsize 查看当前数据库的key的数量
• flushdb 清空当前库
• flushall 通杀全部库

2.2 字符串 String

（1）简介
String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M
（2）常用命令

• set key value 添加键值对
  *NX：当数据库中key不存在时，可以将key-value添加数据库
  *XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
  *EX：key的超时秒数
  *PX：key的超时毫秒数，与EX互斥
• get key查询对应键值
• append key value将给定的value追加到原值的末尾
• strlen key获得值的长度
• setnx key value只有在 key 不存在时 设置 key 的值
• incr key
  将 key 中储存的数字值增1
  只能对数字值操作，如果为空，新增值为1
• decr key
  将 key 中储存的数字值减1
  只能对数字值操作，如果为空，新增值为-1
• incrby / decrby key <步长>将 key 中储存的数字值增减。自定义步长。
• mset key1 value1 key2 value2 …
  同时设置一个或多个 key-value对
• mget key1 key2 key3 …
  同时获取一个或多个 value
• msetnx key1 value1 key2 value2 …
  同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。
  原子性，有一个失败则都失败
• getrange key <起始位置><结束位置>
  获得值的范围，类似java中的substring，前包，后包
• setrange key<起始位置>value
  用 value 覆写key所储存的字符串值，从<起始位置>开始(索引从0开始)。
• setex key<过期时间>value
  设置键值的同时，设置过期时间，单位秒。
• getset key value
  以新换旧，设置了新值同时获得旧值。
  原子性
  所谓原子操作是指不会被线程调度机制打断的操作；
  这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
  （1）在单线程中， 能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。
  （2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。
  Redis单命令的原子性主要得益于Redis的单线程。
  案例：
  java中的i++是否是原子操作？不是
  i=0;两个线程分别对i进行++100次,值是多少？ 2~200
  

（3）数据结构
String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.

如图中所示，内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

2.3 列表List

（1）简介
单键多值
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

（2）常用命令

• lpush/rpush key value1 value2 value3… 从左边/右边插入一个或多个值。

• lpop/rpop key从左边/右边吐出一个值。值在键在，值光键亡。

• rpoplpush key1 key2从key1列表右边吐出一个值，插到key2列表左边。
• lrange key start stop
  按照索引下标获得元素(从左到右)
  lrange mylist 0 -1 0左边第一个，-1右边第一个，（0-1表示获取所有）
• lindex key index按照索引下标获得元素(从左到右)
• llen key获得列表长度
• linsert key before value newvalue在value的后面插入newvalue插入值
• lrem key n value从左边删除n个value(从左到右)
• lset key index value将列表key下标为index的值替换成value
  （3）数据结构
  List的数据结构为快速链表quickList。
  首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。
  Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

2.4 集合Set

(1) 简介
set可以自动去重 Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。
(2) 常用命令

• sadd … 将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略
• smembers 取出该集合的所有值。
• sismember 判断集合是否为含有该值，有1，没有0
• scard返回该集合的元素个数。
• srem … 删除集合中的某个元素。
• spop 随机从该集合中吐出一个值。
• srandmember 随机从该集合中取出n个值。不会从集合中删除 。
• smove value把集合中一个值从一个集合移动到另一个集合
• sinter 返回两个集合的交集元素。
• sunion 返回两个集合的并集元素。
• sdiff 返回两个集合的差集元素(key1中的，不包含key2中的)

(3) 数据结构
Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

2.5 哈希 Hash

(1) 简介
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题
(2) 常用命令

• hset 给集合中的 键赋值
• hget 从集合取出 value
• hmset … 批量设置hash的值
• hexists查看哈希表 key 中，给定域 field 是否存在。
• hkeys 列出该hash集合的所有field
• hvals 列出该hash集合的所有value
• hincrby 为哈希表 key 中的域 field 的值加上增量 1 -1
• hsetnx 将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 .

(3) 底层原理
Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。

2.6 有序集合Zset (sorted set)

(1) 简介
Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。
不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。
因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。
(2) 常用命令

• zadd …将一个或多个 member 元素及其 score 值加入到有序集 key 当中。
• zrange [WITHSCORES] 返回有序集 key 中，下标在 之间的元素 带WITHSCORES，可以让分数一起和值返回到结果集。
• zrangebyscore key minmax [withscores] [limit offset count]
  返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。
• zrevrangebyscore key maxmin [withscores] [limit offset count] 同上，改为从大到小排列。
• zincrby 为元素的score加上增量
• zrem 删除该集合下，指定值的元素
• zcount 统计该集合，分数区间内的元素个数
• zrank 返回该值在集合中的排名，从0开始。

(3) 底层原理
zset底层使用了两个数据结构
（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。
（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

3. Redis配置文件详解

略 见资料

4. Redis的发布和订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
演示过程
1、 打开一个客户端订阅channel1

2、打开另一个客户端，给channel1发布消息hello

3、打开第一个客户端可以看到发送的消息

发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息

5. 新数据类型

5.1 Bitmaps

(1) 简介
Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：
Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。

(2) 命令

• setbit设置Bitmaps中某个偏移量的值（0或1）
• 
• getbit 获取Bitmaps中某个偏移量的值
• bitcount 统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2
  表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。
• bitop and(or/not/xor) [key…] bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。
  
  (3) Bitmaps与set对比
  独立访问用户数量大 不适合用Bitmaps 更适合用set
  独立访问用户数量不大 适合用Bitmaps，Bitmaps可以节省内存

5.2 HyperLogLog

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

• pfadd < element> [element …] 添加指定元素到 HyperLogLog 中
• pfcount [key …] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可
• pfmerge [sourcekey …] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得

5.3 Geospatial

(1) 简介
GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
(2) 命令

• geoadd< longitude> [longitude latitude member…] 添加地理位置（经度，纬度，名称）
• geopos [member…] 获得指定地区的坐标值
• geodist [m|km|ft|mi ] 获取两个位置之间的直线距离
• georadius < longitude>radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素

6. Jedis操作

jedis就是基于java语言的redis客户端，集成了redis的命令操作，提供了连接池管理。

6.1 Redis-Jedis 测试

导入依赖

    <dependencies>
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>3.2.0</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

测试连接

package com.guigu.jedis;
import redis.clients.jedis.Jedis;
public class jedisDemo {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("127.0.0.1",6379);
        String pong = jedis.ping();
        System.out.println("连接成功+"+pong);
        jedis.close();
    }
}

6.2 案例模拟验证码发送

在这里插入代码片

7. Redis整合SpringBoot

• 导入依赖，注意改写springboot的版本 参考尚硅谷视频
• 写config文件：格式比较复杂，直接拿尚硅谷的资源
• 遇到的bug
  （1）java版本问题 ：改三个地方的java版本为1.8
  （2）报 XX文件 为空 或者读取失败
  类似于Error:java: 读取D:\install\maven\maven-repository\com\fasterxml\jackson\datatype\jackson-datatype-jsr310\2.10.2\jackson-datatype-jsr310-2.10.2.jar时出错; error in opening zip file
  找到文件 删除后刷新maven 并重启idea
  

8. 事务和锁机制

8.1 定义

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

8.2 Multi、Exec、discard

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

8.3 事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。
如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

8.4 事务冲突

8.4.1 例子

8.4.2 悲观锁和乐观锁

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

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

8.4.3 watch和unwatch

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
unwatch取消 WATCH 命令对所有 key 的监视。
redis使用的是乐观锁，先用watch监视key，然后分别用multi exec进行操作

8.5 Redis事务三大特性

• 单独的隔离操作
  事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念
  队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
• 不保证原子性
  事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

8.6 案例

基本案例----用ab模拟并发------出现超时:连接池解决-----出现库存为负数：用乐观锁解决----------出现库存遗留，lua脚本解决

8.6.1 秒杀案例

商品库存 剩余多少个 秒杀成功后 往set里面添加user的id

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;
	}
}

8.6.2 秒杀并发模拟

ab工具模拟
问题：会出现超时和超卖问题(如下，秒杀结束后仍然秒杀成功，redis中商品个数value出现负数)

8.6.3 超卖和超时

超时：使用连接池解决
超卖：使用watch命令监视key(商品个数)，multi开启事务，exec执行

8.6.4 库存遗留问题

乐观锁带来的问题，执行完后由于版本问题，库存还遗留，引入lua脚本解决
Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。

9. 持久化操作

9.1 RDB (Redis DataBase)

9.1.1 介绍

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

9.1.2 Fork

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

9.1.3 dump.rdb文件及redis.conf

在redis.conf配置文件，默认名称为dump.rdb,文件保存路径也可以在配置文件里修改
save用来触发RDB快照

9.1.4 优点和缺点

• 优点
   适合大规模的数据恢复
   对数据完整性和一致性要求不高更适合使用
   节省磁盘空间
   恢复速度快
• 劣势
   Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
   虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
   在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
  

9.2 AOF（Append Only File）

9.2.1 介绍

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

9.2.2 相关操作及配置

• 可以在redis.conf中配置文件名称，默认为 appendonly.aof
• 默认不开启，若和RDB一起开启，系统优先考虑AOF
• 如何启动: 修改默认的appendonly no，改为yes
• 若aof文件出现异常如何恢复：通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
• 同步频率设置问题
  appendfsync always 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
  appendfsync everysec 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  appendfsync no redis不主动进行同步，把同步时机交给操作系统。
• Rewrite 压缩
  当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
  比如，set a1 v1；set b1 v2；set a1 v1 b1 v2； 这三个命令仅仅会保留最后一个

9.2.3 流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

9.2.4 优缺点

• 优点
   备份机制更稳健，丢失数据概率更低。
   可读的日志文本，通过操作AOF稳健，可以处理误操作。
• 劣势
   比起RDB占用更多的磁盘空间。
   恢复备份速度要慢。
   每次读写都同步的话，有一定的性能压力。
   存在个别Bug，造成恢复不能。
  

9.3 RDB和AOF的选择

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。

10. 主从复制

10.1 介绍

• 主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
• 作用
  读写分离，性能扩展
  容灾快速恢复(一台主机挂掉了，另外一台可以工作)
  

10.2 搭建主从复制(一主二从)

• 配置文件，启动三台服务器

include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

• 查看主从复制的相关信息****
  info replication
• 配从不配主***
  slaveof <ip><port> 成为某个实例的从服务器
  
• 读写问题
  在主机上写，在从机上可以读取数据; 在从机上写数据报错
• 重启问题
  主机挂掉，重启就行，一切如初; 从机重启需重设：slaveof 127.0.0.1 6379 可以将配置增加到文件中。永久生效。

10.3 复制原理

• 相关术语
   全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
   增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
   但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
  

10.4 常用三种主从设置

• 一主二仆
  具体操作见10.2，需要注意的是：
  从机关闭后，重启时需要重新设置才能变成从机，主机则不需要。
• 薪火相传
  上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
  风险是一旦某个slave宕机，后面的slave都没法备份。主机挂了，从机还是从机，无法写数据了
  
• 反客为主
  当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
  用 slaveof no one 将从机变为主机。

10.5 哨兵模式

10.5.1 介绍

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

10.5.2 配置

• 自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
• 配置哨兵,填写内容
  sentinel monitor mymaster 127.0.0.1 6379 1 其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。
• 启动哨兵
  redis-sentinel /myredis/sentinel.conf
• 当主机挂掉，从机选举中产生新的主机
  哪个从机会被选举为主机呢？根据优先级别：slave-priority
  原主机重启后会变为从机。

10.5.3 复制延时及故障恢复

• 复制延时
  由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
• 故障恢复
  
  优先级在redis.conf中默认：slave-priority 100，值越小优先级越高
  偏移量是指获得原主机数据最全的
  每个redis实例启动后都会随机生成一个40位的runid

11. 集群

11.1 介绍

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis 集群通过**分区（partition）**来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

11.2 搭建集群

• 配置文件
  cluster-enabled yes 打开集群模式
  cluster-config-file nodes-6379.conf 设定节点配置文件名
  cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

include /home/bigdata/redis.conf
port 6379
pidfile "/var/run/redis_6379.pid"
dbfilename "dump6379.rdb"
dir "/home/bigdata/redis_cluster"
logfile "/home/bigdata/redis_cluster/redis_err_6379.log"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

• 创建六个节点
• 将六个节点合体
  redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391
  –replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。
• -c 采用集群策略连接，设置数据会自动切换到相应的写主机
  
• 通过 cluster nodes 命令查看集群信息
• redis cluster 如何分配这六个节点?
  一个集群至少要有三个主节点。
  选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
  分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。
  

11.3 slots

• 介绍

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

• 常用命令
  CLUSTER GETKEYSINSLOT 返回 count 个 slot 槽中的键。
  Cluster counterkeysinslot 返回slot槽中的值，只能查看自己插槽中。
  Cluster Getkeysinslot<指定的最大数量> 返回槽中键的数量

11.4 故障恢复

• 如果主节点下线？
  从节点自动升为主节点
• 主节点恢复后，主从关系会如何
  主节点回来变成从机。
• 如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?
  取决于 redis.conf中的参数 cluster-require-full-coverage
  如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉
  如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

11.5 集群的Jedis开发

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("192.168.31.211",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "v1");
     System.out.println(jedisCluster.get("k1"));
  }
}

11.6 优缺点

• 优点
  实现扩容、分摊压力、无中心配置相对简单
• 缺点
  多键操作是不被支持的
  多键的Redis事务是不被支持的。lua脚本不被支持
  由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

12. 应用问题解决

12.1 缓存穿透

• 问题描述
  缓存穿透指用户的请求没有经过缓存而直接请求到数据库上了。
  key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源
  (访问不存在的key)
  
• 解决方案
  (1)对空值缓存 如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟
  (2)设置可访问的名单 使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
  (3)采用布隆过滤器 布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)
  将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
  (4)实时监控 当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

12.2 缓存击穿

• 问题描述
  一个热点的key，有大并发集中对其进行访问，突然间这个key失效了，导致大并发全部打在数据库上，导致数据库压力剧增。 (突然大量访问一个失效的key)
  
• 解决方案
  (1）预先设置热门数据
  （2）实时调整
  （3）使用锁效率会低
  

12.3 缓存雪崩

• 问题描述
  某一时刻出现大规模的缓存失效情况，大量的请求直接打在数据库上，可能会导致数据库宕机，如果重启数据库无效，会再次造成缓存雪崩 (大量的key失效)
  

• 解决方案
  （1）构建多级缓存架构
  （2）使用锁或队列
  用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
  （3）设置过期标志更新缓存
  记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
  （4）将缓存失效时间分散开

12.4 分布式锁

• 介绍
  加一把锁 所有机器都生效

• 分布式锁主流的实现方案
  基于数据库实现分布式锁
  基于缓存（Redis等）
  基于Zookeeper

• 每一种分布式锁解决方案都有各自的优缺点
  性能：redis最高
  可靠性：zookeeper最高
  这里，我们就基于redis实现分布式锁

• 设置锁和过期时间
  

• UUID防止误删(问题1)
  a在操作的时候 出现卡顿 且此时b恰好上锁 ；卡顿期间，a的锁自动释放；卡顿结束，a手动释放锁，即把b的锁误删了
  问题描述
  解决方案：上锁的时候加一个uuid，释放锁的时候进行比较
  

• LUA脚本保证删除的原子性(问题2)
  问题描述:uuid比较之后，还没有删锁，恰好过期，因此a会把b的锁给删了
  
  解决方案：
  使用lua释放锁

// 1. 从redis中获取锁,set k1 v1 px 20000 nx
String uuid = UUID.randomUUID().toString();
Boolean lock = this.redisTemplate.opsForValue()
      .setIfAbsent("lock", uuid, 2, TimeUnit.SECONDS);
// 2. 释放锁 del
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 设置lua脚本返回的数据类型
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
// 设置lua脚本返回类型为Long
redisScript.setResultType(Long.class);
redisScript.setScriptText(script);
redisTemplate.execute(redisScript, Arrays.asList("lock"),uuid);

• 满足分布式锁使用的四个条件
  互斥性。在任意时刻，只有一个客户端能持有锁。
  不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
  解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
  加锁和解锁必须具有原子性。

13. 新功能介绍

13.1 ACL

Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：
（1）接入权限:用户名和密码
（2）可以执行的命令
（3）可以操作的 KEY

13.2 工具Cluster

之前老版Redis想要搭集群需要单独安装ruby环境，Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了，通过多线程的方式对多个分片进行压测。

13.3 IO多线程

IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。