个人阿里面经，和面试官漫谈Redis，面试当谈笑风生

时间  2020-05-28 标签 个人 里面 面试 漫谈 redis 谈笑风生

本文转载自：个人阿里面经，和面试官漫谈Redis，面试当谈笑风生

今天，我蚍蜉撼树的面试了某大厂的java开发岗位，迎面走来一位风尘仆仆的中年男子，手里拿着屏幕还亮着的mac，他冲着我礼貌的笑了笑，而后说了句“很差意思，让你久等了”，而后示意我坐下，说：“咱们开始吧。看了你的简历，以为你对redis应该掌握的不错，咱们今天就来讨论下redis…”。我想：“来就来，兵来将挡水来土掩”。java

1、Redis是什么

面试官：你先来讲下redis是什么吧web

我：（这不就是总结下redis的定义和特色嘛）Redis是一种NoSQL（not-only sql，泛指非关系型数据库）的数据库。面试

我顿了一下，接着说：Redis做为一个内存数据库。redis

  1. 性能优秀，数据在内存中，读写速度很是快，支持并发10W QPS；
  2. 单进程单线程，是线程安全的，采用IO多路复用机制；
  3. 丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等；
  4. 支持数据持久化。能够将内存中数据保存在磁盘中，重启时加载；
  5. 主从复制，哨兵，高可用；
  6. 能够用做分布式锁；
  7. 能够做为消息中间件使用，支持发布订阅

2、五种数据类型

面试官：总结的不错，看来是早有准备啊。刚来听你提到redis支持五种数据类型，那你能简单说下这五种数据类型吗？算法

我：固然能够，可是在说以前，我以为有必要先来了解下Redis内部内存管理是如何描述这5种数据类型的。说着，我拿着笔给面试官画了一张图：spring

我：首先redis内部使用一个redisObject对象来表示全部的key和value，redisObject最主要的信息如上图所示：type表示一个value对象具体是何种数据类型，encoding是不一样数据类型在redis内部的存储方式。好比：type=string表示value存储的是一个普通字符串，那么encoding能够是raw或者int。sql

我顿了一下，接着说：下面我简单说下5种数据类型：数据库

  1. string是redis最基本的类型，能够理解成与memcached如出一辙的类型，一个key对应一个value。value不只是string，也能够是数字。string类型是二进制安全的，意思是redis的string类型能够包含任何数据，好比jpg图片或者序列化的对象。string类型的值最大能存储512M。express

  2. Hash是一个键值（key-value）的集合。redis的hash是一个string的key和value的映射表，Hash特别适合存储对象。经常使用命令：hget,hset,hgetall等。apache

  3. list列表是简单的字符串列表，按照插入顺序排序。能够添加一个元素到列表的头部（左边）或者尾部（右边） 经常使用命令：lpush、rpush、lpop、rpop、lrange(获取列表片断)等。

  • 应用场景：list应用场景很是多，也是Redis最重要的数据结构之一，好比twitter的关注列表，粉丝列表均可以用list结构来实现。
  • 数据结构：list就是链表，能够用来当消息队列用。redis提供了List的push和pop操做，还提供了操做某一段的api，能够直接查询或者删除某一段的元素。
  • 实现方式：redis list的是实现是一个双向链表，既能够支持反向查找和遍历，更方便操做，不过带来了额外的内存开销。
  1. set是string类型的无序集合。集合是经过hashtable实现的。set中的元素是没有顺序的，并且是没有重复的。
  • 经常使用命令：sdd、spop、smembers、sunion等。
  • 应用场景：redis set对外提供的功能和list同样是一个列表，特殊之处在于set是自动去重的，并且set提供了判断某个成员是否在一个set集合中。
  1. zset和set同样是string类型元素的集合，且不容许重复的元素。经常使用命令：zadd、zrange、zrem、zcard等。
  • 使用场景：sorted set能够经过用户额外提供一个优先级（score）的参数来为成员排序，而且是插入有序的，即自动排序。当你须要一个有序的而且不重复的集合列表，那么能够选择sorted set结构。和set相比，sorted set关联了一个double类型权重的参数score，使得集合中的元素可以按照score进行有序排列，redis正是经过分数来为集合中的成员进行从小到大的排序。
  • 实现方式：Redis sorted set的内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是全部的成员，排序依据是HashMap里存的score，使用跳跃表的结构能够得到比较高的查找效率，而且在实现上比较简单。

2.1 数据类型应用场景总结

面试官：想不到你平时也下了很多工夫，那redis缓存你必定用过的吧

我：用过的。。

面试官：那你跟我说下你是怎么用的？

我是结合spring boot使用的。通常有两种方式，一种是直接经过RedisTemplate来使用，另外一种是使用spring cache集成Redis（也就是注解的方式）

3、Redis缓存

直接经过RedisTemplate来使用

使用spring cache集成Redis pom.xml中加入如下依赖：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.session</groupId>
        <artifactId>spring-session-data-redis</artifactId>
    </dependency>

    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

spring-boot-starter-data-redis:在spring boot 2.x之后底层再也不使用Jedis，而是换成了Lettuce。

commons-pool2：用做redis链接池，如不引入启动会报错

spring-session-data-redis：spring session引入，用做共享session。配置文件application.yml的配置：

server:
  port: 8082
  servlet:
    session:
      timeout: 30ms
spring:
  cache:
    type: redis
  redis:
    host: 127.0.0.1
    port: 6379
    password:
    # redis默认状况下有16个分片，这里配置具体使用的分片，默认为0
    database: 0
    lettuce:
      pool:
        # 链接池最大链接数(使用负数表示没有限制),默认8
        max-active: 100

建立实体类User.java

public class User implements Serializable{

    private static final long serialVersionUID = 662692455422902539L;

    private Integer id;

    private String name;

    private Integer age;

    public User() {
    }

    public User(Integer id, String name, Integer age) {
        this.id = id;
        this.name = name;
        this.age = age;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }

    @Override
    public String toString() {
        return "User{" +
                "id=" + id +
                ", name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

3.1 RedisTemplate的使用方式

默认状况下的模板只能支持RedisTemplate<String, String>，也就是只能存入字符串，因此自定义模板颇有必要。添加配置类RedisCacheConfig.java

@Configuration
@AutoConfigureAfter(RedisAutoConfiguration.class)
public class RedisCacheConfig {

    @Bean
    public RedisTemplate<String, Serializable> redisCacheTemplate(LettuceConnectionFactory connectionFactory) {

        RedisTemplate<String, Serializable> template = new RedisTemplate<>();
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        template.setConnectionFactory(connectionFactory);
        return template;
    }
}

测试类

@RestController
@RequestMapping("/user")
public class UserController {

    public static Logger logger = LogManager.getLogger(UserController.class);

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Autowired
    private RedisTemplate<String, Serializable> redisCacheTemplate;

    @RequestMapping("/test")
    public void test() {
        redisCacheTemplate.opsForValue().set("userkey", new User(1, "张三", 25));
        User user = (User) redisCacheTemplate.opsForValue().get("userkey");
        logger.info("当前获取对象：{}", user.toString());
    }

而后在浏览器访问，观察后台日志http://localhost:8082/user/test

3.2 使用spring cache集成redis

spring cache具有很好的灵活性，不只可以使用SPEL(spring expression language)来定义缓存的key和各类condition，还提供了开箱即用的缓存临时存储方案，也支持和主流的专业缓存如EhCache、Redis、Guava的集成。

定义接口UserService.java

public interface UserService {

    User save(User user);

    void delete(int id);

    User get(Integer id);
}

接口实现类UserServiceImpl.java

@Service
public class UserServiceImpl implements UserService{

    public static Logger logger = LogManager.getLogger(UserServiceImpl.class);

    private static Map<Integer, User> userMap = new HashMap<>();
    static {
        userMap.put(1, new User(1, "肖战", 25));
        userMap.put(2, new User(2, "王一博", 26));
        userMap.put(3, new User(3, "杨紫", 24));
    }


    @CachePut(value ="user", key = "#user.id")
    @Override
    public User save(User user) {
        userMap.put(user.getId(), user);
        logger.info("进入save方法，当前存储对象：{}", user.toString());
        return user;
    }

    @CacheEvict(value="user", key = "#id")
    @Override
    public void delete(int id) {
        userMap.remove(id);
        logger.info("进入delete方法，删除成功");
    }

    @Cacheable(value = "user", key = "#id")
    @Override
    public User get(Integer id) {
        logger.info("进入get方法，当前获取对象：{}", userMap.get(id)==null?null:userMap.get(id).toString());
        return userMap.get(id);
    }
}

为了方便演示数据库的操做，这里直接定义了一个Map<Integer,User> userMap，这里的核心是三个注解@Cachable、@CachePut和@CacheEvict。

@RestController
@RequestMapping("/user")
public class UserController {

    public static Logger logger = LogManager.getLogger(UserController.class);

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Autowired
    private RedisTemplate<String, Serializable> redisCacheTemplate;

    @Autowired
    private UserService userService;

    @RequestMapping("/test")
    public void test() {
        redisCacheTemplate.opsForValue().set("userkey", new User(1, "张三", 25));
        User user = (User) redisCacheTemplate.opsForValue().get("userkey");
        logger.info("当前获取对象：{}", user.toString());
    }


    @RequestMapping("/add")
    public void add() {
        User user = userService.save(new User(4, "李现", 30));
        logger.info("添加的用户信息：{}",user.toString());
    }

    @RequestMapping("/delete")
    public void delete() {
        userService.delete(4);
    }

    @RequestMapping("/get/{id}")
    public void get(@PathVariable("id") String idStr) throws Exception{
        if (StringUtils.isBlank(idStr)) {
            throw new Exception("id为空");
        }
        Integer id = Integer.parseInt(idStr);
        User user = userService.get(id);
        logger.info("获取的用户信息：{}",user.toString());
    }
}

用缓存要注意，启动类要加上一个注解开启缓存

@SpringBootApplication(exclude=DataSourceAutoConfiguration.class)
@EnableCaching
public class Application {

	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}

}

一、先调用添加接口：http://localhost:8082/user/add

二、再调用查询接口，查询id=4的用户信息：

能够看出，这里已经从缓存中获取数据了，由于上一步add方法已经把id=4的用户数据放入了redis缓存

三、调用删除方法，删除id=4的用户信息，同时清除缓存

四、再次调用查询接口，查询id=4的用户信息：

没有了缓存，因此进入了get方法，从userMap中获取。

3.3 缓存注解

一、@Cacheable
根据方法的请求参数对其结果进行缓存

  • key：缓存的key，能够为空，若是指定要按照SPEL表达式编写，若是不指定，则按照方法的全部参数进行组合。
  • value：缓存的名称，必须指定至少一个（如 @Cacheable (value=‘user’)或者@Cacheable(value={‘user1’,‘user2’})）
  • condition：缓存的条件，能够为空，使用SPEL编写，返回true或者false，只有为true才进行缓存。

二、@CachePut
根据方法的请求参数对其结果进行缓存，和@Cacheable不一样的是，它每次都会触发真实方法的调用。参数描述见上。

三、@CacheEvict
根据条件对缓存进行清空

  • key：同上
  • value：同上
  • condition：同上
  • allEntries：是否清空全部缓存内容，缺省为false，若是指定为true，则方法调用后将当即清空全部缓存
  • beforeInvocation：是否在方法执行前就清空，缺省为false，若是指定为true，则在方法尚未执行的时候就清空缓存。缺省状况下，若是方法执行抛出异常，则不会清空缓存。

4、缓存问题

面试官：看了一下你的demo，简单易懂。那你在实际项目中使用缓存有遇到什么问题或者会遇到什么问题你知道吗？

我：缓存和数据库数据一致性问题：分布式环境下很是容易出现缓存和数据库间数据一致性问题，针对这一点，若是项目对缓存的要求是强一致性的，那么就不要使用缓存。咱们只能采起合适的策略来下降缓存和数据库间数据不一致的几率，而没法保证二者间的强一致性。合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增长重试机制。

面试官：Redis雪崩了解吗？

我：我了解的，目前电商首页以及热点数据都会去作缓存，通常缓存都是定时任务去刷新，或者查不到以后去更新缓存的，定时任务刷新就有一个问题。举个栗子：若是首页全部Key的失效时间都是12小时，中午12点刷新的，我零点有个大促活动大量用户涌入，假设每秒6000个请求，原本缓存能够抗住每秒5000个请求，可是缓存中全部Key都失效了。此时6000个/秒的请求所有落在了数据库上，数据库必然扛不住，真实状况可能DBA都没反应过来直接挂了，此时，若是没什么特别的方案来处理，DBA很着急，重启数据库，可是数据库立马又被新流量给打死了。这就是我理解的缓存雪崩。

我心想：同一时间大面积失效，瞬间Redis跟没有同样，那这个数量级别的请求直接打到数据库几乎是灾难性的，你想一想若是挂的是一个用户服务的库，那其余依赖他的库全部接口几乎都会报错，若是没作熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂，等你重启好的时候，用户早睡觉去了，临睡以前，骂骂咧咧“什么垃圾产品”。

面试官摸摸了本身的头发：嗯，还不错，那这种状况你都是怎么应对的？

我：处理缓存雪崩简单，在批量往Redis存数据的时候，把每一个Key的失效时间都加个随机值就行了，这样能够保证数据不会再同一时间大面积失效。

setRedis（key, value, time+Math.random()*10000）;

若是Redis是集群部署，将热点数据均匀分布在不一样的Redis库中也能避免所有失效。或者设置热点数据永不过时，有更新操做就更新缓存就行了（好比运维更新了首页商品，那你刷下缓存就行了，不要设置过时时间），电商首页的数据也能够用这个操做，保险。

面试官：那你了解缓存穿透和击穿么，能够说说他们跟雪崩的区别吗？

我：嗯，了解，先说下缓存穿透吧，缓存穿透是指缓存和数据库中都没有的数据，而用户（黑客）不断发起请求，举个栗子：咱们数据库的id都是从1自增的，若是发起id=-1的数据或者id特别大不存在的数据，这样的不断攻击致使数据库压力很大，严重会击垮数据库。

我又接着说：至于缓存击穿嘛，这个跟缓存雪崩有点像，可是又有一点不同，缓存雪崩是由于大面积的缓存失效，打崩了DB，而缓存击穿不一样的是缓存击穿是指一个Key很是热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发直接落到了数据库上，就在这个Key的点上击穿了缓存。

面试官露出欣慰的眼光：那他们分别怎么解决？

我：缓存穿透我会在接口层增长校验，好比用户鉴权，参数作校验，不合法的校验直接return，好比id作基础校验，id<=0直接拦截。

面试官：那你还有别的方法吗？

我：我记得Redis里还有一个高级用法**布隆过滤器（Bloom Filter）**这个也能很好的预防缓存穿透的发生，他的原理也很简单，就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就行了，存在你就去查DB刷新KV再return。缓存击穿的话，设置热点数据永不过时，或者加上互斥锁就搞定了。做为暖男，代码给你准备好了，拿走不谢。

public static String getData(String key) throws InterruptedException {
        //从Redis查询数据
        String result = getDataByKV(key);
        //参数校验
        if (StringUtils.isBlank(result)) {
            try {
                //得到锁
                if (reenLock.tryLock()) {
                    //去数据库查询
                    result = getDataByDB(key);
                    //校验
                    if (StringUtils.isNotBlank(result)) {
                        //插进缓存
                        setDataToKV(key, result);
                    }
                } else {
                    //睡一会再拿
                    Thread.sleep(100L);
                    result = getData(key);
                }
            } finally {
                //释放锁
                reenLock.unlock();
            }
        }
        return result;
    }

面试官：嗯嗯，还不错。

5、Redis为什么这么快

面试官：redis做为缓存你们都在用，那redis必定很快咯？

我：固然了，官方提供的数据能够达到100000+的QPS（每秒内的查询次数），这个数据不比Memcached差！

面试官：redis这么快，它的“多线程模型”你了解吗？（露出邪魅一笑）

我：您是想问Redis这么快，为何仍是单线程的吧。Redis确实是单进程单线程的模型，由于Redis彻底是基于内存的操做，CPU不是Redis的瓶颈，Redis的瓶颈最有多是机器内存的大小或者网络带宽。既然单线程容易实现，并且CPU不会成为瓶颈，那就瓜熟蒂落的采用单线程的方案了（毕竟采用多线程会有不少麻烦）。

面试官：嗯，是的。那你能说说Redis是单线程的，为何还能这么快吗？

我：能够这么说吧。

  • 第一：Redis彻底基于内存，绝大部分请求是纯粹的内存操做，很是迅速，数据存在内存中，相似于HashMap，HashMap的优点就是查找和操做的时间复杂度是O(1)。
  • 第二：数据结构简单，对数据操做也简单。
  • 第三：采用单线程，避免了没必要要的上下文切换和竞争条件，不存在多线程致使的CPU切换，不用去考虑各类锁的问题，不存在加锁释放锁操做，没有死锁问题致使的性能消耗。
  • 第四：使用多路复用IO模型，非阻塞IO。

6、Redis和Memcached的区别

面试官：嗯嗯，说的很详细。那你为何选择Redis的缓存方案而不用memcached呢

我：

  1. 存储方式上：memcache会把数据所有存在内存之中，断电后会挂掉，数据不能超过内存大小。redis有部分数据存在硬盘上，这样能保证数据的持久性。
  2. 数据支持类型上：memcache对数据类型的支持简单，只支持简单的key-value，，而redis支持五种数据类型。
  3. 使用底层模型不一样：它们之间底层实现方式以及与客户端之间通讯的应用协议不同。redis直接本身构建了VM机制，由于通常的系统调用系统函数的话，会浪费必定的时间去移动和请求。
  4. value的大小：redis能够达到1GB，而memcache只有1MB。

7、淘汰策略

面试官：那你说说你知道的redis的淘汰策略有哪些？

我：Redis有六种淘汰策略

补充一下：Redis4.0加入了LFU(least frequency use)淘汰策略，包括volatile-lfu和allkeys-lfu，经过统计访问频率，将访问频率最少，即最不常用的KV淘汰。

8、持久化

面试官：你对redis的持久化机制了解吗？能讲一下吗？

我：redis为了保证效率，数据缓存在了内存中，可是会周期性的把更新的数据写入磁盘或者把修改操做写入追加的记录文件中，以保证数据的持久化。Redis的持久化策略有两种：

  1. RDB：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存，保存策略。
  2. AOF：把全部的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。Redis默认是快照RDB的持久化方式。

当Redis重启的时候，它会优先使用AOF文件来还原数据集，由于AOF文件保存的数据集一般比RDB文件所保存的数据集更完整。你甚至能够关闭持久化功能，让数据只在服务器运行时存。

面试官：那你再说下RDB是怎么工做的？

我：默认Redis是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件dump.rdb。工做原理简单说一下：当Redis须要作持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处是能够copy-on-write。

我：RDB的优势是：这种文件很是适合用于备份：好比，你能够在最近的24小时内，每小时备份一次，而且在每月的每一天也备份一个RDB文件。这样的话，即便赶上问题，也能够随时将数据集还原到不一样的版本。RDB很是适合灾难恢复。RDB的缺点是：若是你须要尽可能避免在服务器故障时丢失数据，那么RDB不合适你。

面试官：那你要再也不说下AOF？？

我：（说就一块儿说下吧）使用AOF作持久化，每个写命令都经过write函数追加到appendonly.aof中，配置方式以下：

appendfsync yes   
appendfsync always     #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。

AOF能够作到全程持久化，只须要在配置中开启 appendonly yes。这样redis每执行一个修改数据的命令，都会把它添加到AOF文件中，当redis重启时，将会读取AOF文件进行重放，恢复到redis关闭前的最后时刻。

我顿了一下，继续说：使用AOF的优势是会让redis变得很是耐久。能够设置不一样的fsync策略，aof的默认策略是每秒钟fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。缺点是对于相同的数据集来讲，AOF的文件体积一般要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。

面试官又问：你说了这么多，那我该用哪个呢？

我：若是你很是关心你的数据，但仍然能够承受数分钟内的数据丢失，那么能够额只使用RDB持久。AOF将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会下降Redis的性能，不知道你是否能够接受。数据库备份和灾难恢复：定时生成RDB快照很是便于进行数据库备份，而且RDB恢复数据集的速度也要比AOF恢复的速度快。固然了，redis支持同时开启RDB和AOF，系统重启后，redis会优先使用AOF来恢复数据，这样丢失的数据会最少。

9、主从复制

面试官：redis单节点存在单点故障问题，为了解决单点问题，通常都须要对redis配置从节点，而后使用哨兵来监听主节点的存活状态，若是主节点挂掉，从节点能继续提供缓存功能，你能说说redis主从复制的过程和原理吗？

我有点懵，这个说来就话长了。但幸亏提早准备了：主从配置结合哨兵模式能解决单点故障问题，提升redis可用性。从节点仅提供读操做，主节点提供写操做。对于读多写少的情况，可给主节点配置多个从节点，从而提升响应效率。

我顿了一下，接着说：关于复制过程，是这样的：

  1. 从节点执行slaveof[masterIP][masterPort]，保存主节点信息
  2. 从节点中的定时任务发现主节点信息，创建和主节点的socket链接
  3. 从节点发送Ping信号，主节点返回Pong，两边能互相通讯
  4. 链接创建后，主节点将全部数据发送给从节点（数据同步）
  5. 主节点把当前的数据同步给从节点后，便完成了复制的创建过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

面试官：那你能详细说下数据同步的过程吗？

（我心想：这也问的太细了吧）我：能够。redis2.8以前使用sync[runId][offset]同步命令，redis2.8以后使用psync[runId][offset]命令。二者不一样在于，sync命令仅支持全量复制过程，psync支持全量和部分复制。介绍同步以前，先介绍几个概念：

  • runId：每一个redis节点启动都会生成惟一的uuid，每次redis重启后，runId都会发生变化。
  • offset：主节点和从节点都各自维护本身的主从复制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度。从节点在收到主节点发送的命令后，也会增长本身的offset，并把本身的offset发送给主节点。这样，主节点同时保存本身的offset和从节点的offset，经过对比offset来判断主从节点数据是否一致。
  • repl_backlog_size：保存在主节点上的一个固定长度的先进先出队列，默认大小是1MB。
  1. 主节点发送数据给从节点过程当中，主节点还会进行一些写操做，这时候的数据存储在复制缓冲区中。从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。
  2. 主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。

上面是psync的执行流程：

从节点发送psync[runId][offset]命令，主节点有三种响应：

  • FULLRESYNC：第一次链接，进行全量复制
  • CONTINUE：进行部分复制
  • ERR：不支持psync命令，进行全量复制

面试官：很好，那你能具体说下全量复制和部分复制的过程吗？

我：能够

上面是全量复制的流程。主要有如下几步：

  1. 从节点发送psync ? -1命令（由于第一次发送，不知道主节点的runId，因此为?，由于是第一次复制，因此offset=-1）。
  2. 主节点发现从节点是第一次复制，返回FULLRESYNC {runId} {offset}，runId是主节点的runId，offset是主节点目前的offset。
  3. 从节点接收主节点信息后，保存到info中。
  4. 主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据持久化）。
  5. 主节点发送RDB文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。
  6. 从节点清理本身的数据库数据。
  7. 从节点加载RDB文件，将数据保存到本身的数据库中。
  8. 若是从节点开启了AOF，从节点会异步重写AOF文件。

关于部分复制有如下几点说明：

  1. 部分复制主要是Redis针对全量复制的太高开销作出的一种优化措施，使用psync[runId][offset]命令实现。当从节点正在复制主节点时，若是出现网络闪断或者命令丢失等异常状况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区将这部分数据直接发送给从节点，这样就能够保持主从节点复制的一致性。补发的这部分数据通常远远小于全量数据。
  2. 主从链接中断期间主节点依然响应命令，但因复制链接中断命令没法发送给从节点，不过主节点内的复制积压缓冲区依然能够保存最近一段时间的写命令数据。
  3. 当主从链接恢复后，因为从节点以前保存了自身已复制的偏移量和主节点的运行ID。所以会把它们当作psync参数发送给主节点，要求进行部分复制。
  4. 主节点接收到psync命令后首先核对参数runId是否与自身一致，若是一致，说明以前复制的是当前主节点；以后根据参数offset在复制积压缓冲区中查找，若是offset以后的数据存在，则对从节点发送+COUTINUE命令，表示能够进行部分复制。由于缓冲区大小固定，若发生缓冲溢出，则进行全量复制。
  5. 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

10、哨兵

面试官：那主从复制会存在哪些问题呢？

我：主从复制会存在如下问题：

  1. 一旦主节点宕机，从节点晋升为主节点，同时须要修改应用方的主节点地址，还须要命令全部从节点去复制新的主节点，整个过程须要人工干预。
  2. 主节点的写能力受到单机的限制。
  3. 主节点的存储能力受到单机的限制。
  4. 原生复制的弊端在早期的版本中也会比较突出，好比：redis复制中断后，从节点会发起psync。此时若是同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会形成毫秒或秒级的卡顿。

面试官：那比较主流的解决方案是什么呢？

我：固然是哨兵啊。

面试官：那么问题又来了。那你说下哨兵有哪些功能？

我：如图，是Redis Sentinel（哨兵）的架构图。Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行状况检测、自动故障转移、主从切换。Redis Sentinel最小配置是一主一从。Redis的Sentinel系统能够用来管理多个Redis服务器，该系统能够执行如下四个任务：

  1. 监控：不断检查主服务器和从服务器是否正常运行。
  2. 通知：当被监控的某个redis服务器出现问题，Sentinel经过API脚本向管理员或者其余应用程序发出通知。
  3. 自动故障转移：当主节点不能正常工做时，Sentinel会开始一次自动的故障转移操做，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，而且将其余的从节点指向新的主节点，这样人工干预就能够免了。
  4. 配置提供者：在Redis Sentinel模式下，客户端应用在初始化时链接的是Sentinel节点集合，从中获取主节点的信息。

面试官：那你能说下哨兵的工做原理吗？

我：话很少说，直接上图：

一、每一个Sentinel节点都须要按期执行如下任务：每一个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其余的Sentinel实例发送一个PING命令。（如上图）

二、若是一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。（如上图）

三、若是一个主服务器被标记为主观下线，那么正在监视这个服务器的全部Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。

四、若是一个主服务器被标记为主观下线，而且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内赞成这一判断，那么这个主服务器被标记为客观下线。

五、通常状况下，每一个Sentinel会以每10秒一次的频率向它已知的全部主服务器和从服务器发送INFO命令，当一个主服务器被标记为客观下线时，Sentinel向下线主服务器的全部从服务器发送INFO命令的频率，会从10秒一次改成每秒一次。

六、Sentinel和其余Sentinel协商客观下线的主节点的状态，若是处于SDOWN状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。

七、当没有足够数量的Sentinel赞成主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器从新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。

面试官：不错，面试前没少下工夫啊，今天Redis这关你过了，明天找个时间咱们再聊聊其余的。（露出欣慰的微笑）

我：没问题。

总结

本文在一次面试的过程当中讲述了Redis是什么，Redis的特色和功能，Redis缓存的使用，Redis为何能这么快，Redis缓存的淘汰策略，持久化的两种方式，Redis高可用部分的主从复制和哨兵的基本原理。只要功夫深，铁杵磨成针，平时准备好，面试不用慌。虽然面试不必定是这样问的，但万变不离其“宗”。（笔者以为这种问答形式的博客很不错，可读性强并且读后记的比较深入）

本文转载自：个人阿里面经，和面试官漫谈Redis，面试当谈笑风生

联系我们 沪ICP备13005482号-10