首页
影视
壁纸
留言
关于
今日热榜
推荐
音乐解锁
听歌
阅读器
听歌2
小乞丐
摸鱼
Search
1
Navicat Premium for Mac 中文破解版 (强大的数据库管理工具)
9,631 阅读
2
植物大战僵尸中文版 for Mac (兼容 M1系统) 中文版
5,767 阅读
3
CleanMyMac X 4.15.2 中文破解版 (Mac优化清理工具)
3,296 阅读
4
PDF Expert 中文破解版 (好用的PDF编辑器)
3,044 阅读
5
Parallels Desktop 17 中文版 (PD虚拟机无限试用版本)
2,820 阅读
生活杂记
macOS
编程技术
奇技淫巧
音乐
视频
δ
Search
标签搜索
python
漫画
php
mac
redis
mysql
mac 软件
macOS
音乐
极客爱情
数据库
游戏
吊打面试官
2.0
面试
罗小黑
linux
纯音乐
使用教程
B站
Kain
累计撰写
210
篇文章
累计收到
26
条评论
首页
栏目
生活杂记
macOS
编程技术
奇技淫巧
音乐
视频
δ
页面
影视
壁纸
留言
关于
今日热榜
推荐
音乐解锁
听歌
阅读器
听歌2
小乞丐
摸鱼
搜索到
4
篇与
的结果
2021-01-23
理解完这些基本上能解决面试中MySql的事务问题
越努力,越幸运前言在面试中,基本上都会问到关于数据库的事务问题,如果啥都不会或者只回答到表面的上知识点的话,那面试基本上是没戏了,为了能顺利通过面试,那MySql的事务问题就需要了解,所以就根据网上的资料总结一版Mysql事务的知识点,巩固一下事务的知识。事务事务是指逻辑上的一组操作,要么都执行,要么都不执行,事务的特性(ACID)原子性(Atomicity):事务是不可分割的工作单元,要么都成功,要么都失败, 如果事务中一个sql语句执行失败,则已执行的语句也必须回滚,数据库退回到事务前的状态。一致性(Consistency):事务不能破坏数据的完整性和业务的一致性 。例如在银行转账时,不管事务成功还是失败,双方钱的总额不变隔离性(Isolation):一个事务所操作的数据在提交之前,对其他事务的可见性设定(一般是不可见)持久性(Durability):事务提交之后,所做的修改就会永久保存,不会因为系统故障导致数据丢失严格来说,只有同时满足数据库的事务ACID特性才能算一个完整的事务,但现实中实现能够真正满足的完整的事务特性少之又少,但是在实现中也必须尽量达到事务要求的特性。那么事务ACID特性具体怎么实现的呢?我们来分析看看,首先先看看事务的特性。原子性(Atomicity)首先我们来看看事务的原子性特性,看看其如何实现的?原子性(Atomicity):事务是不可分割的工作单元,要么都成功,要么都失败, 如果事务中一个sql语句执行失败,则已执行的语句也必须回滚,数据库退回到事务前的状态原子性(Atomicity)的实现离不开 MySQL的事务日志 undo log日志类型,当事务需要回滚的时候需要将数据库状态回滚到事务开始前,即需要撤销所有已经成功执行的sql语句。那么undo log起了关键性作用:当事务对数据库进行修改时,InnoDB会生成对应的undo log;如果事务执行失败或调用了rollback,导致事务需要回滚,便可以利用undo log中的信息将数据回滚到修改之前的样子。那么undo log是什么呢?每个数据变更操作是怎么被记录下来的呢?undo log( 回滚日志 )undo log (回滚日志):是采用段(segment)*的方式来记录的,每个undo操作在记录的时候占用一个*undo log segment。为什么会在数据更改操作的时候,记录了相对应的undo log呢?其目的在于:为了保证数据的原子性,记录事务发生之前的一个版本,用于回滚,通过mvcc+undo log实现innodb事务可重复读和读取已提交隔离级别。其中,undo log分为:insert undo log : insert操作中产生的undo log,update undo log: 对delete 和update操作产生的undo log数据更改的undo log怎么记录的呢?因为insert操作的记录,只对事务本身可见,对其他事务不可见。故该undo log可以在事务提交后直接删除,不需要进行purge操作,而Delete操作在事务中实际上并不是真正的删除掉数据行,而是一种Delete Mark操作,在记录上标识Delete_Bit,而不删除记录。是一种"假删除",只是做了个标记,真正的删除工作需要后台purge线程去完成。update分为两种情况:update的列是否是主键列。如果不是主键列,在undo log中直接反向记录是如何update的。即update是直接进行的。如果是主键列,update分两部执行:先删除该行,再插入一行目标行。与insert undo log 不同的,update undo log日志,当事务提交的时候,innodb不会立即删除undo log, 会将该事务对应的undo log放入到删除列表中,未来通过purge线程来删除。因为后续还可能会用到undo log,如隔离级别为repeatable read时,事务读取的都是开启事务时的最新提交行版本,只要该事务不结束,该行版本就不能删除(即undo log不能删除),且undo log分配的页可重用减少存储空间和提升性能。Note: purge线程两个主要作用是:清理undo页和清除page里面带有Delete_Bit标识的数据行。接着我们来看看事务的隔离性,看看事务有哪些隔离级别,而且事务并发中会产生什么问题。隔离性(Isolation)隔离性(Isolation),是指事务内部的操作与其他事务是隔离的,并发执行的各个事务之间不能互相干扰 ,一个事务所操作的数据在提交之前,对其他事务的可见性设定(一般是不可见)。事务隔离级别而且数据库为了在并发下有效保证读取数据正确性,数据库提供了四种事务隔离级别,分别为:读未提交(脏读):允许读取尚未提交的数据,允许脏读读已提交( 不可重复读 ):允许读取事务已经提交的数据可重复读( 幻读 ):在同一个事务内的查询结果都是和事务开始时刻查询一致的( InnoDB默认级别 )串行化:所有事务逐个依次执行, 每次读都需要获得表级共享锁,读写相互都会阻塞其中,不同的隔离级别可能会存在在不同并发问题,主要并发问题包括:数据丢失: 两个或多个事务操作相同数据,基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新脏读:读到了其他事务还未提交的数据,事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据不可重复读(重点是修改):在一个事务中,先后进行两次相同的读取,由于另一个事务修改了数据,导致前后两次结果的不一致,事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果不一致。幻读(重点是新增、删除): 在一个事务中,先后进行两次相同的读取(一般是范围查询),由于另一个事务新增或删除了数据,导致前后两次结果不一致不可重复读和幻读的区别?不可重复读和幻读最大的区别,就在于如何通过锁机制来解决他们产生的问题,使用锁机制来实现这两种隔离级别,在可重复读中,相同sql第一次读取到数据后就将这些数据加锁,其它事务无法更新操作这些数据来实现可重复读了隔离。但这种处理方式却无法锁住insert的数据,因此会出现当事务A先前读取了数据,事务B再insert数据提交,结果发现事务A就会发现莫名其妙多了些数据,这就是幻读,不能通过行锁来避免 。了解了并发问题后,来看看不同的隔离级别可能会存在在不同并发问题:事务隔离级别脏读不可重复读幻读读未提交是是是不可重复读否是是可重复读否否是串行化否否否为了实现事务隔离,延伸出了数据库锁。其中,innodb事务的隔离级别是由锁机制和MVCC(多版本并发控制)来实现的那我们来先看看锁的原理,怎么使用锁来实现事务隔离的呢?锁机制锁机制的基本工作原理,事务在修改数据之前,需要先获得相应的锁;获得锁之后,事务便可以修改数据;该事务操作期间,这部分数据是锁定的,其他事务如果需要修改数据,需要等待当前事务提交或回滚后释放锁,MySQL主要分成三种类型(级别)的锁机制:表级锁:最大颗粒度的锁机制,锁定资源争用的概率也会最高 ,并发度最低 ,但开销小,加锁快,不会出现死锁,行级锁:最大颗粒度的锁机制很小, 发生锁定资源争用的概率也最小,能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能 ,但 开销大,加锁慢;会出现死锁 ,页级锁: 开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般而且不同的存储引擎支持不同的的锁机制,主要分析一下InnoDB锁。InnoDB锁InnoDB实现了以下两种类型的行锁共享锁(S锁、行锁):多个事务对同一数据行可以共享一把锁,只能读不能修改排它锁(X锁、行锁):一个事务获取一个数据行的排它锁,那么其他事务将不能再获取该行的锁(共享锁、排它锁), 允许获取排他锁的事务更新数据对于UPDATE,DELETE,INSERT操作, InnoDB会自动给涉及及数据集加排他锁(X);对于普通SELECT语句,InnoDB不会加任何锁,而且因为InnoDB引擎允许行锁和表锁共存,实现多粒度锁机制,使用意向锁实现表锁机制,意向共享锁(IS锁、表锁):当事务准备给数据行加共享锁时,会先给表加上一个意向共享锁。意向共享锁之间是兼容的意向排它锁(IX锁、表锁):当事务准备给数据行加排它锁时,会先给表加上一个意向排它锁。意向排它锁之间是兼容的意向锁(IS、IX)是InnoDB数据操作之前自动加的,不需要用户干预。它的意义在于:当事务想去进行锁表时,可以先判断意向锁是否存在,存在时则可快速返回该表不能启用表锁,否则就需要等待,其中,四种锁的兼容性如下当前锁模式/是否兼容/请求锁模式XIXSISX冲突冲突冲突冲突IX冲突兼容冲突兼容S冲突冲突兼容兼容IS冲突兼容兼容兼容如果一个事务请求的锁模式与当前的锁兼容,InnoDB就请求的锁授予该事务;反之,如果两者两者不兼容,该事务就要等待锁释放。InnoDB行锁InnoDB的行锁是通过给索引上的索引项加锁来实现的。只有通过索引检索数据,才能使用行锁,否则将使用表锁(锁住索引的所有记录)临键锁(next-key),可以防止幻读。根据索引,划分为一个个左开右闭的区间。当进行范围查询的时候,若命中索引且能够检索到数据,则锁住记录所在的区间和它的下一个区间,其实,临键锁(Next-Key)=记录锁(Record Locks)+间隙锁(Gap Locks),当我们用范围条件检索数据而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合范围条件的已有数据记录的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做间隙(GAP)。当使用唯一索引,且记录存在的精准查询时,使用Record Locks记录锁具体的使用体现在哪里呢?如下图所示:范围查询,记录存在当记录不存在(不论是等值查询,还是范围查询)时,next-key将退化成Gap Lock(间隙锁)当条件是精准匹配(即为等值查询时)且记录存在时,并且是唯一索引,临键锁(Next-Key)*退化成*Record Lock(记录锁)当条件是精准匹配(即为等值查询时)且记录存在,但不是唯一索引时,临键锁(Next-Key)*会有精准值的数据会增加*Record Lock(记录锁)*和精准值前后的区间的数据会增加*Gap Lock(间隙锁)。如何使用锁解决并发问题利用锁解决脏读、不可重复读、幻读X锁解决脏读S锁解决不可重复读临键锁解决幻读Multiversion concurrency control (MVCC 多版本并发控制)InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的,一个保存了行的事务ID(事务ID就会递增 ),一个保存了行的回滚段的指针 。每开始一个新的事务,都会自动递增产 生一个新的事务id。事务开始时刻的会把事务id放到当前事务影响的行事务id中,而DB_ROLL_PTR表示指向该行回滚段的指针,该行记录上所有版本数据,在undo中都通过链表形式组织,该值实际指向undo中该行的历史记录链表,在并发访问数据库时,对正在事务中的数据做MVCC多版本的管理,以避免写操作阻塞读操作,并且会通过比较版本解决幻读。而且MVCC只在REPEATABLE READ和READ COMMITIED两个隔离级别下才会工作,其中,MVCC实现实质就是保存数据在某个时间点的快照来实现的。 那哪些操作是快照读?快照读和当前读快照读,innodb快照读,数据的读取将由 cache(原本数据) + undo(事务修改前的数据) 两部分组成普通的select,比如 select * from table where ?;当前读,SQL读取的数据是最新版本。通过锁机制来保证读取的数据无法通过其他事务进行修改UPDATEDELETEINSERTSELECT … LOCK IN SHARE MODESELECT … FOR UPDATE其中当前读中,只有SELECT … LOCK IN SHARE MODE对读取记录加S锁 (共享锁)外,其他的操作,都加的是X锁 (排它锁)。那么在RR隔离级别下,MVCC具体是如何操作的。RR隔离级别下,MVCC具体操作SELECT操作,InnoDB遵循以后两个规则执行:InnoDB只查找版本早于当前事务版本的数据行(即行的事务编号小于或等于当前事务的事务编号,这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的记录。行的删除版本要么未定义,读取到事务开始之前状态的版本,这可以确保事务读取到的行,在事务开始之前未被删除.只有同时满足的两者的记录,才能返回作为查询结果.INSERT:InnoDB为新插入的每一行保存当前事务编号作为行版本号。DELETE:InnoDB为删除的每一行保存当前事务编号作为行删除标识。UPDATE:InnoDB为插入一行新记录,保存当前事务编号作为行版本号,同时保存当前事务编号到原来的行作为行删除标识。保存这两个额外系统版本号,使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单,性能很好,并且也能保证只会读取到符合标准的行,不足之处是每行记录都需要额外的存储空间,需要做更多的行检查工作,以及一些额外的维护工作。分析完了原子性和隔离性,我们继续看看事务的持久性。持久性(Durability)持久性(Durability):事务提交之后,所做的修改就会永久保存,不会因为系统故障导致数据丢失,而且其实现的关键在于redo log, 在执行SQL时会保存已执行的SQL语句到一个指定的Log文件,当执行recovery时重新执行redo log记录的SQL操作。那么redo log如何实现的呢?redo log当向数据库写入数据时,执行过程会首先写入Buffer Pool,Buffer Pool中修改的数据会定期刷新到磁盘中(这一过程称为刷脏),这整一过程称为redo log。redo log 分为:Buffer Pool内存中的日志缓冲(redo log buffer),该部分日志是易失性的;磁盘上的重做日志文件(redo log file),该部分日志是持久的。Buffer Pool的使用可以大大提高了读写数据的效率,但是也带了新的问题:如果MySQL宕机,而此时Buffer Pool中修改的数据在内存还没有刷新到磁盘,就会导致数据的丢失,事务的持久性无法保证。为了确保事务的持久性,在当事务提交时,会调用fsync接口对redo log进行刷盘, (即redo log buffer写日志到磁盘的redo log file中 ),刷新频率由 innodb_flush_log_at_trx_commit变量来控制的:0 : 每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据 ;1: 事务每次提交都写入磁盘;2:每秒刷新写入到磁盘中的,但跟0是有区别的。redo log有更加详细的解读,后续有时间再补上,到现在为止,已经将事务三个特性都理解了,那事务一致性呢?一致性(Consistency)一致性(Consistency):事务不能破坏数据的完整性和业务的一致性 :数据的完整性: 实体完整性、列完整性(如字段的类型、大小、长度要符合要求)、外键约束等业务的一致性:例如在银行转账时,不管事务成功还是失败,双方钱的总额不变。那是如何保证数据一致性的?其实数据一致性是通过事务的原子性、持久性和隔离性来保证的原子性:语句要么全执行,要么全不执行,是事务最核心的特性,事务本身就是以原子性来定义的;实现主要基于undo log持久性:保证事务提交后不会因为宕机等原因导致数据丢失;实现主要基于redo log隔离性:保证事务执行尽可能不受其他事务影响;InnoDB默认的隔离级别是RR,RR的实现主要基于锁机制(包含next-key lock)、MVCC(包括数据的隐藏列、基于undo log的版本链、ReadView)总结其中要同时满足ACID特性,这样的事务少之又少。实际中很多例子都只是满足一些特性,比如:MySQL的NDB Cluster事务不满足持久性和隔离性;InnoDB默认事务隔离级别是可重复读,不满足隔离性;Oracle默认的事务隔离级别为READ COMMITTED,不满足隔离性所以我们只能使用这个四个维度的特性去衡量事务的操作。
2021年01月23日
112 阅读
0 评论
0 点赞
2020-07-06
《吊打面试官》系列-Redis常见面试题(带答案)
你知道的越多,你不知道的越多前言Redis在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次Offer的面霸,打败了无数竞争对手,每次都只能看到无数落寞的身影失望的离开,略感愧疚(请允许我使用一下夸张的修辞手法)。回望过去上一期吊打系列我们提到了Redis相关的一些知识,还没看的小伙伴可以回顾一下《吊打面试官》系列-Redis基础《吊打面试官》系列-缓存雪崩、击穿、穿透《吊打面试官》系列-Redis哨兵、持久化、主从、手撕LRU《吊打面试官》系列-Redis终章这期我就从缓存到一些常见的问题讲一下,有一些我是之前提到过的,不过可能大部分仔是第一次看,我就重复发一下。缓存知识点缓存有哪些类型?缓存是高并发场景下提高热点数据访问性能的一个有效手段,在开发项目时会经常使用到。缓存的类型分为:本地缓存、分布式缓存和多级缓存。本地缓存:本地缓存就是在进程的内存中进行缓存,比如我们的 JVM 堆中,可以用 LRUMap 来实现,也可以使用 Ehcache 这样的工具来实现。本地缓存是内存访问,没有远程交互开销,性能最好,但是受限于单机容量,一般缓存较小且无法扩展。分布式缓存:分布式缓存可以很好得解决这个问题。分布式缓存一般都具有良好的水平扩展能力,对较大数据量的场景也能应付自如。缺点就是需要进行远程请求,性能不如本地缓存。多级缓存:为了平衡这种情况,实际业务中一般采用多级缓存,本地缓存只保存访问频率最高的部分热点数据,其他的热点数据放在分布式缓存中。在目前的一线大厂中,这也是最常用的缓存方案,单考单一的缓存方案往往难以撑住很多高并发的场景。淘汰策略不管是本地缓存还是分布式缓存,为了保证较高性能,都是使用内存来保存数据,由于成本和内存限制,当存储的数据超过缓存容量时,需要对缓存的数据进行剔除。一般的剔除策略有 FIFO 淘汰最早数据、LRU 剔除最近最少使用、和 LFU 剔除最近使用频率最低的数据几种策略。noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外)allkeys-lru: 尝试回收最少使用的键(LRU),使得新添加的数据有空间存放。volatile-lru: 尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。allkeys-random: 回收随机的键使得新添加的数据有空间存放。volatile-random: 回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。volatile-ttl: 回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。如果没有键满足回收的前提条件的话,策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。其实在大家熟悉的LinkedHashMap中也实现了Lru算法的,实现如下:当容量超过100时,开始执行LRU策略:将最近最少未使用的 TimeoutInfoHolder 对象 evict 掉。真实面试中会让你写LUR算法,你可别搞原始的那个,那真TM多,写不完的,你要么怼上面这个,要么怼下面这个,找一个数据结构实现下Java版本的LRU还是比较容易的,知道啥原理就好了。Memcache注意后面会把 Memcache 简称为 MC。先来看看 MC 的特点:MC 处理请求时使用多线程异步 IO 的方式,可以合理利用 CPU 多核的优势,性能非常优秀;MC 功能简单,使用内存存储数据;MC 的内存结构以及钙化问题我就不细说了,大家可以查看官网了解下;MC 对缓存的数据可以设置失效期,过期后的数据会被清除;失效的策略采用延迟失效,就是当再次使用数据时检查是否失效;当容量存满时,会对缓存中的数据进行剔除,剔除时除了会对过期 key 进行清理,还会按 LRU 策略对数据进行剔除。另外,使用 MC 有一些限制,这些限制在现在的互联网场景下很致命,成为大家选择Redis、MongoDB的重要原因:key 不能超过 250 个字节;value 不能超过 1M 字节;key 的最大失效时间是 30 天;只支持 K-V 结构,不提供持久化和主从同步功能。Redis先简单说一下 Redis 的特点,方便和 MC 比较。与 MC 不同的是,Redis 采用单线程模式处理请求。这样做的原因有 2 个:一个是因为采用了非阻塞的异步事件处理机制;另一个是缓存数据都是内存操作 IO 时间不会太长,单线程可以避免线程上下文切换产生的代价。Redis 支持持久化,所以 Redis 不仅仅可以用作缓存,也可以用作 NoSQL 数据库。相比 MC,Redis 还有一个非常大的优势,就是除了 K-V 之外,还支持多种数据格式,例如 list、set、sorted set、hash 等。Redis 提供主从同步机制,以及 Cluster 集群部署能力,能够提供高可用服务。详解 RedisRedis 的知识点结构如下图所示。功能来看 Redis 提供的功能有哪些吧!我们先看基础类型:String:String 类型是 Redis 中最常使用的类型,内部的实现是通过 SDS(Simple Dynamic String )来存储的。SDS 类似于 Java 中的 ArrayList,可以通过预分配冗余空间的方式来减少内存的频繁分配。这是最简单的类型,就是普通的 set 和 get,做简单的 KV 缓存。但是真实的开发环境中,很多仔可能会把很多比较复杂的结构也统一转成String去存储使用,比如有的仔他就喜欢把对象或者List转换为JSONString进行存储,拿出来再反序列话啥的。我在这里就不讨论这样做的对错了,但是我还是希望大家能在最合适的场景使用最合适的数据结构,对象找不到最合适的但是类型可以选最合适的嘛,之后别人接手你的代码一看这么规范,诶这小伙子有点东西呀,看到你啥都是用的String,垃圾!好了这些都是题外话了,道理还是希望大家记在心里,习惯成自然嘛,小习惯成就你。String的实际应用场景比较广泛的有:缓存功能:String字符串是最常用的数据类型,不仅仅是Redis,各个语言都是最基本类型,因此,利用Redis作为缓存,配合其它数据库作为存储层,利用Redis支持高并发的特点,可以大大加快系统的读写速度、以及降低后端数据库的压力。计数器:许多系统都会使用Redis作为系统的实时计数器,可以快速实现计数和查询的功能。而且最终的数据结果可以按照特定的时间落地到数据库或者其它存储介质当中进行永久保存。共享用户Session:用户重新刷新一次界面,可能需要访问一下数据进行重新登录,或者访问页面缓存Cookie,但是可以利用Redis将用户的Session集中管理,在这种模式只需要保证Redis的高可用,每次用户Session的更新和获取都可以快速完成。大大提高效率。Hash:这个是类似 Map 的一种结构,这个一般就是可以将结构化的数据,比如一个对象(前提是这个对象没嵌套其他的对象)给缓存在 Redis 里,然后每次读写缓存的时候,可以就操作 Hash 里的某个字段。但是这个的场景其实还是多少单一了一些,因为现在很多对象都是比较复杂的,比如你的商品对象可能里面就包含了很多属性,其中也有对象。我自己使用的场景用得不是那么多。List:List 是有序列表,这个还是可以玩儿出很多花样的。比如可以通过 List 存储一些列表型的数据结构,类似粉丝列表、文章的评论列表之类的东西。比如可以通过 lrange 命令,读取某个闭区间内的元素,可以基于 List 实现分页查询,这个是很棒的一个功能,基于 Redis 实现简单的高性能分页,可以做类似微博那种下拉不断分页的东西,性能高,就一页一页走。比如可以搞个简单的消息队列,从 List 头怼进去,从 List 屁股那里弄出来。List本身就是我们在开发过程中比较常用的数据结构了,热点数据更不用说了。消息队列:Redis的链表结构,可以轻松实现阻塞队列,可以使用左进右出的命令组成来完成队列的设计。比如:数据的生产者可以通过Lpush命令从左边插入数据,多个数据消费者,可以使用BRpop命令阻塞的“抢”列表尾部的数据。文章列表或者数据分页展示的应用。比如,我们常用的博客网站的文章列表,当用户量越来越多时,而且每一个用户都有自己的文章列表,而且当文章多时,都需要分页展示,这时可以考虑使用Redis的列表,列表不但有序同时还支持按照范围内获取元素,可以完美解决分页查询功能。大大提高查询效率。Set:Set 是无序集合,会自动去重的那种。直接基于 Set 将系统里需要去重的数据扔进去,自动就给去重了,如果你需要对一些数据进行快速的全局去重,你当然也可以基于 JVM 内存里的 HashSet 进行去重,但是如果你的某个系统部署在多台机器上呢?得基于Redis进行全局的 Set 去重。可以基于 Set 玩儿交集、并集、差集的操作,比如交集吧,我们可以把两个人的好友列表整一个交集,看看俩人的共同好友是谁?对吧。反正这些场景比较多,因为对比很快,操作也简单,两个查询一个Set搞定。Sorted Set:Sorted set 是排序的 Set,去重但可以排序,写进去的时候给一个分数,自动根据分数排序。有序集合的使用场景与集合类似,但是set集合不是自动有序的,而Sorted set可以利用分数进行成员间的排序,而且是插入时就排序好。所以当你需要一个有序且不重复的集合列表时,就可以选择Sorted set数据结构作为选择方案。排行榜:有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜,榜单维护可能是多方面:按照时间、按照播放量、按照获得的赞数等。用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。微博热搜榜,就是有个后面的热度值,前面就是名称高级用法:Bitmap :位图是支持按 bit 位来存储信息,可以用来实现 布隆过滤器(BloomFilter);HyperLogLog:供不精确的去重计数功能,比较适合用来做大规模数据的去重统计,例如统计 UV;Geospatial:可以用来保存地理位置,并作位置距离计算或者根据半径计算位置等。有没有想过用Redis来实现附近的人?或者计算最优地图路径?这三个其实也可以算作一种数据结构,不知道还有多少朋友记得,我在梦开始的地方,Redis基础中提到过,你如果只知道五种基础类型那只能拿60分,如果你能讲出高级用法,那就觉得你有点东西。pub/sub:功能是订阅发布功能,可以用作简单的消息队列。Pipeline:可以批量执行一组指令,一次性返回全部结果,可以减少频繁的请求应答。Lua:Redis 支持提交 Lua 脚本来执行一系列的功能。我在前电商老东家的时候,秒杀场景经常使用这个东西,讲道理有点香,利用他的原子性。话说你们想看秒杀的设计么?我记得我面试好像每次都问啊,想看的直接点赞后评论秒杀吧。事务:最后一个功能是事务,但 Redis 提供的不是严格的事务,Redis 只保证串行执行命令,并且能保证全部执行,但是执行命令失败时并不会回滚,而是会继续执行下去。持久化Redis 提供了 RDB 和 AOF 两种持久化方式,RDB 是把内存中的数据集以快照形式写入磁盘,实际操作是通过 fork 子进程执行,采用二进制压缩存储;AOF 是以文本日志的形式记录 Redis 处理的每一个写入或删除操作。RDB 把整个 Redis 的数据保存在单一文件中,比较适合用来做灾备,但缺点是快照保存完成之前如果宕机,这段时间的数据将会丢失,另外保存快照时可能导致服务短时间不可用。AOF 对日志文件的写入操作使用的追加模式,有灵活的同步策略,支持每秒同步、每次修改同步和不同步,缺点就是相同规模的数据集,AOF 要大于 RDB,AOF 在运行效率上往往会慢于 RDB。细节的点大家去高可用这章看,特别是两者的优缺点,以及怎么抉择。《吊打面试官》系列-Redis哨兵、持久化、主从、手撕LRU高可用来看 Redis 的高可用。Redis 支持主从同步,提供 Cluster 集群部署模式,通过 Sentine l哨兵来监控 Redis 主服务器的状态。当主挂掉时,在从节点中根据一定策略选出新主,并调整其他从 slaveof 到新主。选主的策略简单来说有三个:slave 的 priority 设置的越低,优先级越高;同等情况下,slave 复制的数据越多优先级越高;相同的条件下 runid 越小越容易被选中。在 Redis 集群中,sentinel 也会进行多实例部署,sentinel 之间通过 Raft 协议来保证自身的高可用。Redis Cluster 使用分片机制,在内部分为 16384 个 slot 插槽,分布在所有 master 节点上,每个 master 节点负责一部分 slot。数据操作时按 key 做 CRC16 来计算在哪个 slot,由哪个 master 进行处理。数据的冗余是通过 slave 节点来保障。哨兵哨兵必须用三个实例去保证自己的健壮性的,哨兵+主从并不能保证数据不丢失,但是可以保证集群的高可用。为啥必须要三个实例呢?我们先看看两个哨兵会咋样。master宕机了 s1和s2两个哨兵只要有一个认为你宕机了就切换了,并且会选举出一个哨兵去执行故障,但是这个时候也需要大多数哨兵都是运行的。那这样有啥问题呢?M1宕机了,S1没挂那其实是OK的,但是整个机器都挂了呢?哨兵就只剩下S2个裸屌了,没有哨兵去允许故障转移了,虽然另外一个机器上还有R1,但是故障转移就是不执行。经典的哨兵集群是这样的:M1所在的机器挂了,哨兵还有两个,两个人一看他不是挂了嘛,那我们就选举一个出来执行故障转移不就好了。暖男我,小的总结下哨兵组件的主要功能:集群监控:负责监控 Redis master 和 slave 进程是否正常工作。消息通知:如果某个 Redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员。故障转移:如果 master node 挂掉了,会自动转移到 slave node 上。配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址。主从提到这个,就跟我前面提到的数据持久化的RDB和AOF有着比密切的关系了。我先说下为啥要用主从这样的架构模式,前面提到了单机QPS是有上限的,而且Redis的特性就是必须支撑读高并发的,那你一台机器又读又写,这谁顶得住啊,不当人啊!但是你让这个master机器去写,数据同步给别的slave机器,他们都拿去读,分发掉大量的请求那是不是好很多,而且扩容的时候还可以轻松实现水平扩容。你启动一台slave 的时候,他会发送一个psync命令给master ,如果是这个slave第一次连接到master,他会触发一个全量复制。master就会启动一个线程,生成RDB快照,还会把新的写请求都缓存在内存中,RDB文件生成后,master会将这个RDB发送给slave的,slave拿到之后做的第一件事情就是写进本地的磁盘,然后加载进内存,然后master会把内存里面缓存的那些新命名都发给slave。我发出来之后来自CSDN的网友:Jian_Shen_Zer 问了个问题:主从同步的时候,新的slaver进来的时候用RDB,那之后的数据呢?有新的数据进入master怎么同步到slaver啊敖丙答:笨,AOF嘛,增量的就像MySQL的Binlog一样,把日志增量同步给从服务就好了key 失效机制Redis 的 key 可以设置过期时间,过期后 Redis 采用主动和被动结合的失效机制,一个是和 MC 一样在访问时触发被动删除,另一种是定期的主动删除。定期+惰性+内存淘汰缓存常见问题缓存更新方式这是决定在使用缓存时就该考虑的问题。缓存的数据在数据源发生变更时需要对缓存进行更新,数据源可能是 DB,也可能是远程服务。更新的方式可以是主动更新。数据源是 DB 时,可以在更新完 DB 后就直接更新缓存。当数据源不是 DB 而是其他远程服务,可能无法及时主动感知数据变更,这种情况下一般会选择对缓存数据设置失效期,也就是数据不一致的最大容忍时间。这种场景下,可以选择失效更新,key 不存在或失效时先请求数据源获取最新数据,然后再次缓存,并更新失效期。但这样做有个问题,如果依赖的远程服务在更新时出现异常,则会导致数据不可用。改进的办法是异步更新,就是当失效时先不清除数据,继续使用旧的数据,然后由异步线程去执行更新任务。这样就避免了失效瞬间的空窗期。另外还有一种纯异步更新方式,定时对数据进行分批更新。实际使用时可以根据业务场景选择更新方式。数据不一致第二个问题是数据不一致的问题,可以说只要使用缓存,就要考虑如何面对这个问题。缓存不一致产生的原因一般是主动更新失败,例如更新 DB 后,更新 Redis 因为网络原因请求超时;或者是异步更新失败导致。解决的办法是,如果服务对耗时不是特别敏感可以增加重试;如果服务对耗时敏感可以通过异步补偿任务来处理失败的更新,或者短期的数据不一致不会影响业务,那么只要下次更新时可以成功,能保证最终一致性就可以。缓存穿透缓存穿透。产生这个问题的原因可能是外部的恶意攻击,例如,对用户信息进行了缓存,但恶意攻击者使用不存在的用户id频繁请求接口,导致查询缓存不命中,然后穿透 DB 查询依然不命中。这时会有大量请求穿透缓存访问到 DB。解决的办法如下。对不存在的用户,在缓存中保存一个空对象进行标记,防止相同 ID 再次访问 DB。不过有时这个方法并不能很好解决问题,可能导致缓存中存储大量无用数据。使用 BloomFilter 过滤器,BloomFilter 的特点是存在性检测,如果 BloomFilter 中不存在,那么数据一定不存在;如果 BloomFilter 中存在,实际数据也有可能会不存在。非常适合解决这类的问题。缓存击穿缓存击穿,就是某个热点数据失效时,大量针对这个数据的请求会穿透到数据源。解决这个问题有如下办法。可以使用互斥锁更新,保证同一个进程中针对同一个数据不会并发请求到 DB,减小 DB 压力。使用随机退避方式,失效时随机 sleep 一个很短的时间,再次查询,如果失败再执行更新。针对多个热点 key 同时失效的问题,可以在缓存时使用固定时间加上一个小的随机数,避免大量热点 key 同一时刻失效。缓存雪崩缓存雪崩,产生的原因是缓存挂掉,这时所有的请求都会穿透到 DB。解决方法:使用快速失败的熔断策略,减少 DB 瞬间压力;使用主从模式和集群模式来尽量保证缓存服务的高可用。实际场景中,这两种方法会结合使用。老朋友都知道为啥我没有大篇幅介绍这个几个点了吧,我在之前的文章实在是写得太详细了,忍不住点赞那种,我这里就不做重复拷贝了。《吊打面试官》系列-Redis基础《吊打面试官》系列-缓存雪崩、击穿、穿透《吊打面试官》系列-Redis哨兵、持久化、主从、手撕LRU《吊打面试官》系列-Redis终章考点与加分项拿笔记一下!考点面试的时候问你缓存,主要是考察缓存特性的理解,对 MC、Redis 的特点和使用方式的掌握。要知道缓存的使用场景,不同类型缓存的使用方式,例如:- 对 DB 热点数据进行缓存减少 DB 压力;对依赖的服务进行缓存,提高并发性能;- 单纯 K-V 缓存的场景可以使用 MC,而需要缓存 list、set 等特殊数据格式,可以使用 Redis;- 需要缓存一个用户最近播放视频的列表可以使用 Redis 的 list 来保存、需要计算排行榜数据时,可以使用 Redis 的 zset 结构来保存。要了解 MC 和 Redis 的常用命令,例如原子增减、对不同数据结构进行操作的命令等。了解 MC 和 Redis 在内存中的存储结构,这对评估使用容量会很有帮助。了解 MC 和 Redis 的数据失效方式和剔除策略,比如主动触发的定期剔除和被动触发延期剔除要理解 Redis 的持久化、主从同步与 Cluster 部署的原理,比如 RDB 和 AOF 的实现方式与区别。要知道缓存穿透、击穿、雪崩分别的异同点以及解决方案。不管你有没有电商经验我觉得你都应该知道秒杀的具体实现,以及细节点。……..加分项如果想要在面试中获得更好的表现,还应了解下面这些加分项。是要结合实际应用场景来介绍缓存的使用。例如调用后端服务接口获取信息时,可以使用本地+远程的多级缓存;对于动态排行榜类的场景可以考虑通过 Redis 的 Sorted set 来实现等等。最好你有过分布式缓存设计和使用经验,例如项目中在什么场景使用过 Redis,使用了什么数据结构,解决哪类的问题;使用 MC 时根据预估值大小调整 McSlab 分配参数等等。最好可以了解缓存使用中可能产生的问题。比如 Redis 是单线程处理请求,应尽量避免耗时较高的单个请求任务,防止相互影响;Redis 服务应避免和其他 CPU 密集型的进程部署在同一机器;或者禁用 Swap 内存交换,防止 Redis 的缓存数据交换到硬盘上,影响性能。再比如前面提到的 MC 钙化问题等等。要了解 Redis 的典型应用场景,例如,使用 Redis 来实现分布式锁;使用 Bitmap 来实现 BloomFilter,使用 HyperLogLog 来进行 UV 统计等等。知道 Redis4.0、5.0 中的新特性,例如支持多播的可持久化消息队列 Stream;通过 Module 系统来进行定制功能扩展等等。……..总结这次是对我Redis系列的总结,这应该是Redis相关的最后一篇文章了,其实四篇看下来的小伙伴很多都从一知半解到了一脸懵逼,哈哈开个玩笑。
2020年07月06日
185 阅读
0 评论
0 点赞
2020-07-04
《吊打面试官》系列-缓存雪崩、击穿、穿透
你知道的越多,你不知道的越多前言Redis在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次offer的面霸(请允许我使用一下夸张的修辞手法),打败了无数竞争对手,每次都只能看到无数落寞的身影失望的离开,略感愧疚,在一个寂寞难耐的夜晚,我痛定思痛,决定开始写《吊打面试官》系列,希望能帮助各位读者以后面试势如破竹,对面试官进行360°的反击,吊打问你的面试官,让一同面试的同僚瞠目结舌,疯狂收割大厂offer!正文上一期吊打系列我们提到了Redis的基础知识,还没看的小伙伴可以回顾一下《吊打面试官》系列-Redis基础那提到Redis我相信各位在面试,或者实际开发过程中对缓存雪崩,穿透,击穿也不陌生吧,就算没遇到过但是你肯定听过,那三者到底有什么区别,我们又应该怎么去防止这样的情况发生呢,我们有请下一位受害者。面试开始一个大腹便便,穿着格子衬衣的中年男子,拿着一个满是划痕的mac向你走来,看着快秃顶的头发,心想着肯定是尼玛顶级架构师吧!但是我们腹有诗书气自华,虚都不虚。小伙子我看你的简历上写到了Redis,那么我们直接开门见山,直接怼常见的几个大问题,Redis雪崩了解么?帅气迷人的面试官您好,我了解的,目前电商首页以及热点数据都会去做缓存 ,一般缓存都是定时任务去刷新,或者是查不到之后去更新的,定时任务刷新就有一个问题。举个简单的例子:如果所有首页的Key失效时间都是12小时,中午12点刷新的,我零点有个秒杀活动大量用户涌入,假设当时每秒 6000 个请求,本来缓存在可以扛住每秒 5000 个请求,但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库,数据库必然扛不住,它会报一下警,真实情况可能DBA都没反应过来就直接挂了。此时,如果没用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。我刻意看了下我做过的项目感觉再吊的都不允许这么大的QPS直接打DB去,不过没慢SQL加上分库,大表分表可能还还算能顶,但是跟用了Redis的差距还是很大同一时间大面积失效,那一瞬间Redis跟没有一样,那这个数量级别的请求直接打到数据库几乎是灾难性的,你想想如果打挂的是一个用户服务的库,那其他依赖他的库所有的接口几乎都会报错,如果没做熔断等策略基本上就是瞬间挂一片的节奏,你怎么重启用户都会把你打挂,等你能重启的时候,用户早就睡觉去了,并且对你的产品失去了信心,什么垃圾产品。面试官摸了摸自己的头发,嗯还不错,那这种情况咋整?你都是怎么去应对的?处理缓存雪崩简单,在批量往Redis存数据的时候,把每个Key的失效时间都加个随机值就好了,这样可以保证数据不会在同一时间大面积失效,我相信,Redis这点流量还是顶得住的。setRedis(Key,value,time + Math.random() * 10000);如果Redis是集群部署,将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题,不过本渣我在生产环境中操作集群的时候,单个服务都是对应的单个Redis分片,是为了方便数据的管理,但是也同样有了可能会失效这样的弊端,失效时间随机是个好策略。或者设置热点数据永远不过期,有更新操作就更新缓存就好了(比如运维更新了首页商品,那你刷下缓存就完事了,不要设置过期时间),电商首页的数据也可以用这个操作,保险。那你了解缓存穿透和击穿么,可以说说他们跟雪崩的区别么?嗯,了解,我先说一下缓存穿透吧,缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,我们数据库的 id 都是1开始自增上去的,如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大,严重会击垮数据库。小点的单机系统,基本上用postman就能搞死,比如我自己买的阿里云服务像这种你如果不对参数做校验,数据库id都是大于0的,我一直用小于0的参数去请求你,每次都能绕开Redis直接打到数据库,数据库也查不到,每次都这样,并发高点就容易崩掉了。至于缓存击穿嘛,这个跟缓存雪崩有点像,但是又有一点不一样,缓存雪崩是因为大面积的缓存失效,打崩了DB,而缓存击穿不同的是缓存击穿是指一个Key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个Key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个完好无损的桶上凿开了一个洞。面试官露出欣慰的眼光,那他们分别怎么解决缓存穿透我会在接口层增加校验,比如用户鉴权校验,参数做校验,不合法的参数直接代码Return,比如:id 做基础校验,id <=0的直接拦截等。这里我想提的一点就是,我们在开发程序的时候都要有一颗“不信任”的心,就是不要相信任何调用方,比如你提供了API接口出去,你有这几个参数,那我觉得作为被调用方,任何可能的参数情况都应该被考虑到,做校验,因为你不相信调用你的人,你不知道他会传什么参数给你。举个简单的例子,你这个接口是分页查询的,但是你没对分页参数的大小做限制,调用的人万一一口气查 Integer.MAX_VALUE 一次请求就要你几秒,多几个并发你不就挂了么?是公司同事调用还好大不了发现了改掉,但是如果是黑客或者竞争对手呢?在你双十一当天就调你这个接口会发生什么,就不用我说了吧。这是之前的Leader跟我说的,我觉得大家也都应该了解下。从缓存取不到的数据,在数据库中也没有取到,这时也可以将对应Key的Value对写为null、位置错误、稍后重试这样的值具体取啥问产品,或者看具体的场景,缓存有效时间可以设置短点,如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击,但是我们要知道正常用户是不会在单秒内发起这么多次请求的,那网关层Nginx本渣我也记得有配置项,可以让运维大大对单个IP每秒访问次数超出阈值的IP都拉黑。那你还有别的办法么?还有我记得Redis还有一个高级用法布隆过滤器(Bloom Filter)这个也能很好的防止缓存穿透的发生,他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在,不存在你return就好了,存在你就去查了DB刷新KV再return。那又有小伙伴说了如果黑客有很多个IP同时发起攻击呢?这点我一直也不是很想得通,但是一般级别的黑客没这么多肉鸡,再者正常级别的Redis集群都能抗住这种级别的访问的,小公司我想他们不会感兴趣的。把系统的高可用做好了,集群还是很能顶的。缓存击穿的话,设置热点数据永远不过期。或者加上互斥锁就能搞定了作为暖男,代码我肯定帮你们准备好了面试结束嗯嗯还不错,三个点都回答得很好,今天也不早了,面试就先到这里,明天你再过来二面我继续问一下你关于Redis集群高可用,主从同步,哨兵等知识点的问题。晕居然还有下一轮面试!(强行下一期的伏笔哈哈)但是为了offer还是得舔,嗯嗯,好的帅气面试官。总结我们玩归玩,闹归闹,别拿面试开玩笑。本文简单的介绍了,Redis的雪崩,击穿,穿透,三者其实都差不多,但是又有一些区别,在面试中其实这是问到缓存必问的,大家不要把三者搞混了,因为缓存雪崩、穿透和击穿,是缓存最大的问题,要么不出现,一旦出现就是致命性的问题,所以面试官一定会问你。大家一定要理解是怎么发生的,以及是怎么去避免的,发生之后又怎么去抢救,你可以不是知道很深入,但是你不能一点都不去想,面试有时候不一定是对知识面的拷问,或许是对你的态度的拷问,如果你思路清晰,然后知其然还知其所以然那就很赞,还知道怎么预防那来上班吧。最后暖男我继续给你们做个小的技术总结:一般避免以上情况发生我们从三个时间段去分析下:事前:Redis 高可用,主从+哨兵,Redis cluster,避免全盘崩溃。事中:本地 ehcache 缓存 + Hystrix 限流+降级,避免 MySQL 被打死。事后:Redis 持久化 RDB+AOF,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。上面的几点我会在吊打系列Redis篇全部讲一下这个月应该可以吧Redis更完,限流组件,可以设置每秒的请求,有多少能通过组件,剩余的未通过的请求,怎么办?走降级!可以返回一些默认的值,或者友情提示,或者空白的值。好处:数据库绝对不会死,限流组件确保了每秒只有多少个请求能通过。 只要数据库不死,就是说,对用户来说,3/5 的请求都是可以被处理的。 只要有 3/5 的请求可以被处理,就意味着你的系统没死,对用户来说,可能就是点击几次刷不出来页面,但是多点几次,就可以刷出来一次。这个在目前主流的互联网大厂里面是最常见的,你是不是好奇,某明星爆出什么事情,你发现你去微博怎么刷都空白界面,但是有的人又直接进了,你多刷几次也出来了,现在知道了吧,那是做了降级,牺牲部分用户的体验换来服务器的安全,可还行?
2020年07月04日
152 阅读
0 评论
0 点赞
2020-07-04
《吊打面试官》系列- Redis基础
你知道的越多,你不知道的越多前言Redis在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次Offer的面霸,打败了无数竞争对手,每次都只能看到无数落寞的身影失望的离开,略感愧疚(请允许我使用一下夸张的修辞手法)。于是在一个寂寞难耐的夜晚,我痛定思痛,决定开始写《吊打面试官》系列,希望能帮助各位读者以后面试势如破竹,对面试官进行360°的反击,吊打问你的面试官,让一同面试的同僚瞠目结舌,疯狂收割大厂Offer!面试开始一个大腹便便,穿着格子衬衣的中年男子,拿着一个满是划痕的mac向你走来,看着快秃顶的头发,心想着肯定是尼玛顶级架构师吧!但是我们腹有诗书气自华,虚都不虚。小伙子您好,看你简历上写了你项目里面用到了Redis,你们为啥用Redis?心里忍不住暗骂,这叫啥问题,大家不都是用的这个嘛,但是你不能说出来。认真回答道:帅气迷人的面试官您好,因为传统的关系型数据库如Mysql已经不能适用所有的场景了,比如秒杀的库存扣减,APP首页的访问流量高峰等等,都很容易把数据库打崩,所以引入了缓存中间件,目前市面上比较常用的缓存中间件有Redis 和 Memcached 不过中和考虑了他们的优缺点,最后选择了Redis。至于更细节的对比朋友们记得查阅Redis 和 Memcached 的区别,比如两者的优缺点对比和各自的场景,后续我有时间也会写出来。那小伙子,我再问你,Redis有哪些数据结构呀?字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。这里我相信99%的读者都能回答上来Redis的5个基本数据类型。如果回答不出来的小伙伴我们就要加油补课哟,大家知道五种类型最适合的场景更好。但是,如果你是Redis中高级用户,而且你要在这次面试中突出你和其他候选人的不同,还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。如果你还想加分,那你说还玩过Redis Module,像BloomFilter,RedisSearch,Redis-ML,这个时候面试官得眼睛就开始发亮了,心想这个小伙子有点东西啊。**注:本人在面试回答到Redis相关的问题的时候,经常提到BloomFilter(布隆过滤器)这玩意的使用场景是真的多,而且用起来是真的香,原理也好理解,看一下文章就可以在面试官面前侃侃而谈了。****如果有大量的key需要设置同一时间过期,一般需要注意什么?如果大量的key过期时间设置的过于集中,到过期的那个时间点,redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩,我们一般需要在时间上加一个随机值,使得过期时间分散一些。电商首页经常会使用定时任务刷新缓存,可能大量的数据失效时间都十分集中,如果失效时间一样,又刚好在失效的时间点大量用户涌入,就有可能造成缓存雪崩那你使用过Redis分布式锁么,它是什么回事?先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。这时候对方会告诉你说你回答得不错,然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样?这时候你要给予惊讶的反馈:唉,是喔,这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋,故作思考片刻,好像接下来的结果是你主动思考出来的,然后回答:我记得set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成一条指令来用的!对方这时会显露笑容,心里开始默念:嗯,这小子还不错,开始有点意思了。假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如何将它们全部找出来?使用keys指令可以扫出指定模式的key列表。对方接着追问:如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?这个时候你要回答redis关键的一个特性:redis的单线程的。keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长。不过,增量式迭代命令也不是没有缺点的: 举个例子, 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素, 但是对于 SCAN 这类增量式迭代命令来说, 因为在对键进行增量式迭代的过程中, 键可能会被修改, 所以增量式迭代命令只能对被返回的元素提供有限的保证 。使用过Redis做异步队列么,你是怎么用的?一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。如果对方追问可不可以不用sleep呢?list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。如果对方接着追问能不能生产一次消费多次呢?使用pub/sub主题订阅者模式,可以实现 1:N 的消息队列。如果对方继续追问 pub/su b有什么缺点?在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如RocketMQ等。如果对方究极TM追问Redis如何实现延时队列?这一套连招下来,我估计现在你很想把面试官一棒打死(面试官自己都想打死自己了怎么问了这么多自己都不知道的),如果你手上有一根棒球棍的话,但是你很克制。平复一下激动的内心,然后神态自若的回答道:使用sortedset,拿时间戳作为score,消息内容作为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。到这里,面试官暗地里已经对你竖起了大拇指。并且已经默默给了你A+,但是他不知道的是此刻你却竖起了中指,在椅子背后。Redis是怎么持久化的?服务主从数据怎么交互的?RDB做镜像全量持久化,AOF做增量持久化。因为RDB会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要AOF来配合使用。在redis实例重启时,会使用RDB持久化文件重新构建内存,再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。这里很好理解,把RDB理解为一整个表全量的数据,AOF理解为每次操作的日志就好了,服务器重启的时候先把表的数据全部搞进去,但是他可能不完整,你再回放一下日志,数据不就完整了嘛。不过Redis本身的机制是 AOF持久化开启且存在AOF文件时,优先加载AOF文件;AOF关闭或者AOF文件不存在时,加载RDB文件;加载AOF/RDB文件城后,Redis启动成功; AOF/RDB文件存在错误时,Redis启动失败并打印错误信息对方追问那如果突然机器掉电会怎样?取决于AOF日志sync属性的配置,如果不要求性能,在每条写指令时都sync一下磁盘,就不会丢失数据。但是在高性能的要求下每次都sync是不现实的,一般都使用定时sync,比如1s1次,这个时候最多就会丢失1s的数据。对方追问RDB的原理是什么?你给出两个词汇就可以了,fork和cow。fork是指redis通过创建子进程来进行RDB操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。注:回答这个问题的时候,如果你还能说出AOF和RDB的优缺点,我觉得我是面试官在这个问题上我会给你点赞,两者其实区别还是很大的,而且涉及到Redis集群的数据同步问题等等。想了解的伙伴也可以留言,我会专门写一篇来介绍的。 **Pipeline有什么好处,为什么要用pipeline?可以将多次IO往返的时间缩减为一次,前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。Redis的同步机制了解么?Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将RDB文件全量同步到复制节点,复制节点接受完成后将RDB镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。后续的增量数据通过AOF日志同步即可,有点类似数据库的binlog。是否使用过Redis集群,集群的高可用怎么保证,集群的原理是什么?Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。面试结束小伙子你可以的,什么时候有时间来上班啊,要不明天就来吧?你强装镇定,这么急啊我还需要租房,要不下礼拜一吧。好的 心想这小子这么NB是不是很多Offer在手上,不行我得叫hr给他加钱。能撑到最后,你自己都忍不住自己给自己点个赞了!(暗示点赞,每次都看了不点赞,你们想白嫖我么?你们好坏喲,不过我喜欢)。总结在技术面试的时候,不管是Redis还是什么问题,如果你能举出实际的例子,或者是直接说自己开发过程的问题和收获会给面试官的印象分会加很多,回答逻辑性也要强一点,不要东一点西一点,容易把自己都绕晕的。还有一点就是我问你为啥用Redis你不要一上来就直接回答问题了,你可以这样回答:帅气的面试官您好,首先我们的项目DB遇到了瓶颈,特别是秒杀和热点数据这样的场景DB基本上就扛不住了,那就需要缓存中间件的加入了,目前市面上有的缓存中间件有 Redis 和 Memcached ,他们的优缺点......,综合这些然后再结合我们项目特点,最后我们在技术选型的时候选了谁。如果你这样有条不紊,有理有据的回答了我的问题而且还说出这么多我问题外的知识点,我会觉得你不只是一个会写代码的人,你逻辑清晰,你对技术选型,对中间件对项目都有自己的理解和思考,说白了就是你的offer有戏了。
2020年07月04日
215 阅读
0 评论
0 点赞