Redis面试题归纳
为什么使用 Redis在项目中使用 Redis,主要考虑两个角度:性能和并发。如果只是为了分布式锁这些其他功能,还有其他中间件 Zookpeer 等代替,并非一定要使用 Redis。
性能:
如下图所示,我们在碰到需要执行耗时特别久,且结果不频繁变动的 SQL,就特别适合将运行结果放入缓存。这样,后面的请求就去缓存中读取,使得请求能够迅速响应。
特别是在秒杀系统,在同一时间,几乎所有人都在点,都在下单。。。执行的是同一操作———向数据库查数据。
根据交互效果的不同,响应时间没有固定标准。在理想状态下,我们的页面跳转需要在瞬间解决,对于页内操作则需要在刹那间解决。
并发
如下图所示,在大并发的情况下,所有的请求直接访问数据库,数据库会出现连接异常。这个时候,就需要使用 Redis 做一个缓冲操作,让请求先访问到 Redis,而不是直接访问数据库。
使用 Redis 的常见问题
缓存和数据库双写一致性问题
缓存雪崩问题
缓存击穿问题
缓存的并发竞争问题
单线程的 Redis 为什么这么快这个问题是对 Redis 内部机制的一个考察。很多人都不知道 Redis 是单线程工作 ...
Redis过期策略实现原理
在使用redis时,一般会设置一个过期时间,当然也有不设置过期时间的,也就是永久不过期。
当我们设置了过期时间,redis是如何判断是否过期,以及根据什么策略来进行删除的。
redis设置过期时间expire key time(以秒为单位)–这是最常用的方式
setex(String key, int seconds, String value)–字符串独有的方式
注:
除了字符串自己独有设置过期时间的方法外,其他方法都需要依靠expire方法来设置时间
如果没有设置时间,那缓存就是永不过期
如果设置了过期时间,之后又想让缓存永不过期,使用persist key
三种过期策略:定时删除含义:在设置key的过期时间的同时,为该key创建一个定时器,让定时器在key的过期时间来临时,对key进行删除
优点:保证内存被尽快释放
缺点:若过期key很多,删除这些key会占用很多的CPU时间,在CPU时间紧张的情况下,CPU不能把所有的时间用来做要紧的事儿,还需要去花时间删除这些key定时器的创建耗时,若为每一个设置过期时间的key创建一个定时器(将会有大量的定时器产生),性能影响严重 ...
Mycat分库分表实战
准备
准备数据库服务,这里作为学习用,我们就用一个数据库服务。dhost1: localhost
在dhost1服务创建三个数据库123CREATE DATABASE db1 CHARACTER SET 'utf8'; CREATE DATABASE db2 CHARACTER SET 'utf8'; CREATE DATABASE db3 CHARACTER SET 'utf8';
配置好dataHost dataNode12345678910111213<mycat:schema xmlns:mycat="http://io.mycat/"> <!-- 注意:里面的元素一定要按 schema 、dataNode 、 dataHost的顺序配置 -->0 <schema name="mydb" checkSQLschema="true" sqlMaxLimit="100" dataNode="dn2& ...
InnoDB为什么要选择B+树来存储数据
关于InnoDB索引,我们可能知道InnDB索引是用B+树实现的,而B+树就是一种能优化查询速度的数据结构。但我们又没想过这样一个问题,能优化查询速度的数据结构有很多,为什么InnoDB要采用B+树?
常见优化查询速度数据结构哈希表哈希表是一种以键 - 值(key-value)存储数据的结构,我们只要输入待查找的键即 key,就可以找到其对应的值即 Value。哈希的思路很简单,把值放在数组里,用一个哈希函数把 key 换算成一个确定的位置,然后把 value 放在数组的这个位置。
不可避免地,多个 key 值经过哈希函数的换算,会出现同一个值的情况。处理这种情况的一种方法是,拉出一个链表。
假设现在维护着一个身份证信息和姓名的表,需要根据身份证号查找对应的名字,这时对应的哈希索引的示意图如下所示:
图中,User2 和 User4 根据身份证号算出来的值都是 N,但没关系,后面还跟了一个链表。假设,这时候你要查 ID_card_n2 对应的名字是什么,处理步骤就是:首先,将 ID_card_n2 通过哈希函数算出 N;然后,按顺序遍历,找到 User2。
需要注意的是,图中四个 ...
MQ使用总结(五)如何保证消息队列的高可用
RabbitMQ的高可用RabbitMQ基于主从模式实现高可用。RabbitMQ有三种模式:单机模式,普通集群模式,镜像集群模式。
单机模式:单机模式就是demo级别的,生产中不会有人使用。
普通集群模式普通集群模式就是在多台机器上启动多个rabbitmq实例,每个机器启动一个。但是创建的queue只会放在一个rabbitmq实例上面,但是其他的实例都同步了这个queue的元数据。在你消费的时候,如果连接到了另一个实例,他会从拥有queue的那个实例获取消息然后再返回给你。
这种方式并没有做到所谓消息的高可用,就是个普通的集群,这样还会导致要么消费者每次随机连接一个实例然后拉取数据,这样的话在实例之间会产生网络传输,增加系统开销,要么固定连接那个queue所在的实例消费,这样会导致单实例的性能瓶颈。
而且如果那个放queue的实例宕机了,会导致接下来其他实例都无法拉取数据;如果没有开启消息的持久化会丢失消息;就算开启了消息的持久化,消息不一定会丢,但是也要等这个实例恢复了,才可以继续拉取数据。所以这个并没有提供高可用,这种方案只是提高了吞吐量,也就是让集群中多个节点来服务某个que ...
MQ使用总结(四)如何保证消息不重复消费
幂等性
幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“setTrue()”函数就是一个幂等函数,无论多次执行,其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
简单来说,幂等性就是一个数据或者一个请求,给你重复来了多次,你得确保对应的数据是不会改变的,不能出错。
出现重复消费场景
首先,比如rabbitmq、rocketmq、kafka,都有可能会出现消息重复消费的问题。因为这个问题通常不是由mq来保证的,而是消费方自己来保证的。
举例kafka来说明重复消费问题:kafka有一个叫做offset的概念,就是每个消息写进去,都有一个offset代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次就算重启,kafk ...
MQ使用总结(三)如何保证消息不丢
mq原则数据不能多,也不能少,不能多是说消息不能重复消费。如果mq传递的是非常核心的消息,支撑核心的业务,那么这种场景是一定不能丢失数据的。
丢失数据场景丢数据一般分为两种,一种是mq把消息丢了,一种就是消费时将消息丢了。下面从rabbitmq和kafka分别说一下,丢失数据的场景。
rabbitmq生产者弄丢了数据生产者将数据发送到rabbitmq的时候,可能在传输过程中因为网络等问题而将数据弄丢了。
rabbitmq自己丢了数据如果没有开启rabbitmq的持久化,那么rabbitmq一旦重启,那么数据就丢了。所依必须开启持久化将消息持久化到磁盘,这样就算rabbitmq挂了,恢复之后会自动读取之前存储的数据,一般数据不会丢失。除非极其罕见的情况,rabbitmq还没来得及持久化自己就挂了,这样可能导致一部分数据丢失。
消费端弄丢了数据主要是因为消费者消费时,刚消费到,还没有处理,结果消费者就挂了,这样你重启之后,rabbitmq就认为你已经消费过了,然后就丢了数据。
kafka生产者弄丢了数据生产者没有设置相应的策略,发送过程中丢失数据。
kafka弄丢了数据比较常见的一个场 ...
MQ使用总结(二)消息积压在消息队列里怎么办
大量消息在mq里积压了几个小时了还没解决场景:几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多。线上故障了,这个时候要不然就是修复consumer的问题,让他恢复消费速度,然后傻傻的等待几个小时消费完毕。这个肯定不行。一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条。所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来。
解决方案:这种时候只能操作临时扩容,以更快的速度去消费数据了。具体操作步骤和思路如下:
先修复consumer的问题,确保其恢复消费速度,然后将现有consumer都停掉。
临时建立好原先10倍或者20倍的queue数量(新建一个topic,partition是原来的10倍)。
然后写一个临时分发消息的consumer程序,这个程序部署上去消费积压的消息,消费之后不做耗时处理,直接均匀轮询写入临时建好分10数量的queue里面。
紧接着征用10倍的机器来部署consumer,每一批consumer消费一个临时queue的消息。
这种做法相当 ...
MQ使用总结(一)如何保证消息按顺序执行
为什么要保证顺序消息队列中的若干消息如果是对同一个数据进行操作,这些操作具有前后的关系,必须要按前后的顺序执行,否则就会造成数据异常。举例:比如通过mysql binlog进行两个数据库的数据同步,由于对数据库的数据操作是具有顺序性的,如果操作顺序搞反,就会造成不可估量的错误。比如数据库对一条数据依次进行了 插入->更新->删除操作,这个顺序必须是这样,如果在同步过程中,消息的顺序变成了 删除->插入->更新,那么原本应该被删除的数据,就没有被删除,造成数据的不一致问题。
出现顺序错乱的场景rabbitmq
一个queue,有多个consumer去消费,这样就会造成顺序的错误,consumer从MQ里面读取数据是有序的,但是每个consumer的执行时间是不固定的,无法保证先读到消息的consumer一定先完成操作,这样就会出现消息并没有按照顺序执行,造成数据顺序错误。
一个queue对应一个consumer,但是consumer里面进行了多线程消费,这样也会造成消息消费顺序错误。
kafka
kafka一个topic,一个partition,一个 ...