redis基础面试

redis操作

brew services start redis 启动并前台运行
brew services stop redis 停止服务
redis-server /usr/local/etc/redis.conf 启动并后台运行
mysql -uroot 本地登录
brew services start mysql 前台
mysql.server start 后台

redis的功能

redis缓存,可用来做分布式锁,支持事务,持久化,lua脚本,lru事件驱动,多集群方案。

数据类型

  • string
  • list
  • set
  • hash
  • zset

具体使用场景

数据结构

字典:dictht

跳表:是有序集合的底层实现。

为什么用redis而不用map/guava

缓存分为本地缓存和分布式缓存。以 Java 为例,使用自带的 map 或者 guava 实现的是本地缓存,最主要的特点是轻量以及快速,生命周期随着 jvm 的销毁而结束,并且在多实例的情况下,每个实例都需要各自保存一份缓存,缓存不具有一致性。

使用 redis 或 memcached 之类的称为分布式缓存,在多实例的情况下,各实例共用一份缓存数据,缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用,整个程序架构上较为复杂。

redis和memcache的区别

  1. redis支持更丰富的数据类型string, list, set, zset,hash, memcache支持简单的数据类型String。
  2. Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
  3. 集群模式:memcached没有原生的集群模式,需要依靠客户端来实现往集群中分片写入数据;但是 redis 目前是原生支持 cluster 模式的。
  4. Memcached是多线程,非阻塞IO复用的网络模型;Redis使用单线程的多路 IO 复用模型。

redis过期时间

  1. 定期删除:redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key,检查其是否过期,如果过期就删除。
  2. 惰性删除:查询的时候再删。

redis内存淘汰机制(6种策略)

  1. Volatile-lru
  2. volatile-ttl
  3. volatile-random
  4. allkeys-lru
  5. allkeys-random
  6. no-eviction

redis持久化机制

Redis的一种持久化方式叫快照(snapshotting,RDB),另一种方式是只追加文件(append-only file,AOF)

RDB:从内存写入磁盘

AOF:记录操作的步骤

  1. Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。快照持久化是Redis默认采用的持久化方式。

  2. 与快照持久化相比,AOF持久化 的实时性更好,因此已成为主流的持久化方案。

Redis 4.0 开始支持 RDB 和 AOF 的混合持久化(默认关闭,可以通过配置项 aof-use-rdb-preamble 开启)。

redis事务

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。

缓存雪崩

缓存同一时间大面积的失效,所以,后面的请求都会落到数据库上,造成数据库短时间内承受大量请求而崩掉。

解决办法:

  • 事前:尽量保证整个 redis 集群的高可用性,发现机器宕机尽快补上。选择合适的内存淘汰策略。
  • 事中:本地ehcache缓存 + hystrix限流&降级,避免MySQL崩掉
  • 事后:利用 redis 持久化机制保存的数据尽快恢复缓存

缓存穿透

一般是黑客故意去请求缓存中不存在的数据,导致所有的请求都落到数据库上,造成数据库短时间内承受大量请求而崩掉。

解决办法: 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

跳表

与红黑树等平衡树相比,跳跃表具有以下优点:

  • 插入速度非常快速,因为不需要进行旋转等操作来维护平衡性;
  • 更容易实现;
  • 支持无锁操作。

memcache

仅支持字符串类型

哨兵

主从复制

git和SVN

git是分布式版本控制

svn是集中式版本控制

集中式版本控制只有中心服务器拥有一份代码,而分布式版本控制每个人的电脑上就有一份完整的代码。

集群

将多台服务器组成集群,使用负载均衡将请求转发到集群中,避免单一服务器的负载压力过大导致性能降低。

服务降级

服务降级是系统为了应对大量的请求,主动关闭部分功能,从而保证核心功能可用。

发布订阅模式

发布与订阅模式和观察者模式有以下不同:

  • 观察者模式中,观察者和主题都知道对方的存在;而在发布与订阅模式中,生产者与消费者不知道对方的存在,它们之间通过频道进行通信。
  • 观察者模式是同步的,当事件触发时,主题会调用观察者的方法,然后等待方法返回;而发布与订阅模式是异步的,生产者向频道发送一个消息之后,就不需要关心消费者何时去订阅这个消息,可以立即返回。

消息队列

使用场景:异步处理,流量削峰,应用接耦。

kafka

Kafka是一个分布式的消息发布-订阅系统,能够支撑海量数据的数据传递。

  • broker:Kafka服务器,负责消息存储和转发
  • topic:消息类别

redis分布式锁和实现

降级策略

Redis持久化方式、如何解决AOF文件过大的问题

消息中间件了解吗,说说为什么要用消息中间件

项目中的缓存不一致怎么解决的

redis内存满了会怎么样

Guess you like

Origin blog.csdn.net/SYaoJun/article/details/106976902