redis相关知识点及面试点有哪些
这篇文章主要介绍了redis相关知识点及面试点有哪些的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇redis相关知识点及面试点有哪些文章都会有所收获，下面我们一起来看看吧。
四、Redis为什么这么快
1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4、使用多路I/O复用模型，非阻塞IO；
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
以上几点都比较好理解，下边我们针对多路 I/O 复用模型进行简单的探讨：
（1）多路 I/O 复用模型
多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
这里"多路"指的是多个网络连接，"复用"指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。
缓存穿透：缓存当中没有 数据库当中也没有
解决方法：缓存空对象 布隆过滤器
缓存空对象：如果redis中没有，数据库中也没查到，就在redis中填加一个这个key对应的空对象。下次判断的时候 如果在redis中查到这个空对象，就说明查询不到数据。缺点：会创造大量的空对象，并且还要设置过期时间。
布隆过滤器：
输入太白 进行三次hash 将得到的值标记为1 其他的以此类推 等以后找的时候也是三次hash 能找到就是可能存在 有一个找不到就是绝对不存在
如果你输入一个不存在的 但是三次hash都为1 还是可能存在的 这时候就属于误触了
误触率跟hash次数和长度有关 布隆过滤器缺点：需要维护 ；不能删除
redis底层保存的数据是位数组
点赞需求以及使用redis的解决思路。第一种点赞需求是比较常规的点赞需求，类似于微博那种点赞模式，用户可以对某条信息点赞、取消点赞、查询是否点赞、被点赞次数等等；第二种点赞稍微特殊，用户可以在一天内对任意用户点赞，取消点赞后不可以再次对同用户点赞，第二天限制解除，可以重新对同一玩家点赞（也就是说点赞是可以累加的），然后还有一个需求是要求可以实时查用户获赞次数全局的排行情况。
需求一解决思路
对于需求一，采用的是redis bitmap来实现。
bitmap简介
bitmap
bitmap是一连串的二进制数字(0,1)，每一位所在的位置为偏移(offset)，在bitmap上可以执行AND,OR,XOR以及其他操作。
位图计数
位图计数的意思是统计bitmap中值为1的位的个数，位图计数的效率是很高的。
redis bitmap
redis中允许使用二进制的Key和二进制的Value，bitmap就是二进制的Value。
点赞/取消点赞
假设用户的数字id为1000，对照片id为100的照片点赞。首先根据照片id生成赞数据存储的redis key，比如生成策略为like_photo:{photo_id}，id为1000的用户点赞，只需要将like_photo:100的第1000位置为1即可（取消赞则置为0）。
redis setbit操作的时间复杂度为O(1)，所以这种点赞方式十分高效。
123 | redis.setbit('like_photo:100', 1000, 1, function(err, ret){ // deal err and ret.}); |
当前是否点赞
用户打开图片的时候需要查询当前是否点赞过该照片，查询是否点赞可以通过redis getbit操作来实现。比如查询用户id为1000的用户是否点赞过照片id为100的照片，只需要对like_photo:100bitmap的第1000位取值即可。
redis getbit操作的时间复杂度同样是O(1)。
1234 | redis.getbit('like_photo:100', 1000, function(err, liked){ // deal err. // if liked==1 liked, liked==0 not like yet.}); |
查询点赞总次数
比如需要显示照片id为100的照片的获赞次数，只需要对like_photo:100bitmap进行位图计数操作即可。
redis bitcount操作的时间复杂度虽然是O(N)的，但是大部分数据量的情况下是不需要担心bitcount效率问题的。
123 | redis.bitcount('like_photo:100', function(err, likeCnt){ // deal with err and likeCnt.}); |
缓存击穿：数据库有数据 但是缓存中没数据或者缓存的数据恰好失效的时候 突然大量的访问过来 此时会访问数据造成数据库崩溃
解决方法 分布式锁
99个请求过来的时候 先放行一个进去 此时在redis中没有缓存 然后会新建一个 然后解锁 这时候剩下的98个就可以读到缓存了
缓存雪崩 大部分缓存失效 或者redis崩溃了
解决办法 搭建高可用集群 或者过期时间错开
如何保持数据库与缓存一致性
redis和mysql数据一致性的问题
在这里，我们讨论三种更新策略：
先更新缓存，再更新数据库
先更新数据库，再更新缓存
先删除缓存，再更新数据库
先更新数据库，再删除缓存
第一种，先更新缓存，再更新数据库
问题：更新缓存成功，更新数据库失败，导致数据不一致。
第二种，先更新数据库，再更新缓存
问题：
1、A更新数据库
2、B更新数据库
3、B写入缓存
4、A写入缓存
出现数据不一致。
考虑另一种情况， 有如下两点：
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
第三种，先删除缓存，再更新数据库。
问题：
1、A删除缓存
2、B查询数据库获取旧值
3、B更新了缓存
4、A更新数据库
出现数据不一致的问题
延时双删
public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(1000); redis.delKey(key);}问题一：延时双删，演变成了：先更新数据库，再删除缓存。。。。
比如：
1、A删除缓存
2、B查询数据库获取旧值
3、B更新了缓存
4、A更新数据库
5、A延时删缓存
1～3步执行后，数据库和缓存是一致的，相当于没删除。
4～5步：先更新数据库，再删缓存。
所以延时双删演变成了：先更新数据库，再删除缓存。问题还是没解决。。。
为什么？假设，此时，在第4步执行之前，又来了个查询C，C查询到旧值。第6步：C将旧值插入缓存。此时出现缓存和数据库不一致。
延时并不能解决：C插入缓存的操作在第5步后面执行，比如C遇到网络问题、GC问题等。当然这是小概率，但并不代表不存在。
当然，延时越长，这个问题越能规避。如果业务需求不是非常严格，是可以忽略的。
问题二：吞吐量
问题三：数据库更新后，无法保证下一次查询，从缓存获取的值和数据库是一致的。
第四种，先更新数据库，再删除缓存
问题：上面C的查询，已经说明问题了。
出现数据不一致的概率，比较小。采取这个方案，取决于业务需求。
终极方案
请求串行化
真正靠谱的方案：将访问操作串行化
先删缓存，将更新数据库的操作放进有序队列中
从缓存查不到的查询操作，都进入有序队列
需要解决的问题：
读请求积压，大量超时，导致数据库的压力：限流、熔断
如何避免大量请求积压：将队列水平拆分，提高并行度。
保证相同请求路由正确。
关于"redis相关知识点及面试点有哪些"这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对"redis相关知识点及面试点有哪些"知识都有一定的了解，大家如果还想学习更多知识，欢迎关注行业资讯频道。
