redis面试必问知识点.pdfVIP

百学须先立志。——朱熹 redis⾯试必问知识点 卑微⼩吴励志写博客第10天。前⼏天写了⼀篇关于redis⼊门的博客，觉得有必要对redis知识点做相应的补充，特别是在⾯试这⼀ 块。 绝⼤部分写业务的程序员，在实际开发中使⽤ Redis 的时候，只会 Set Value 和 Get Value 两个操作，对 Redis 整体缺乏⼀个认知。这⾥对 Redis 常见问题做⼀个总结，解决⼤家的知识盲点。 1、为什么使⽤ Redis 在项⽬中使⽤ Redis，主要考虑两个⾓度：性能和并发。如果只是为了分布式锁这些其他功能，还有其他中间件 Zookpeer 等代替，并⾮ ⼀定要使⽤ Redis。 性能： 如下图所⽰，我们在碰到需要执⾏耗时特别久，且结果不频繁变动的 SQL，就特别适合将运⾏结果放⼊缓存。这样，后⾯的请求就去缓存 中读取，使得请求能够迅速响应。 特别是在秒杀系统，在同⼀时间，⼏乎所有⼈都在点，都在下单。。。执⾏的是同⼀操作———向数据库查数据。 根据交互效果的不同，响应时间没有固定标准。在理想状态下，我们的页⾯跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。 并发： 如下图所⽰，在⼤并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使⽤ Redis 做⼀个缓冲操作， 让请求先访问到 Redis，⽽不是直接访问数据库。 一寸光阴一寸金，寸金难买寸光阴。——《增广贤文》 非淡泊无以明志，非宁静无以致远。——诸葛亮 使⽤ Redis 的常见问题 缓存和数据库双写⼀致性问题 缓存雪崩问题 缓存击穿问题 缓存的并发竞争问题 2、单线程的 Redis 为什么这么快 这个问题是对 Redis 内部机制的⼀个考察。很多⼈都不知道 Redis 是单线程⼯作模型。 原因主要是以下三点： 纯内存操作 单线程操作，避免了频繁的上下⽂切换 采⽤了⾮阻塞 I/O 多路复⽤机制 仔细说⼀说 I/O 多路复⽤机制，打⼀个⽐⽅：⼩名在 A 城开了⼀家快餐店，负责同城快餐服务。⼩明因为资⾦限制，雇佣了⼀批配送员， 然后⼩明发现资⾦不够了，只够买⼀辆车送快递。 经营⽅式⼀ 客户每下⼀份订单，⼩明就让⼀个配送员盯着，然后让⼈开车去送。慢慢的⼩曲就发现了这种经营⽅式存在下述问题： 时间都花在了抢车上了，⼤部分配送员都处在闲置状态，抢到车才能去送。 随着下单的增多，配送员也越来越多，⼩明发现快递店⾥越来越挤，没办法雇佣新的配送员了。 配送员之间的协调很花时间。 综合上述缺点，⼩明痛定思痛，提出了经营⽅式⼆。 经营⽅式⼆ ⼩明只雇佣⼀个配送员。当客户下单，⼩明按送达地点标注好，依次放在⼀个地⽅。最后，让配送员依次开着车去送，送好了就回来拿下⼀ 个。上述两种经营⽅式对⽐，很明显第⼆种效率更⾼。 在上述⽐喻中： 每个配送员→每个线程 每个订单→每个 Socket(I/O 流) 吾日三省乎吾身。为人谋而不忠乎？与朋友交而不信乎？传不习乎？——《论语》 其身正，不令而行；其身不正，虽令不从。——《论语》 订单的送达地点→Socket 的不同状态 客户送餐请求→来⾃客户端的请求 明曲的经营⽅式→服务端运⾏的代码 ⼀辆车→CPU 的核数 于是有了如下结论： 经营⽅式⼀就是传统的并发模型，每个 I/O 流(订单)都有⼀个新的线程(配送员)管理。 经营⽅式⼆就是 I/O 多路复⽤。只有单个线程(⼀个配送员)，通过跟踪每个 I/O 流的状态(每个配送员的送达地点)，来管理多个 I/O 流。 下⾯类⽐到真实的 Redis 线程模型，如图所⽰： Redis-client 在操作的时候，会产⽣具有不同事件类型的 Socket。在服务端，有⼀段 I/O 多路复⽤程序，将其置⼊队列之中。然后，⽂件 事件分派器，依次去队列中取，转发到不同的事件处理器中。 3、Redis 的数据类型及使⽤场景 ⼀个合格的程序员，这五种类型都会⽤到。 String 最常规的 set/get 操作，Value 可以是 String 也可以是数字。⼀般做⼀些复杂的计数功能的缓存。 Hash 这⾥ Value 存放的是结构化的对象，⽐较⽅便的就是操作其中的某个字段。我在做单点登录的时候，就是⽤这种数据结构存储⽤户信息， 以 CookieId 作为 Key，设置 30 分钟为缓存过期时间，能很好的模拟出类似 Session 的效果。 List 使⽤ List 的数据结构，可以做简单的消息队列的功能。另外，可以利⽤ lrange 命令，做基于 Redi