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
缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
