聊聊Redis
Redis 为什么会这么快？
- 基于内存
- 单线程减少上下文切换，减少锁竞争，同时保证原子性
- IO多路复用
- 高级数据结构支持快速查询（如 SDS、Hash以及跳表等）
为什么Redis采用单线程模型？
官方答案：因为 Redis 是基于内存的操作，CPU 不会成为 Redis 的瓶颈，而最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。
redis的zset中的跳表？
跳表是一种随机化的数据结构，基于并联的链表，实现简单，插入、删除、查找的复杂度均为 O(logN)。简单说来跳表也是链表的一种，只不过它在链表的基础上增加了跳跃功能，正是这个跳跃的功能，使得在查找元素时，跳表能够提供 O(logN) 的时间复杂度。跳表为了避免每次插入或删除带来的额外操作，不要求上下相邻两层链表之间的节点个数有严格的对应关系，而是为每个节点随机出一个层数（level）。而且新插入一个节点不会影响其它节点的层数。因此，插入操作只需要修改插入节点前后的指针，而不需要对很多节点都进行调整。
跳表的随机概率，解释起来就是第n层的概率为0.25^ (n-1)。
redis为啥用跳表不用平衡树？
- 平衡树的插入和删除需要再平衡，会增大复杂度，影响更新效率
- 平衡树每个节点包含 2 个指针（分别指向左右子树），而跳表每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。
- 在范围查询中，平衡树如果不做改造，类似mysql b+树那样的改造，那么范围查询起来，会比较麻烦，定位到节点后，还得中序遍历继续找。
mysql为啥用b+树，不用跳表？
- 写入的效率其实是跳表高，b+树会差一些，这点忽略
- 主要是索引效率，b+树很平衡，2000w数据大概都三次的索引就能查到。而对于跳表2000w的数据等于24层索引，意味着某些数据最多需要24次的IO是我们不能接收的。磁盘IO太慢了，越少IO越好。
Redis的数据过期策略？
常见的过期策略有：
- 定时删除：在设置 key 的过期时间的同时，为该 key 创建一个定时器，让定时器在 key 的过期时间来临时，对 key 进行删除。
- 惰性删除：在获取key的时候实时去判断有没有过期，有就删除，并返回nil。
- 定期删除：每隔一段时间执行一次删除（在 redis.conf 配置文件设置，1s 刷新的频率）过期 key 操作。
如何解决Redis缓存穿透？
解释：缓存穿透是指查询一个根本不存在的数据，缓存层和持久层都不会命中，请求都会压到数据库，从而压垮数据库。
解决：
- 对空值缓存：如果一个查询返回的数据为空（不管数据是否存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
- 采用布隆过滤器：布隆过滤器（Bloom Filter）是由Howard Bloom在1970年提出的一种比较巧妙的概率型数据结构，它可以告诉你某种东西一定不存在或者可能存在。当布隆过滤器说，某种东西存在时，这种东西可能不存在；当布隆过滤器说，某种东西不存在时，那么这种东西一定不存在。 布隆过滤器相对于Set、Map 等数据结构来说，它可以更高效地插入和查询，并且占用空间更少，它也有缺点，就是判断某种东西是否存在时，可能会被误判。但是只要参数设置的合理，它的精确度也可以控制的相对精确，只会有小小的误判概率。
- 前置校验：一些认为一定不存在的值，可以直接过滤，比如uid是负数啥的情况。
如何解决Redis缓存击穿？
解释：key可能会在某些时间点被高并发访问，是一种非常热点的数据，这个时候，如果key突然过期，缓存被击穿，所有请求打垮数据库。
解决：
- 预热：在redis高峰访问前，把一些热门数据提前存入redis中，加大这些热门数据key的时长实时调整 现场监控哪些数据是热门数据，实时调整key的过期时长
- 加锁排队: 就是在缓存失效的时候（判断拿出来的值为空），不是立即去查数据库，而是先去竞争一个锁（可以是jvm锁也可以是分布式锁）。这样只有一个请求打到数据库，其他请求都会排队等候结果。这样避免数据库被打穿。
如何解决Redis缓存雪崩？
解释：缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决：
- 永不过期：热点数据永不过期
- 异步更新缓存过期时间：判断缓存在即将过期的时候如果有请求，那就异步更新过期时间
- 将缓存失效时间随机：设置缓存过期时间时加上一个随机值，避免缓存在同一时间过期
Redis使用姿势最佳实践是怎么样的?
- Cache-Aside：旁路缓存，这应该是最常见的缓存模式了。对于读，首先从缓存读取数据，如果没有命中则回源 SoR （system-of-record）读取并更新缓存。对于写操作，先写 SoR，再删缓存。
- Cache-As-SoR：缓存即数据源。读写操作都直接针对缓存，由缓存自己去维护和SoR的同步关系。这样可以异步合并/批量写，提高性能。比如维护秒杀库存。
redis和memecache的区别？
- memecache支持多核运行，redis单核运行，整体的性能优于redis。
- memecache数据结构单一，redis支持多种复杂数据结构list，set，hash。
- memecache纯缓存型kv数据库，掉电数据丢失，redis有持久化功能。
为什么Redis Cluster的Hash Slot 是16384？
我们知道一致性hash算法是2的16次方，为什么hash slot是2的14次方呢？
在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8],当槽位为65536时，这块的大小是:65536÷8÷1024=8kb，而16384÷8÷1024=2kb,主要就是心跳包是个频繁的操作，占用带宽越少越好。
redis锁的几种实现：
1. redis加锁分类
redis能用的的加锁命令分表是INCR、SETNX、SET
2. 第一种锁命令INCR
这种加锁的思路是， key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作进行加一。
然后其它用户在执行 INCR 操作进行加一时，如果返回的数大于 1 ，说明这个锁正在被使用当中。
1、 客户端A请求服务器获取key的值为1表示获取了锁
2、 客户端B也去请求服务器获取key的值为2表示获取锁失败
3、 客户端A执行代码完成，删除锁
4、 客户端B在等待一段时间后在去请求的时候获取key的值为1表示获取锁成功
5、 客户端B执行代码完成，删除锁
$redis->incr($key);
$redis->expire($key, $ttl); //设置生成时间为1秒
3. 第二种锁SETNX
这种加锁的思路是，如果 key 不存在，将 key 设置为 value 如果 key 已存在，则 SETNX 不做任何动作
1、 客户端A请求服务器设置key的值，如果设置成功就表示加锁成功
2、 客户端B也去请求服务器设置key的值，如果返回失败，那么就代表加锁失败
3、 客户端A执行代码完成，删除锁
4、 客户端B在等待一段时间后在去请求设置key的值，设置成功
5、 客户端B执行代码完成，删除锁
$redis->setNX($key, $value);
$redis->expire($key, $ttl);
4. 第三种锁SET
上面两种方法都有一个问题，会发现，都需要设置 key 过期。那么为什么要设置key过期呢？如果请求执行因为某些原因意外退出了，导致创建了锁但是没有删除锁，那么这个锁将一直存在，以至于以后缓存再也得不到更新。于是乎我们需要给锁加一个过期时间以防不测。
但是借助 Expire 来设置就不是原子性操作了。所以还可以通过事务来确保原子性，但是还是有些问题，所以官方就引用了另外一个，使用 SET 命令本身已经从版本 2.6.12 开始包含了设置过期时间的功能。
1、 客户端A请求服务器设置key的值，如果设置成功就表示加锁成功
2、 客户端B也去请求服务器设置key的值，如果返回失败，那么就代表加锁失败
3、 客户端A执行代码完成，删除锁
4、 客户端B在等待一段时间后在去请求设置key的值，设置成功
5、 客户端B执行代码完成，删除锁
$redis->set($key, $value, array('nx', 'ex' => $ttl)); //ex表示秒
5. 其它问题
虽然上面一步已经满足了我们的需求，但是还是要考虑其它问题？
- redis发现锁失败了要怎么办？中断请求还是循环请求？
- 循环请求的话，如果有一个获取了锁，其它的在去获取锁的时候，是不是容易发生抢锁的可能？
- 锁提前过期后，客户端A还没执行完，然后客户端B获取到了锁，这时候客户端A执行完了，会不会在删锁的时候把B的锁给删掉？
6. 解决办法
针对问题1：使用循环请求，循环请求去获取锁
针对问题2：针对第二个问题，在循环请求获取锁的时候，加入睡眠功能，等待几毫秒在执行循环
针对问题3：在加锁的时候存入的key是随机的。这样的话，每次在删除key的时候判断下存入的key里的value和自己存的是否一样
do { //针对问题1，使用循环
$timeout = 10;
$roomid = 10001;
$key = 'room_lock';
$value = 'room_'.$roomid; //分配一个随机的值针对问题3
$isLock = Redis::set($key, $value, 'ex', $timeout, 'nx');//ex 秒
if ($isLock) {
if (Redis::get($key) == $value) { //防止提前过期，误删其它请求创建的锁
//执行内部代码
Redis::del($key);
continue;//执行成功删除key并跳出循环
}
} else {
usleep(5000); //睡眠，降低抢锁频率，缓解redis压力，针对问题2
}
} while(!$isLock);
7. 另外一个锁
以上的锁完全满足了需求，但是官方另外还提供了一套加锁的算法，这里以PHP为例
$servers = [
['127.0.0.1', 6379, 0.01],
['127.0.0.1', 6389, 0.01],
['127.0.0.1', 6399, 0.01],
];
$redLock = new RedLock($servers);
//加锁
$lock = $redLock->lock('my_resource_name', 1000);
//删除锁
$redLock->unlock($lock)
上面是官方提供的一个加锁方法，就是和第6的大体方法一样，只不过官方写的更健壮。所以可以直接使用官方提供写好的类方法进行调用。官方提供了各种语言如何实现锁。
本文来自博客园，作者：LiJialong，转载请注明原文链接：https://www.cnblogs.com/carver/p/17115963.html
