redis|Redis 缓存|数据库|redis

Redis redis有哪些数据类型？
String，List，Set，Zset，Hash
持久化
什么是redis持久化？
持久化就是把内存的数据写到磁盘中，防止服务宕机了，导致内存数据丢失。
Redis的持久化机制是什么？
redis提供了两种持久化机制 RDB 和 AOF机制。

RDB：
redis默认的持久化方式，按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产出的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。
优点：
只有一个文件dump.rdb，方便持久化。
容灾性好，一个文件可以保存到安全的磁盘。
性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化，使用单独进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能。
相对于数据集大时，比AOF的启动效率更高。
缺点：
数据安全性低，RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。
AOF持久化方式：是指所有命令行记录以redis命令请求协议的格式完成持久化存储，保存为AOF文件。
AOF
AOF持久化，则是将redis的执行每次写命令记录到单独的日志文件中，当重启redis会重新将持久化的日志中文件恢复数据。
当两种方式同时开启时，数据恢复redis会优先选择AOF恢复。
优点：
数据安全，aof持久化可以配置appendfsync 属性，有always。每进行一次命令操作就记录到aof文件中一次。
通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof 工具解决数据一致性问题。
AOF机制的rewrite模式，AOF文件没被rewrite之前，可以删除其中的某些命令。
缺点：
AOF文件比RDB文件大，且恢复速度慢。
数据集大的时候，比rdb启动效率低。

两个持久性方式的区别：

AOF文件比RDB更新频率高，优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配了优先加载AOF

内存相关
redis中数据如何保证都是热点数据？
redis内存数据集大熊啊上升到一定大小的时候，就会实行数据淘汰策略。
redis内存淘汰策略
全局的见空间选择性移除

noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

设置过期时间的键空间选择性移除：

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

redis事务
redis集群
哨兵模式

文章图片

哨兵模式主要是用于实现redis集群的高可用。

集群监控：负责监控redis master 和 slave 进程是否正常工作。
消息通知：如果redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员，
故障转移：如果master node 挂掉，会自动转移到 slave node上。
配置中心：如果故障转移发生了，通知client客服端新的 master地址。

核心：

哨兵至少需要3个实例，保证自己的健壮性。
哨兵+redis 主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性。

Redis Cluster redis cluster 是一种服务端Sharding技术，3.0版本开始正式提供。redis cluster并没有使用一致性hash，而是采用slot的概念，一种分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。
方案说明：

通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分赔了16384个槽位。
每份数据分片会存储在多个互为主从的多节点上。
数据写入先写主节点，在同步到从节点(支持配置为阻塞同步)
同一分片多个节点间的数据不保持一致性。
读取数据时，当客服端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
扩容时需要把就节点数据迁移的一部分到新节点。

分布式寻址算法

hash算法
一致性hash算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
redis cluster 的 hash slot 算法

Redis主从架构对于缓存来说，一般都是用来支撑读高并发的，因此架构做成主从架构，一主多从，主负责写，并且将数据复制到其他的slave节点，从节点负责读。所有的读请求全部走从节点。轻松实现水平扩容，支撑读高并发。
redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发、
redis主从复制的核心原理
当启动一个从节点的时候，他会发送一个PSYNC 命令给主节点。
如果这是从节点初次连接到主节点，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件。
同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，
接着master会将内存中缓存的写命令发送到slave，slave也会同步这些数据。

文章图片

过程原理

当从库和主库建立MS关系后，会向主数据库发送SYNC命令
主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来
当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis
从Redis接收到后，会载入快照文件并且执行收到的缓存的命令
之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致

redis集群会有写操作丢失吗？因为redis不能保证数据的强一致性，所以会存在丢失写操作。
Redis是单线程的，如何提高多核CPU的利用率？可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的，所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。
分布式锁 redis为单进程单线程模式，采用队列模式将并发访问编程串行访问，且多客服端对redis的连接并不存在竞争关系，Redis中可以使用SETNX命令实现分布式锁。
使用SETNX完成同步锁的流程：
使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功
为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间
释放锁，使用DEL命令将锁数据删除
什么是 RedLock Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：

安全特性：互斥访问，即永远只有一个 client 能拿到锁
避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
容错性：只要大部分 Redis 节点存活就可以正常提供服务

缓存异常
缓存雪崩缓存雪崩是指缓存同一时间大面积的失效，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：

缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
一般并发量不是特别多的时候，使用最多的解决方案时加锁排队。
给每个缓存数据增加相应的缓存标记，记录缓存是否失效，如果缓存标记失效，则更新数据缓存。

缓存穿透缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：

接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截。
从缓存取不到，在数据库中也没有取到的数据，可以将key-value对写为key-null，缓存有效时间可以设置短一点。这样可以防止攻击用户反复用同一个id暴力攻击。
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

布隆过滤器
引入了k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。
他的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。
Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。
Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。
缓存击穿缓存击穿是指缓存中没有但数据库中存在的数据。这时由于并发用户特别多，同时都缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
解决方案：

设置热点数据永不过期
加互斥锁

缓存预热缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。
缓存热点key 【redis|Redis】缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。