Redis面试知识点
1.Redis概述
在我们日常的Java Web开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。
NoSQL 技术
为了克服上述的问题，Java Web项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。
Redis和MongoDB是当前使用最广泛的NoSQL，而就Redis技术而言，它的性能十分优越，可以支持每秒十几万此的读/写操作，其性能远超数据库，并且还支持集群、分布式、主从同步等配置，原则上可以无限扩展，让更多的数据存储在内存中，更让人欣慰的是它还支持一定的事务能力，这保证了高并发的场景下数据的安全和一致性。
因为普通的关系型数据库是把数据存在磁盘里的，而redis是把数据存在内存里的，所以redis的读写速度要比一般的关系型数据库要快很多。
Redis是一款非关系型的内存高速缓存数据库；
Redis 为什么那么“快”
纯内存KV操作
内部是单线程实现的（不需要创建/销毁线程，避免上下文切换，无并发资源竞争的问题）
异步非阻塞的I/O（多路复用）
Redis使用单线程，相比于多线程快在哪里？
Redis的瓶颈不在线程，不在获取CPU的资源，所以如果使用多线程就会带来多余的资源占用。比如上下文切换、资源竞争、锁的操作。
上下文的切换
上下文其实不难理解，它就是CPU寄存器和程序计数器。主要的作用就是存放没有被分配到资源的线程，多线程操作的时候，不是每一个线程都能够直接获取到CPU资源的，我们之所以能够看到我们电脑上能够运行很多的程序，是应为多线程的执行和CPU不断对多线程的切换。但是总有线程获取到资源，也总有线程需要等待获取资源，这个时候，等待获取资源的线程就需要被挂起，也就是我们的寄存。这个时候我们的上下文就产生了，当我们的上下文再次被唤起，得到资源的时候，就是我们上下文的切换。
竞争资源
竞争资源相对来说比较好理解，CPU对上下文的切换其实就是一种资源分批，但是在切换之前，到底切换到哪一个上下文，就是资源竞争的开始。在我redis中由于是单线程的，所以所有的操作都不会涉及到资源的竞争。
锁的消耗
对于多线程的情况来讲，不能回避的就是锁的问题。如果说多线程操作出现并发，有可能导致数据不一致，或者操作达不到预期的效果。这个时候我们就需要锁来解决这些问题。当我们的线程很多的时候，就需要不断的加锁，释放锁，该操作就会消耗掉我们很多的时间
I/O复用，非阻塞模型
对于I/O阻塞可能有很多人不知道，I/O操作的阻塞到底是怎么引起的，Redis又是怎么解决的呢？
I/O操作的阻塞：当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
Redis采用多路复用：I/O 多路复用其实是在单个线程中通过记录跟踪每一个sock（I/O流） 的状态来管理多个I/O流。select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。
select(),poll()缺点：
涉及到用户态跟内核态的切换，耗性能，需要上下文切换，消耗资源大；
返回值是 int，只能知道就绪的socket个数，需要重新轮询找出是具体哪个socket就绪。
select()跟poll()主要区别：传参不一样——select()：bitmap；poll()：数组
解决了bitmap长度 1024 难以修改的问题
epoll()：
- 数据模型为：key - value，非关系型数据库使用的存储数据的格式，同时还提供list，set，zset，hash等数据结构的存储。
- 可持久化：将内存数据在写入之后按照一定格式存储在磁盘文件中，宕机、断电后可以重启redis时读取磁盘中文件恢复缓存数据；
- 分布式：当前任务被多个节点切分处理，叫做分布式处理一个任务。单个服务器内存，磁盘空间有限，无法处理海量的缓存数据，必须支持分布式的结构；
- Redis支持数据的备份，即master-slave模式的数据备份。
redis的数据类型，以及每种数据类型的使用场景
一共五种
- String（最常用）
这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存
常用方法：
set key value 设置一个key 值为 value
get key 获得key值得value
incr key —对应的value 自增1,如果没有这个key值 自动给你创建创建 并赋值为1
decr key —对应的value 自减1
- hash
这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。
格式
常用方法：
hset key filed value 设置值
hget key filed 获取值
hlen key filed value 统计某一数值下的数据条数是多少
例如：用redis实现购物车
- List
使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适—取行情信息。就也是个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。
常用方法：
List 有顺序可重复
lpush list 1 2 3 4 从左添加元素
rpush list 1 2 3 4 从右添加元素
lrange list 0 -1 (从0 到-1 元素查看：也就表示查看所有)
lpop list （从左边取，删除）
rpop list (从右边取，删除)
- set
因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
常用方法：
Set 无顺序，不能重复
sadd set1 a b c d d (向set1中添加元素) 元素不重复
smembers set1 （查询元素）
srem set1 a （删除元素）
- sorted set sorted set
Sorted Set多了一个权重参数 Score，集合中的元素能够按 Score 进行排列。
可以做排行榜应用，取 TOP N 操作。Sorted Set 可以用来做延时任务。最后一个应用就是可以做范围查找。
有顺序，不能重复
适合做排行榜 排序需要一个分数属性
常用方法：
zadd zset1 9 a 8 c 10 d 1 e （添加元素 zadd key score member ）
(ZRANGE key start stop [WITHSCORES])(查看所有元素：zrange key 0 -1 withscores)
如果要查看分数，加上withscores.
zrange zset1 0 -1 (从小到大)
zrevrange zset1 0 -1 (从大到小)
zincrby zset2 score member (对元素member 增加 score)
最后，还有个对key的通用操作，所有的数据类型都可以使用的
3.Redis 在 Java Web 中的应用
Redis 在 Java Web 主要有两个应用场景：
- 存储 缓存 用的数据；
- 需要高速读/写的场合使用它快速读/写；
缓存
在日常对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用SQL语句去数据库进行读写操作时，数据库就会去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。
如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样速度明显就会快上不少，并且会极大减小数据库的压力，但是使用内存进行数据存储开销也是比较大的，限于成本的原因，一般我们只是使用 Redis 存储一些常用和主要的数据，比如用户登录的信息等。
一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：
- 业务数据常用吗？命中率如何？如果命中率很低，就没有必要写入缓存；
- 该业务数据是读操作多，还是写操作多？如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
- 业务数据大小如何？如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要；
在考虑了这些问题之后，如果觉得有必要使用缓存，那么就使用它！使用 Redis 作为缓存的读取逻辑如下图所示：
从上图我们可以知道以下两点：
- 当第一次读取数据的时候，读取 Redis 的数据就会失败，此时就会触发程序读取数据库，把数据读取出来，并且写入 Redis 中；
- 当第二次以及以后需要读取数据时，就会直接读取 Redis，读到数据后就结束了流程，这样速度就大大提高了。
从上面的分析可以知道，读操作的可能性是远大于写操作的，所以使用 Redis 来处理日常中需要经常读取的数据，速度提升是显而易见的，同时也降低了对数据库的依赖，使得数据库的压力大大减少。
分析了读操作的逻辑，下面我们来看看写操作的流程：
从流程可以看出，更新或者写入的操作，需要多个 Redis 的操作，如果业务数据写次数远大于读次数那么就没有必要使用 Redis。高速读/写的场合
在如今的互联网中，越来越多的存在高并发的情况，比如天猫双11、抢红包、抢演唱会门票等，这些场合都是在某一个瞬间或者是某一个短暂的时刻有成千上万的请求到达服务器，如果单纯的使用数据库来进行处理，就算不崩，也会很慢的，轻则造成用户体验极差用户量流失，重则数据库瘫痪，服务宕机，而这样的场合都是不允许的！
所以我们需要使用 Redis 来应对这样的高并发需求的场合，我们先来看看一次请求操作的流程图：
我们来进一步阐述这个过程：
- 当一个请求到达服务器时，只是把业务数据在 Redis
上进行读写，而没有对数据库进行任何的操作，这样就能大大提高读写的速度，从而满足高速响应的需求； - 但是这些缓存的数据仍然需要持久化，也就是存入数据库之中，所以在一个请求操作完 Redis
的读/写之后，会去判断该高速读/写的业务是否结束，这个判断通常会在秒杀商品为0，红包金额为0时成立，如果不成立，则不会操作数据库；如果成立，则触发事件将
Redis 的缓存的数据以批量的形式一次性写入数据库，从而完成持久化的工作。
4.使用redis有什么缺点
分析:大家用redis这么久，这个问题是必须要了解的，基本上使用redis都会碰到一些问题，常见的也就几个。
回答:主要是四个问题
- 缓存和数据库双写一致性问题
- 缓存雪崩问题
- 缓存击穿问题
- 缓存的并发竞争问题
4.Redis 为什么那么“快”
- 纯内存KV操作
- 内部是单线程实现的（不需要创建/销毁线程，避免上下文切换，无并发资源竞争的问题）
- 异步非阻塞的I/O（多路复用）
Redis使用单线程，相比于多线程快在哪里？
Redis的瓶颈不在线程，不在获取CPU的资源，所以如果使用多线程就会带来多余的资源占用。比如上下文切换、资源竞争、锁的操作。
上下文的切换
上下文其实不难理解，它就是CPU寄存器和程序计数器。主要的作用就是存放没有被分配到资源的线程，多线程操作的时候，不是每一个线程都能够直接获取到CPU资源的，我们之所以能够看到我们电脑上能够运行很多的程序，是应为多线程的执行和CPU不断对多线程的切换。但是总有线程获取到资源，也总有线程需要等待获取资源，这个时候，等待获取资源的线程就需要被挂起，也就是我们的寄存。这个时候我们的上下文就产生了，当我们的上下文再次被唤起，得到资源的时候，就是我们上下文的切换。
竞争资源
竞争资源相对来说比较好理解，CPU对上下文的切换其实就是一种资源分批，但是在切换之前，到底切换到哪一个上下文，就是资源竞争的开始。在我redis中由于是单线程的，所以所有的操作都不会涉及到资源的竞争。
锁的消耗
对于多线程的情况来讲，不能回避的就是锁的问题。如果说多线程操作出现并发，有可能导致数据不一致，或者操作达不到预期的效果。这个时候我们就需要锁来解决这些问题。当我们的线程很多的时候，就需要不断的加锁，释放锁，该操作就会消耗掉我们很多的时间
I/O复用，非阻塞模型
对于I/O阻塞可能有很多人不知道，I/O操作的阻塞到底是怎么引起的，Redis又是怎么解决的呢？
I/O操作的阻塞：当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
Redis采用多路复用：I/O 多路复用其实是在单个线程中通过记录跟踪每一个sock（I/O流） 的状态来管理多个I/O流。select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。
5.缓存穿透、缓存击穿、缓存雪崩
缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
缓存穿透解决方案
有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时先用布隆过滤器验证是key否存在，如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少。
另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
缓存击穿：key对应的数据存在，但在redis中过期了，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存击穿解决方案
key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。
1.使用互斥锁
当同个业务不同线程访问redis未命中时，先获取一把互斥锁，然后进行数据库操作，此时另外一个线程未命中时，拿不到锁，等待一段时间后重新查询缓存，此时之前的线程已经重新把数据加载到redis之中了，线程二就直接缓存命中。这样就不会使得大量访问进入数据库
2.设置热点数据永不过期
缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
缓存雪崩解决方案：
- 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
- 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
- 设置热点数据永远不过期。
6.Redis的过期策略和内存淘汰机制**
过期策略
我们set key的时候，都可以给一个expire time，就是过期时间，指定这个key比如说只能存活1个小时，我们自己可以指定缓存到期就失效。
如果假设你设置一个一批key只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？
答案是：定期删除+惰性删除
定期删除：
指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
注意：这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。
实际上redis是每隔100ms随机抽取一些key来检查和删除的。
但是，定期删除可能会导致很多过期key到了时间并没有被删除掉，所以就得靠惰性删除了。
惰性删除：
这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。
并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下
通过上述两种手段结合起来，保证过期的key一定会被干掉。
注意：但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？
如果大量过期key堆积在内存里，导致redis内存块耗尽了，怎么办？
答案是：走内存淘汰机制。
7.Redis内存淘汰机制
内存淘汰机制就能保证在redis内存占用过高的时候，去进行内存淘汰，也就是删除一部分key，保证redis的内存占用率不会过高，那么它会淘汰哪些key呢？Redis目前共提供了8种内存淘汰策略，含Redis 4.0版本之后又新增的两种LFU模式：volatile-lfu和allkeys-lfu。
no-eviction | 当内存不足以容纳新写入数据时，新写入操作会报错，无法写入新数据，一般不采用。 |
allkeys-lru | 当内存不足以容纳新写入数据时，移除最近最少使用的key，这个是最常用的 |
allkeys-random | 当内存不足以容纳新写入的数据时，随机移除key |
allkeys-lfu | 当内存不足以容纳新写入数据时，移除最不经常（最少）使用的key |
volatile-lru | 当内存不足以容纳新写入数据时，在设置了过期时间的key中，移除最近最少使用的key。 |
volatile-random | 内存不足以容纳新写入数据时，在设置了过期时间的key中，随机移除某个key 。 |
volatile-lfu | 当内存不足以容纳新写入数据时，在设置了过期时间的key中，移除最不经常（最少）使用的key |
volatile-ttl | 当内存不足以容纳新写入数据时，在设置了过期时间的key中，优先移除过期时间最早（剩余存活时间最短）的key。 |
LRU数据淘汰机制是这样的：在数据集中随机挑选几个键值对，去除其中最近最少使用的键值对淘汰。所以Redis并不是保证取得所有数据集中最少最少使用的键值对，而只是在随机挑选的几个键值对中
什么时候会执行内存淘汰策略，内存占用率过高的标准是什么？
redis.conf配置文件中的 maxmemory 属性限定了 Redis 最大内存使用量，当占用内存大于maxmemory的配置值时会执行内存淘汰策略。
内存淘汰策略的配置
内存淘汰机制由redis.conf配置文件中的maxmemory-policy属性设置，没有配置时默认为no-eviction模式。
淘汰策略的执行过程
客户端执行一条命令，导致Redis需要增加数据（比如set key value）；Redis会检查内存使用情况，如果内存使用超过 maxmemory，就会按照配置的置换策略maxmemory-policy删除一些key；再执行新的数据的set操作；
8.Redis的zset底层数据结构，为什么用跳跃表而不用红黑树
zset底层存储结构
zset底层的存储结构包括ziplist或skiplist，在同时满足以下两个条件的时候使用ziplist，其他时候使用skiplist，两个条件如下：
- 有序集合保存的元素数量小于128个
- 有序集合保存的所有元素的长度小于64字节
当ziplist作为zset的底层存储结构时候，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个元素保存元素的分值。
当skiplist作为zset的底层存储结构的时候，使用skiplist按序保存元素及分值，使用dict来保存元素和分值的映射关系。
ziplist数据结构
ziplist作为zset的存储结构时，格式如下图，细节就不多说了，我估计大家都看得懂，紧挨着的是元素memeber和分值socore，整体数据是有序格式。
满足条件：
- [score,value]键值对数量少于128个；
- 每个元素的长度小于64字节；
zset ziplist结构:
skiplist（跳跃表）数据结构
skiplist作为zset的存储结构，整体存储结构如下图，核心点主要是包括一个dict对象和一个skiplist对象。dict保存key/value，key为元素，value为分值；skiplist保存的有序的元素列表，每个元素包括元素和分值。两种数据结构下的元素指向相同的位置。
不满足ziplist的两个条件时使用跳表、组合了hash和skipList（跳跃表）
- hash用来存储value到score的映射，这样就可以在O(1)时间内找到value对应的分数；
- skipList按照从小到大的顺序存储分数
- skipList每个元素的值都是[socre,value]对
使用跳表时的示意图：
zset skiplist结构：
更详细的可以参考以下文章：https://www.jianshu.com/p/dc252b5efca6
Redis只在两个地方用到了跳跃表，一个是实现有序集合键(zset)，另一个是在集群节点中用作内部数据结构，除此之外，跳表在Redis里面没有其他用途。
但是为什么用跳表而不用红黑树呢？猜想如下：
- 在做范围查找的时候，平衡树比skiplist操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就非常简单，只需要在找到小值之后，对第1层链表进行若干步的遍历就可以实现。
- 平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而skiplist的插入和删除只需要修改相邻节点的指针，操作简单又快速。
- 从内存占用上来说，skiplist比平衡树更灵活一些。一般来说，平衡树每个节点包含2个指针（分别指向左右子树），而skiplist每个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。如果像Redis里的实现一样，取p=1/4，那么平均每个节点包含1.33个指针，比平衡树更有优势。
- 查找单个key，skiplist和平衡树的时间复杂度都为O(logn)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近O(1)，性能更高一些。所以我们平常使用的各种Map或dictionary结构，大都是基于哈希表实现的。
- 从算法实现难度上来比较，skiplist比平衡树要简单得多。
结合书籍《redis设计与实现(第二版)》里面的一段描述进行理解：
Redis 为什么那么“快”
纯内存KV操作
内部是单线程实现的（不需要创建/销毁线程，避免上下文切换，无并发资源竞争的问题）
异步非阻塞的I/O（多路复用）
Redis使用单线程，相比于多线程快在哪里？
Redis的瓶颈不在线程，不在获取CPU的资源，所以如果使用多线程就会带来多余的资源占用。比如上下文切换、资源竞争、锁的操作。
上下文的切换
上下文其实不难理解，它就是CPU寄存器和程序计数器。主要的作用就是存放没有被分配到资源的线程，多线程操作的时候，不是每一个线程都能够直接获取到CPU资源的，我们之所以能够看到我们电脑上能够运行很多的程序，是应为多线程的执行和CPU不断对多线程的切换。但是总有线程获取到资源，也总有线程需要等待获取资源，这个时候，等待获取资源的线程就需要被挂起，也就是我们的寄存。这个时候我们的上下文就产生了，当我们的上下文再次被唤起，得到资源的时候，就是我们上下文的切换。
竞争资源
竞争资源相对来说比较好理解，CPU对上下文的切换其实就是一种资源分批，但是在切换之前，到底切换到哪一个上下文，就是资源竞争的开始。在我redis中由于是单线程的，所以所有的操作都不会涉及到资源的竞争。
锁的消耗
对于多线程的情况来讲，不能回避的就是锁的问题。如果说多线程操作出现并发，有可能导致数据不一致，或者操作达不到预期的效果。这个时候我们就需要锁来解决这些问题。当我们的线程很多的时候，就需要不断的加锁，释放锁，该操作就会消耗掉我们很多的时间
I/O复用，非阻塞模型
对于I/O阻塞可能有很多人不知道，I/O操作的阻塞到底是怎么引起的，Redis又是怎么解决的呢？
I/O操作的阻塞：当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
Redis采用多路复用：I/O 多路复用其实是在单个线程中通过记录跟踪每一个sock（I/O流） 的状态来管理多个I/O流。select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。
使用Redis的时候要注意什么？
1、实体类要实现序列化接口，否在无法存入Redis数据库
2、application里的database配置成0，因为redis没有数据库的概念，整个就是一个大的数据库
3、往redis里面存东西的时候，会默认在每个值前面加一串字符，想要知道那一串字符是什么，可以用“keys *实体名”命令，这是redis的序列化操作，但是取的时候会自动反序列化，所以不影响
4、list类型往左边开始存的时候，，取值的时候也是从左边开始取，所以这时候相当于一个栈
SpringBoot整合Redis
String
List
Set
结果
key的值可以一样，但是value的值不允许重复Zset
Hash
Redis持久化
Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数 据恢复。理解掌握持久化机制对于Redis运维非常重要
RDB持久化
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，将某一时刻的数据持久化到磁盘中，它恢复时是将快照文件直接读到内存里，触发RDB持久化过程分为手动触发和自动触发
RDB的优缺点
Redis加载RDB恢复数据远远快于AOF的方式
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效
RDB的缺点是最后一次持久化后的数据可能丢失，Redis意外宕机,可能会丢失几分钟的数据（取决于配置的save时间点）
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题
1）触发机制
手动触发分别对应save和bgsave命令
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
2）自动触发RDB的持久
使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave
针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决
AOF持久化
AOF（append only file）持久化：以独立日志的方式记录每次写命令，AOF方式是将执行过的写指令记录下来，在数据恢复时按照丛前到后的顺序再将指令执行一遍。 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据
1）使用AOF
开启AOF功能需要设置配置：appendonly yes，默认不开启。通过appendfsync参数可以控制实时/秒级持久化。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）
AOF重写过程可以手动触发和自动触发：
·手动触发：直接调用bgrewriteaof命令。
·自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。
·auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。
自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage
其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。
AOF的缺点：
对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大，恢复速度慢；
以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来
本章重点回顾
1）Redis提供了两种持久化方式：RDB和AOF。
2）RDB使用一次性生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。
3）save命令会阻塞主线程不建议使用，bgsave命令通过fork操作创建子 进程生成RDB避免阻塞。
4）AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以 控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。
5）AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewritepercentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。
6）子进程执行期间使用copy-on-write机制与父进程共享内存，避免内 存消耗翻倍。AOF重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。
7）持久化阻塞主线程场景有：fork阻塞和AOF追加阻塞。fork阻塞时间 跟内存量和系统有关，AOF追加阻塞说明硬盘资源紧张。
8）单机下部署多个实例时，为了防止出现多个子进程执行重写操作， 建议做隔离控制，避免CPU和IO资源竞争。
缓存和数据库双写一致性问题
双写一致性有以下三个要求：
缓存不能读到脏数据
缓存可能会读到过期数据，但要在可容忍时间内实现最终一致
这个可容忍时间尽可能的小
要想同时满足上面三条，可以采用读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况。但是，串行化之后，就会导致系统的吞吐量会大幅度的降低，要用比正常情况下多几倍的机器去支撑线上请求。
双写串行化
所以，在这里，我们讨论三种常见方法：
先更新数据库，再更新缓存
先删除缓存，再更新数据库
先更新数据库，再删除缓存
- 先更新数据库，再更新缓存
这种方法是大家普遍反对的，原因集中在下面两点：
原因1：线程安全角度。
同时有请求A和请求B进行更新操作，那么会出现:
线程A更新了数据库
线程B更新了数据库
线程B更新了缓存
线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
"先更新缓存，再更新数据库"这种方案同理，也是造成脏数据，所以不被考虑
原因2：业务场景角度。
有如下两点：
如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致数据压根还没读到，缓存就被频繁的更新，浪费性能。
如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
如果一定要更新缓存，可以考虑给缓存数据增加版本号
为什么要删除缓存
- 先删除缓存，再更新数据库
该方案同样会导致不一致。同时有请求A和请求B进行更新操作，那么会出现:
请求A进行写操作，删除缓存
请求B查询发现缓存不存在
请求B去数据库查询得到旧值
请求B将旧值写入缓存
请求A将新值写入数据库上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
先删除后更新
解决方法：
先删除缓存
再写数据库(这两步和原来一样)
休眠一定时间（例如1秒或200ms），再次删除缓存。这么做，可以将缓存脏数据再次删除。
然而这种解决方案由于要休眠线程还是很影响吞吐量的
- 先更新数据库，再删除缓存
这种方案是很多工程采用的方案，我们来看下是否一定安全。
假设有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
缓存刚好失效
请求A查询数据库，得一个旧值
请求B将新值写入数据库
请求B删除缓存
请求A将查到的旧值写入缓存
这样，脏数据就产生了，然而上面的情况是假设在数据库写请求比读请求还要快。实际上，工程中数据库的读操作的速度远快于写操作的。
要么通过2PC或是Paxos协议保证一致性，要么就是想尽办法降低并发时脏数据的概率，大概是因为2PC太慢，而Paxos又太复杂，综合考虑，Facebook选择了这个第三种方案。
如果删除缓存失败了怎么办？
启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
删除缓存重试
阿里开源的中间件canal可以完成订阅binlog日志的功能。
最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库，然后再删除缓存。
redis在配置文件application.yml中的配置：
//一般需要配置以下属性
redis:
host: 127.0.0.1
port: 6379
password:
connect-timeout: 30000//SpringCloud项目里需要配置的
redis:
host: ${REDIS_HOST:127.0.0.1}
port: ${REDIS_PORT:8080}
jedis:
pool:
min-idle: 20
max-idle: 30
max-active: 40
redisson:
config: |
singleServerConfig:
address: "redis://${REDIS_HOST:127.0.0.1}:${REDIS_PORT:8080}"
codec: !<org.redisson.codec.JsonJacksonCodec> {}
password:redis配置文件
RedisConfig.java
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;
//记得一定要有配置的注释
@Configuration
public class RedisConfig {
/**
* 实例化 RedisTemplate 对象
* 提供给 RedisUtil 使用
*/
@Bean
public RedisTemplate<String, Object> RedisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
initRedisTemplate(redisTemplate, redisConnectionFactory);
return redisTemplate;
}
/**
* 设置数据存入 redis 的序列化方式,并开启事务
*
*/
private void initRedisTemplate(RedisTemplate<String, Object> redisTemplate, RedisConnectionFactory factory) {
//如果不配置Serializer，那么存储的时候缺省使用String，如果用User类型存储，那么会提示错误User can't cast to String！
redisTemplate.setKeySerializer(new StringRedisSerializer());
redisTemplate.setHashKeySerializer(new StringRedisSerializer());
redisTemplate.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
// 开启事务
redisTemplate.setEnableTransactionSupport(true);
redisTemplate.setConnectionFactory(factory);
}
/**
* 注入封装RedisTemplate 给RedisUtil提供操作类
*/
@Bean(name = "redisUtil")
public RedisUtil redisUtil(RedisTemplate<String, Object> redisTemplate) {
RedisUtil redisUtil = new RedisUtil();
redisUtil.setRedisTemplate(redisTemplate);
return redisUtil;
}
}redis工具类
RedisUtil .java
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.util.CollectionUtils;
import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.TimeUnit;
/**
*@Description: redis工具类
*/
public class RedisUtil {
private static RedisTemplate<String, Object> redisTemplate;
public void setRedisTemplate(RedisTemplate<String, Object> redisTemplate) {
this.redisTemplate = redisTemplate;
}
//=============================common============================
/**
* 指定缓存失效时间
* @param key 键
* @param time 时间(秒)
* @return
*/
public boolean expire(String key,long time){
try {
if(time>0){
redisTemplate.expire(key, time, TimeUnit.SECONDS);
}
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 根据key 获取过期时间
* @param key 键 不能为null
* @return 时间(秒) 返回0代表为永久有效
*/
public long getExpire(String key){
return redisTemplate.getExpire(key,TimeUnit.SECONDS);
}
/**
* 判断key是否存在
* @param key 键
* @return true 存在 false不存在
*/
public boolean hasKey(String key){
try {
return redisTemplate.hasKey(key);
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 删除缓存
* @param key 可以传一个值 或多个
*/
@SuppressWarnings("unchecked")
public void del(String ... key){
if(key!=null&&key.length>0){
if(key.length==1){
redisTemplate.delete(key[0]);
}else{
redisTemplate.delete((Collection<String>) CollectionUtils.arrayToList(key));
}
}
}
//============================String=============================
/**
* 普通缓存获取
* @param key 键
* @return 值
*/
public Object get(String key){
return key==null?null:redisTemplate.opsForValue().get(key);
}
/**
* 普通缓存放入
* @param key 键
* @param value 值
* @return true成功 false失败
*/
public boolean set(String key,Object value) {
try {
redisTemplate.opsForValue().set(key, value);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 普通缓存放入并设置时间
* @param key 键
* @param value 值
* @param time 时间(秒) time要大于0 如果time小于等于0 将设置无限期
* @return true成功 false 失败
*/
public boolean set(String key,Object value,long time){
try {
if(time>0){
redisTemplate.opsForValue().set(key, value, time, TimeUnit.SECONDS);
}else{
set(key, value);
}
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 递增
* @param key 键
* @param delta 要增加几(大于0)
* @return
*/
public long incr(String key, long delta){
if(delta<0){
throw new RuntimeException("递增因子必须大于0");
}
return redisTemplate.opsForValue().increment(key, delta);
}
/**
* 递减
* @param key 键
* @param delta 要减少几(小于0)
* @return
*/
public long decr(String key, long delta){
if(delta<0){
throw new RuntimeException("递减因子必须大于0");
}
return redisTemplate.opsForValue().increment(key, -delta);
}
//================================Map=================================
/**
* HashGet
* @param key 键 不能为null
* @param item 项 不能为null
* @return 值
*/
public Object hget(String key,String item){
return redisTemplate.opsForHash().get(key, item);
}
/**
* 获取hashKey对应的所有键值
* @param key 键
* @return 对应的多个键值
*/
public Map<Object,Object> hmget(String key){
return redisTemplate.opsForHash().entries(key);
}
/**
* HashSet
* @param key 键
* @param map 对应多个键值
* @return true 成功 false 失败
*/
public boolean hmset(String key, Map<String,Object> map){
try {
redisTemplate.opsForHash().putAll(key, map);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* HashSet 并设置时间
* @param key 键
* @param map 对应多个键值
* @param time 时间(秒)
* @return true成功 false失败
*/
public boolean hmset(String key, Map<String,Object> map, long time){
try {
redisTemplate.opsForHash().putAll(key, map);
if(time>0){
expire(key, time);
}
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 向一张hash表中放入数据,如果不存在将创建
* @param key 键
* @param item 项
* @param value 值
* @return true 成功 false失败
*/
public boolean hset(String key,String item,Object value) {
try {
redisTemplate.opsForHash().put(key, item, value);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 向一张hash表中放入数据,如果不存在将创建
* @param key 键
* @param item 项
* @param value 值
* @param time 时间(秒) 注意:如果已存在的hash表有时间,这里将会替换原有的时间
* @return true 成功 false失败
*/
public boolean hset(String key,String item,Object value,long time) {
try {
redisTemplate.opsForHash().put(key, item, value);
if(time>0){
expire(key, time);
}
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 删除hash表中的值
* @param key 键 不能为null
* @param item 项 可以使多个 不能为null
*/
public void hdel(String key, Object... item){
redisTemplate.opsForHash().delete(key,item);
}
/**
* 判断hash表中是否有该项的值
* @param key 键 不能为null
* @param item 项 不能为null
* @return true 存在 false不存在
*/
public boolean hHasKey(String key, String item){
return redisTemplate.opsForHash().hasKey(key, item);
}
/**
* hash递增 如果不存在,就会创建一个 并把新增后的值返回
* @param key 键
* @param item 项
* @param by 要增加几(大于0)
* @return
*/
public double hincr(String key, String item,double by){
return redisTemplate.opsForHash().increment(key, item, by);
}
/**
* hash递减
* @param key 键
* @param item 项
* @param by 要减少记(小于0)
* @return
*/
public double hdecr(String key, String item,double by){
return redisTemplate.opsForHash().increment(key, item,-by);
}
//============================set=============================
/**
* 根据key获取Set中的所有值
* @param key 键
* @return
*/
public Set<Object> sGet(String key){
try {
return redisTemplate.opsForSet().members(key);
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
/**
* 根据value从一个set中查询,是否存在
* @param key 键
* @param value 值
* @return true 存在 false不存在
*/
public boolean sHasKey(String key,Object value){
try {
return redisTemplate.opsForSet().isMember(key, value);
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 将数据放入set缓存
* @param key 键
* @param values 值 可以是多个
* @return 成功个数
*/
public long sSet(String key, Object...values) {
try {
return redisTemplate.opsForSet().add(key, values);
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
/**
* 将set数据放入缓存
* @param key 键
* @param time 时间(秒)
* @param values 值 可以是多个
* @return 成功个数
*/
public long sSetAndTime(String key,long time,Object...values) {
try {
Long count = redisTemplate.opsForSet().add(key, values);
if(time>0)
{expire(key, time);}
return count;
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
/**
* 获取set缓存的长度
* @param key 键
* @return
*/
public long sGetSetSize(String key){
try {
return redisTemplate.opsForSet().size(key);
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
/**
* 移除值为value的
* @param key 键
* @param values 值 可以是多个
* @return 移除的个数
*/
public long setRemove(String key, Object ...values) {
try {
Long count = redisTemplate.opsForSet().remove(key, values);
return count;
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
//===============================list=================================
/**
* 获取list缓存的内容
* @param key 键
* @param start 开始
* @param end 结束 0 到 -1代表所有值
* @return
*/
public List<Object> lGet(String key, long start, long end){
try {
return redisTemplate.opsForList().range(key, start, end);
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
/**
* 获取list缓存的长度
* @param key 键
* @return
*/
public long lGetListSize(String key){
try {
return redisTemplate.opsForList().size(key);
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
/**
* 通过索引 获取list中的值
* @param key 键
* @param index 索引 index>=0时， 0 表头，1 第二个元素，依次类推；index<0时，-1，表尾，-2倒数第二个元素，依次类推
* @return
*/
public Object lGetIndex(String key,long index){
try {
return redisTemplate.opsForList().index(key, index);
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
/**
* 将list放入缓存
* @param key 键
* @param value 值
* @return
*/
public boolean lSet(String key, Object value) {
try {
redisTemplate.opsForList().rightPush(key, value);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 将list放入缓存
* @param key 键
* @param value 值
* @param time 时间(秒)
* @return
*/
public boolean lSet(String key, Object value, long time) {
try {
redisTemplate.opsForList().rightPush(key, value);
if (time > 0)
{expire(key, time);}
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 将list放入缓存
* @param key 键
* @param value 值
* @return
*/
public boolean lSet(String key, List<Object> value) {
try {
redisTemplate.opsForList().rightPushAll(key, value);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 将list放入缓存
* @param key 键
* @param value 值
* @param time 时间(秒)
* @return
*/
public boolean lSet(String key, List<Object> value, long time) {
try {
redisTemplate.opsForList().rightPushAll(key, value);
if (time > 0) expire(key, time);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 根据索引修改list中的某条数据
* @param key 键
* @param index 索引
* @param value 值
* @return
*/
public boolean lUpdateIndex(String key, long index,Object value) {
try {
redisTemplate.opsForList().set(key, index, value);
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
/**
* 移除N个值为value
* @param key 键
* @param count 移除多少个
* @param value 值
* @return 移除的个数
*/
public long lRemove(String key,long count,Object value) {
try {
Long remove = redisTemplate.opsForList().remove(key, count, value);
return remove;
} catch (Exception e) {
e.printStackTrace();
return 0;
}
}
}使用方法：
//存入
redisUtil.set("key","这里是存入的值");
//设置存储的时间 秒
redisUtil.expire("key",20);
//读取数据
redisUtil.get("key");SPRingBoot项目使用redis：
SpringBoot——Redis的使用
Redis存储一个对象
方式一：将对象转化为JSON字符串存入redis
创建一个Jedis实例
package com.xiateng.util;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
/**
* jedis获取工具类
*/
public class JedisUtil {
private static JedisPool jedisPool;
private static final Logger logger = LoggerFactory.getLogger(JedisUtil.class);
static {
// 初始化连接池
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(20);
jedisPoolConfig.setMaxIdle(10);
jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379);
logger.info("jedisPool连接池初始化====" + jedisPool);
}
/**
* 获取一个Jedis实例
* @return
*/
public synchronized static Jedis getJedis(){
Jedis jedis = jedisPool.getResource();
// jedis.auth("123456");//密码
return jedis;
}
}Jedis jedis = JedisUtil.getJedis();
TUser tUser = new TUser();
tUser.setUserName("你好");
tUser.setPassword("2342342");
jedis.set("xiateng", JSON.toJSONString(tUser));
String sss = jedis.get("xiateng");
TUser ssss = JSON.parseObject(sss,TUser.class);
jedis.del("xiateng");
System.out.println("---------------------------: "+ssss.toString());方式二：将对象序列化后存到redis
封装序列化跟反序列化方法
package com.xiateng.util;
import java.io.*;
public class SerializeUtil {
/**
* 序列化操作
* @param object
* @return
*/
public static byte[] serialize(Object object){
ObjectOutputStream oos = null;
ByteArrayOutputStream baos = null;
try {
// 序列化
baos = new ByteArrayOutputStream();
oos = new ObjectOutputStream(baos);
oos.writeObject(object);
byte[] bytes = baos.toByteArray();
return bytes;
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
/**
* 反序列化操作
* @param bytes
* @return
*/
public static Object unSerialize(byte[] bytes){
ByteArrayInputStream bais = null;
try {
bais = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new ObjectInputStream(bais);
return ois.readObject();
} catch (IOException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return null;
}
}Jedis jedis = JedisUtil.getJedis();
jedis.set("code".getBytes(), SerializeUtil.serialize(tUser));
byte[] bytes = jedis.get("code".getBytes());
TUser o = (TUser)SerializeUtil.unSerialize(bytes);
jedis.del("code");
System.out.println(o.toString());方式三：将对象用Hash数据类型存储
Jedis jedis = JedisUtil.getJedis();
jedis.hset("user", "id", "3");
jedis.hset("user", "name", "xiateng");
jedis.hset("user", "password", "123455");
jedis.hget("user","id");
List<String> user = jedis.hmget("user", new String[]{"id","name","password"});
System.out.println("---------------------------: "+user);
// 输出结果 [3,xiateng,123455]redis单机、哨兵、集群模式的对比
单机版
生成环境不建议使用，有单点故障风险。一旦单台结点出现故障，可能会导致整个服务不可用
sentinal哨兵模式
另外引入一台结点redis sentinal（哨兵），会与其他的redis结点保持长连接（心跳机制），它实时地感应到其他redis结点的状态，客户端进行访问时，会向redis sentinal询问可用的redis服务结点，redis sentinal会返回可用的redis结点的信息。客户端获取到信息后再去访问对应的redis结点，并且会将连接信息保存到本地。
当可用的redis结点信息发生变化的时候，redis sentinal会调整对应的结点关系（主从关系），然后向客户端发送一个change通知，告诉它redis结点发生变化，客户端就会重新想redis sentinal发送请求获取新的结点信息。
当redis结点中有多个主从复制，客户端如何知道何时将请求发给哪个master呢？
客户端本地维护了一个分片机制，它通过redis sentinal明确地知道有两个master结点，通过对master机器的IP值进行hash，将数据按照不同的策略路由到不同的master结点。
它有一些缺点：
- 它需要在客户端做比较复杂的分片逻辑。增加了客户端与redis结点之间的耦合
- 随着业务的发展，我们以前定义的redis结点不够用的需要新增redis结点的时候，会设计到数据迁移的过程，这个过程是比较繁琐的。
集群cluster模式
多个redis结点，redis会自动竞选出master和slave结点，并且集群中的每个redis都和其他多台redis有网状结构，redis能清晰地直到我的主/从是谁，我们其他分片的主从信息，也就是每个redis结点中都有维护整个集群结构的信息，这都是基于redis-cluster的数据同步和paxos的竞争算法来实现的。
当客户端访问其中的一个结点时，就能获取整个集群结点的信息，并保存到本地。若有结点宕机，集群会自动进行调整更新信息，然后每个结点维护一份新的信息，此时客户端按照旧的集群信息访问到一个不属于新的集群管理范围的key的时候，redis会发送一个reask请求，通知客户端获取新的集群信息
当redis4宕机后，redis会发送一个reask请求，通知客户端获取新的集群信息
集中模式对比
- 生产环境中不要使用单机版
- 哨兵模式是由客户端本地来维护redis结点之间的信息，而集群模式是由结点来维护所有结点之间的连接关系
- sentinal哨兵模式存在缺陷，在水平拓展redis结点的情况下，需要客户端在本地维护分片机制（客户端与redis结点之间存在耦合），并且如果此时需要再继续进行拓展，那么就会有一个数据迁移的过程，这个过程是繁琐的。
- 而集群模式却不需要客户端来进行分片机制的维护，并且每个客户端中都维护了整个集群网络的信息，进行客户端与redis集群之间的解耦，并且更加易于拓展。
redis主从哨兵和集群的区别
架构不同
redis主从：一主多从；
redis集群：多主多从；
存储不同
redis主从：主节点和从节点都是存储所有数据；
redis集群：数据的存储是通过hash计算16384的槽位，算出要将数据存储的节点，然后进行存储；
选举不同
redis主从：通过启动redis自带的哨兵（sentinel）集群进行选举，也可以是一个哨兵
选举流程：1、先发现主节点fail的哨兵，将成为哨兵中的leader，之后的主节点选举将通过这个leader进行故障转移操作，从存活的slave中选举新的master，新 的master选举同集群的master节点选举类似；
redis集群：集群可以自己进行选举
选举流程：1、当主节点挂掉，从节点就会广播该主节点fail；
2、延迟时间后进行选举（延迟的时间算法为：延迟时间+随机数+rank*1000，从节点数据越多，rank越小，因为主从数据复制是异步进行的，所以 所有的从节点的数据可能会不同），延迟的原因是等待主节点fail广播到所有存活的主节点，否则主节点会拒绝参加选举；
3、参加选举的从节点向所有的存活的节点发送ack请求，但只有主节点会回复它，并且主节点只会回复第一个到达参加选举的从节点，一半以上的主节点回复，该节点就会成为主节点，广播告诉其他节点该节点成为主节点。
节点扩容不同
redis主从：只能扩容从节点，无法对主节点进行扩容；
redis集群：可以扩容整个主从节点，但是扩容后需要进行槽位的分片，否则无法进行数据写入，命令为：/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster reshard 192.168.0.61:8001，其中的192.168.0.61:8001为新加入的主从节点；
