看目录自己面试,答案在下边,会慢慢补充。
- 并发
- Mysql
- Redis
- 应用场景及数据结构算法
- 1.简述缓存的基本**
- 2.为什么要用分布式缓存 - 不直接用本地缓存
- 3.简单介绍一下redis
- 4.redis和memcached的区别和共同点
- 5.为什么要用缓存/为什么要用redis
- 6.redis给缓存数据设置过期时间有啥用
- 7.redis可以实现事务吗?如何实现的
- 8.如何利用Redis实现乐观锁?
- 9.了解Redis的管道吗?有什么好处?
- 10.谈一下缓存穿透
- 11.谈一下缓存击穿
- 12.谈一下缓存雪崩
- 13.Redis有一个分布式锁,有什么弊端?怎么解决?
- 14.如何保证缓存和数据库数据的一致性?
- 15.Redis中,big key有哪些危害?怎么避免?
- 16.常见数据结构及使用场景
- 17.为什么Redis选择使用跳表而不是红黑树来实现有序集合?
- 18.聊一下ziplist、quicklist、intset
- 19.聊一下Hyperloglog
- 20.什么是一致性哈希算法?什么是哈希槽?
- 21.keys * 有什么风险?该怎么解决?
- 22.如何用Redis实现一个延时队列?
- 23.如何用Redis实现购物车功能?
- 24.如何用Redis实现微信微博点赞功能?
- 25.如何用Redis实现微博关注功能中,你可能认识的人?你和他的共同好友?
- 26.如何利用Redis实现微信抽奖功能?一次抽奖抽出六个人 或 多次抽奖包含三等奖、二等奖、一等奖
- 27.如何利用Redis实现微博热搜?
- 28.如何利用Redis实现电商中,根据各个标签筛选商品?一个商品可能涉及多个标签
- 29.如何利用Redis实现附近的人?
- 30.Redis中有一个限流模块,了解过吗?谈一下几大限流算法
- 31.怎么设计一套秒杀系统?
- 工作机制
- 集群
- 1.redis主从怎么复制的?有哪些方案?
- 2.从节点挂掉之后重新启动,怎么跟主节点保持一致?会有什么问题吗?
- 3.谈一下Redis集群方式。sentinel工作原理?Redis cluster工作原理?
- 4.谈一下 CAP,Redis符合哪些?为什么?
- 5.sentinel 和 Redis cluster对比一下,有哪些优缺点?
- 6.谈一下Redis cluster中槽位是怎么转移的?
- 7.Redis cluster中,-MOVED 和 -asking的区别?
- 8.Redis cluster中,客户端会缓存一份槽位信息映射表。当槽位发生变化后,客户端是怎么感知的?
- 9.集群节点变更后,客户端是怎么感知的?
- 10.Redis cluster是怎么处理网络抖动的?
- 11.谈一下Redis cluster中的 GOSIP 协议
- 应用场景及数据结构算法
进程 - 程序的一次执行过程 ,是系统运行程序的基本单位 是动态的
线程 - 一个进程在执行过程中可以产生多个线程,同类的多个线程共享进程的堆和方法区资源,每个线程有自己的程序计数器/虚拟机栈/本地方法栈。产生一个线程,各个线程之间切换工作,负担会比进程小得多
- 可以提高系统性能以及减少请求响应时间。基本**是空间换时间,cpu缓存的是内存数据-用于解决CPU运算速度和内存读写速度不匹配的问题 内存缓存的是硬盘的数据 用于解决硬盘访问速度过慢的问题 操作系统在页表方案基础上引入快表加速虚拟地址到物理地址的转换 那么块表可以理解为一种特殊的高速缓冲存储器。从业务的角度,为了避免用户在请求数据时获取速度过于缓慢,在数据库之上增加了缓存
- 本地缓存对分布式架构支持不友好 - 本地缓存只在当前机器上 同一个相同服务部署在多台服务器上,各个服务之间的缓存无法共享
- 本地缓存容量受服务器部署所在的机器限制 - 如果当前系统服务耗费的内存多,本地缓存可用的容量就很少
使用分布式缓存后,缓存部署在一台单独的服务器上,即使同一份服务部署在多台服务器上,使用的是同一份缓存。单独分布式缓存服务的性能 容量和提供的功能都要强大
c语言开发的数据库,数据是存放在内存中的,所以读写速度非常快。被广泛用于缓存方向,除此之外 经常被用来用分布式锁/消息队列等 提供了多种数据类型来支持不同的业务场景,支持事务/持久化/Lua脚本/多种集群方案
https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/Redis/redis-all.md
- Cache Aside Pattern(旁路缓存模式)
写:更新 DB,然后直接删除 cache 。
读:从 cache 中读取数据,读取到就直接返回,读取不到的话,就从 DB 中取数据返回,然后再把数据放到 cache 中。
Cache Aside Pattern 中服务端需要同时维系 DB 和 cache,并且是以 DB 的结果为准。另外,Cache Aside Pattern 有首次请求数据一定不在 cache 的问题,对于热点数据可以提前放入缓存中。
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式,比较适合读请求比较多的场景。
Read/Write Through 套路是:服务端把 cache 视为主要数据存储,从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 DB,从而减轻了应用程序的职责。
- 写(Write Through):先查 cache,cache 中不存在,直接更新 DB。 cache 中存在,则先更新 cache,然后 cache 服务自己更新 DB(同步更新 cache 和 DB)。
- 读(Read Through): 从 cache 中读取数据,读取到就直接返回 。读取不到的话,先从 DB 加载,写入到 cache 后返回响应。
Read-Through Pattern 实际只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下,发生读请求的时候,如果 cache 中不存在对应的数据,是由客户端自己负责把数据写入 cache,而 Read Through Pattern 则是 cache 服务自己来写入缓存的,这对客户端是透明的。
和 Cache Aside Pattern 一样, Read-Through Pattern 也有首次请求数据一定不再 cache 的问题,对于热点数据可以提前放入缓存中。
Write Behind Pattern 和 Read/Write Through Pattern 很相似,两者都是由 cache 服务来负责 cache 和 DB 的读写。
但是,两个又有很大的不同:Read/Write Through 是同步更新 cache 和 DB,而 Write Behind Caching 则是只更新缓存,不直接更新 DB,而是改为异步批量的方式来更新 DB。
Write Behind Pattern 下 DB 的写性能非常高,尤其适合一些数据经常变化的业务场景比如说一篇文章的点赞数量、阅读数量。 往常一篇文章被点赞 500 次的话,需要重复修改 500 次 DB,但是在 Write Behind Pattern 下可能只需要修改一次 DB 就可以了。
但是,这种模式同样也给 DB 和 Cache 一致性带来了新的考验,很多时候如果数据还没异步更新到 DB 的话,Cache 服务宕机就 gg 了。
https://draveness.me/whys-the-design-redis-single-thread/
(LRU+贪心算法)
(数据页)