《今天面試了嗎》-Redis

時間 2019-12-17

原文原文鏈接

今天，我蚍蜉撼樹的面試了某大廠的java開發崗位，迎面走來一位風塵僕僕的中年男子，手裏拿着屏幕還亮着的mac，他衝着我禮貌的笑了笑，而後說了句「很差意思，讓你久等了」，而後示意我坐下，說：「咱們開始吧。看了你的簡歷，以爲你對redis應該掌握的不錯，咱們今天就來討論下redis......」。我想：「來就來，兵來將擋水來土掩」。java

Redis是什麼

面試官：你先來講下redis是什麼吧web
我：（這不就是總結下redis的定義和特色嘛）Redis是C語言開發的一個開源的（聽從BSD協議）高性能鍵值對（key-value）的內存數據庫，能夠用做數據庫、緩存、消息中間件等。它是一種NoSQL（not-only sql，泛指非關係型數據庫）的數據庫。面試
我頓了一下，接着說：Redis做爲一個內存數據庫。一、性能優秀，數據在內存中，讀寫速度很是快，支持併發10W QPS；二、單進程單線程，是線程安全的，採用IO多路複用機制；三、豐富的數據類型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等；四、支持數據持久化。能夠將內存中數據保存在磁盤中，重啓時加載；五、主從複製，哨兵，高可用；六、能夠用做分佈式鎖；七、能夠做爲消息中間件使用，支持發佈訂閱redis

五種數據類型

面試官：總結的不錯，看來是早有準備啊。剛來聽你提到redis支持五種數據類型，那你能簡單說下這五種數據類型嗎？算法
我：固然能夠，可是在說以前，我以爲有必要先來了解下Redis內部內存管理是如何描述這5種數據類型的。說着，我拿着筆給面試官畫了一張圖： spring
我：首先redis內部使用一個redisObject對象來表示全部的key和value，redisObject最主要的信息如上圖所示：type表示一個value對象具體是何種數據類型，encoding是不一樣數據類型在redis內部的存儲方式。好比：type=string表示value存儲的是一個普通字符串，那麼encoding能夠是raw或者int。sql
我頓了一下，接着說：下面我簡單說下5種數據類型：
一、string是redis最基本的類型，能夠理解成與memcached如出一轍的類型，一個key對應一個value。value不只是string，也能夠是數字。string類型是二進制安全的，意思是redis的string類型能夠包含任何數據，好比jpg圖片或者序列化的對象。string類型的值最大能存儲512M。
二、Hash是一個鍵值（key-value）的集合。redis的hash是一個string的key和value的映射表，Hash特別適合存儲對象。經常使用命令：hget,hset,hgetall等。
三、list列表是簡單的字符串列表，按照插入順序排序。能夠添加一個元素到列表的頭部（左邊）或者尾部（右邊）經常使用命令：lpush、rpush、lpop、rpop、lrange(獲取列表片斷)等。
應用場景：list應用場景很是多，也是Redis最重要的數據結構之一，好比twitter的關注列表，粉絲列表均可以用list結構來實現。
數據結構：list就是鏈表，能夠用來當消息隊列用。redis提供了List的push和pop操做，還提供了操做某一段的api，能夠直接查詢或者刪除某一段的元素。
實現方式：redis list的是實現是一個雙向鏈表，既能夠支持反向查找和遍歷，更方便操做，不過帶來了額外的內存開銷。
四、set是string類型的無序集合。集合是經過hashtable實現的。set中的元素是沒有順序的，並且是沒有重複的。
經常使用命令：sdd、spop、smembers、sunion等。
應用場景：redis set對外提供的功能和list同樣是一個列表，特殊之處在於set是自動去重的，並且set提供了判斷某個成員是否在一個set集合中。
五、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，使用跳躍表的結構能夠得到比較高的查找效率，而且在實現上比較簡單。數據庫
我：我以前總結了一張圖，關於數據類型的應用場景，若是您感興趣，能夠去個人掘金看。。express

數據類型應用場景總結

類型	簡介	特性	場景
string（字符串）	二進制安全	能夠包含任何數據，好比jpg圖片或者序列化對象	---
Hash（字典）	鍵值對集合，即編程語言中的map類型	適合存儲對象，而且能夠像數據庫中的update一個屬性同樣只修改某一項屬性值	存儲、讀取、修改用戶屬性
List（列表）	鏈表（雙向鏈表）	增刪快，提供了操做某一元素的api	最新消息排行；消息隊列
set（集合）	hash表實現，元素不重複	添加、刪除、查找的複雜度都是O(1)，提供了求交集、並集、差集的操做	共同好友；利用惟一性，統計訪問網站的全部Ip
sorted set（有序集合）	將set中的元素增長一個權重參數score，元素按score有序排列	數據插入集合時，已經進行了自然排序	排行榜；帶權重的消息隊列

面試官：想不到你平時也下了很多工夫，那redis緩存你必定用過的吧apache
我：用過的。。
面試官：那你跟我說下你是怎麼用的？
我是結合spring boot使用的。通常有兩種方式，一種是直接經過RedisTemplate來使用，另外一種是使用spring cache集成Redis（也就是註解的方式）。具體的代碼我就不說了，在個人掘金中有一個demo（見下）。

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 + '}'; } } 複製代碼

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

使用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。
測試類：UserController

@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中獲取。

緩存註解

一、@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，則在方法尚未執行的時候就清空緩存。缺省狀況下，若是方法執行拋出異常，則不會清空緩存。

緩存問題

面試官：看了一下你的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;
    }
複製代碼

面試官：嗯嗯，還不錯。

Redis爲什麼這麼快

面試官：redis做爲緩存你們都在用，那redis必定很快咯？
我：固然了，官方提供的數據能夠達到100000+的QPS（每秒內的查詢次數），這個數據不比Memcached差！
面試官：redis這麼快，它的「多線程模型」你瞭解嗎？（露出邪魅一笑）
我：您是想問Redis這麼快，爲何仍是單線程的吧。Redis確實是單進程單線程的模型，由於Redis徹底是基於內存的操做，CPU不是Redis的瓶頸，Redis的瓶頸最有多是機器內存的大小或者網絡帶寬。既然單線程容易實現，並且CPU不會成爲瓶頸，那就瓜熟蒂落的採用單線程的方案了（畢竟採用多線程會有不少麻煩）。
面試官：嗯，是的。那你能說說Redis是單線程的，爲何還能這麼快嗎？
我：能夠這麼說吧。第一：Redis徹底基於內存，絕大部分請求是純粹的內存操做，很是迅速，數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度是O(1)。第二：數據結構簡單，對數據操做也簡單。第三：採用單線程，避免了沒必要要的上下文切換和競爭條件，不存在多線程致使的CPU切換，不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有死鎖問題致使的性能消耗。第四：使用多路複用IO模型，非阻塞IO。

Redis和Memcached的區別

面試官：嗯嗯，說的很詳細。那你爲何選擇Redis的緩存方案而不用memcached呢
我：一、存儲方式上：memcache會把數據所有存在內存之中，斷電後會掛掉，數據不能超過內存大小。redis有部分數據存在硬盤上，這樣能保證數據的持久性。二、數據支持類型上：memcache對數據類型的支持簡單，只支持簡單的key-value，，而redis支持五種數據類型。三、使用底層模型不一樣：它們之間底層實現方式以及與客戶端之間通訊的應用協議不同。redis直接本身構建了VM機制，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。四、value的大小：redis能夠達到1GB，而memcache只有1MB。

淘汰策略

面試官：那你說說你知道的redis的淘汰策略有哪些？
我：Redis有六種淘汰策略

策略	描述
volatile-lru	從已設置過時時間的KV集中優先對最近最少使用(less recently used)的數據淘汰
volitile-ttl	從已設置過時時間的KV集中優先對剩餘時間短(time to live)的數據淘汰
volitile-random	從已設置過時時間的KV集中隨機選擇數據淘汰
allkeys-lru	從全部KV集中優先對最近最少使用(less recently used)的數據淘汰
allKeys-random	從全部KV集中隨機選擇數據淘汰
noeviction	不淘汰策略，若超過最大內存，返回錯誤信息

補充一下：Redis4.0加入了LFU(least frequency use)淘汰策略，包括volatile-lfu和allkeys-lfu，經過統計訪問頻率，將訪問頻率最少，即最不常用的KV淘汰。

持久化

面試官：你對redis的持久化機制瞭解嗎？能講一下嗎？
我：redis爲了保證效率，數據緩存在了內存中，可是會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件中，以保證數據的持久化。Redis的持久化策略有兩種：一、RDB：快照形式是直接把內存中的數據保存到一個dump的文件中，定時保存，保存策略。二、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來恢復數據，這樣丟失的數據會最少。

主從複製

面試官：redis單節點存在單點故障問題，爲了解決單點問題，通常都須要對redis配置從節點，而後使用哨兵來監聽主節點的存活狀態，若是主節點掛掉，從節點能繼續提供緩存功能，你能說說redis主從複製的過程和原理嗎？
我有點懵，這個說來就話長了。但幸虧提早準備了：主從配置結合哨兵模式能解決單點故障問題，提升redis可用性。從節點僅提供讀操做，主節點提供寫操做。對於讀多寫少的情況，可給主節點配置多個從節點，從而提升響應效率。
我頓了一下，接着說：關於複製過程，是這樣的：一、從節點執行slaveof[masterIP][masterPort]，保存主節點信息
二、從節點中的定時任務發現主節點信息，創建和主節點的socket鏈接
三、從節點發送Ping信號，主節點返回Pong，兩邊能互相通訊
四、鏈接創建後，主節點將全部數據發送給從節點（數據同步）
五、主節點把當前的數據同步給從節點後，便完成了複製的創建過程。接下來，主節點就會持續的把寫命令發送給從節點，保證主從數據一致性。
面試官：那你能詳細說下數據同步的過程嗎？
（我心想：這也問的太細了吧）我：能夠。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]命令，主節點有三種響應：
（1）FULLRESYNC：第一次鏈接，進行全量複製
（2）CONTINUE：進行部分複製
（3）ERR：不支持psync命令，進行全量複製

面試官：很好，那你能具體說下全量複製和部分複製的過程嗎？
我：能夠

上面是全量複製的流程。主要有如下幾步：
一、從節點發送psync ? -1命令（由於第一次發送，不知道主節點的runId，因此爲?，由於是第一次複製，因此offset=-1）。
二、主節點發現從節點是第一次複製，返回FULLRESYNC {runId} {offset}，runId是主節點的runId，offset是主節點目前的offset。
三、從節點接收主節點信息後，保存到info中。
四、主節點在發送FULLRESYNC後，啓動bgsave命令，生成RDB文件（數據持久化）。
五、主節點發送RDB文件給從節點。到從節點加載數據完成這段期間主節點的寫命令放入緩衝區。
六、從節點清理本身的數據庫數據。
七、從節點加載RDB文件，將數據保存到本身的數據庫中。
八、若是從節點開啓了AOF，從節點會異步重寫AOF文件。

關於部分複製有如下幾點說明：
一、部分複製主要是Redis針對全量複製的太高開銷作出的一種優化措施，使用psync[runId][offset]命令實現。當從節點正在複製主節點時，若是出現網絡閃斷或者命令丟失等異常狀況時，從節點會向主節點要求補發丟失的命令數據，主節點的複製積壓緩衝區將這部分數據直接發送給從節點，這樣就能夠保持主從節點複製的一致性。補發的這部分數據通常遠遠小於全量數據。
二、主從鏈接中斷期間主節點依然響應命令，但因複製鏈接中斷命令沒法發送給從節點，不過主節點內的複製積壓緩衝區依然能夠保存最近一段時間的寫命令數據。
三、當主從鏈接恢復後，因爲從節點以前保存了自身已複製的偏移量和主節點的運行ID。所以會把它們當作psync參數發送給主節點，要求進行部分複製。
四、主節點接收到psync命令後首先覈對參數runId是否與自身一致，若是一致，說明以前複製的是當前主節點；以後根據參數offset在複製積壓緩衝區中查找，若是offset以後的數據存在，則對從節點發送+COUTINUE命令，表示能夠進行部分複製。由於緩衝區大小固定，若發生緩衝溢出，則進行全量複製。
五、主節點根據偏移量把複製積壓緩衝區裏的數據發送給從節點，保證主從複製進入正常狀態。

哨兵

面試官：那主從複製會存在哪些問題呢？
我：主從複製會存在如下問題：
一、一旦主節點宕機，從節點晉升爲主節點，同時須要修改應用方的主節點地址，還須要命令全部從節點去複製新的主節點，整個過程須要人工干預。
二、主節點的寫能力受到單機的限制。
三、主節點的存儲能力受到單機的限制。四、原生複製的弊端在早期的版本中也會比較突出，好比：redis複製中斷後，從節點會發起psync。此時若是同步不成功，則會進行全量同步，主庫執行全量備份的同時，可能會形成毫秒或秒級的卡頓。
面試官：那比較主流的解決方案是什麼呢？
我：固然是哨兵啊。
面試官：那麼問題又來了。那你說下哨兵有哪些功能？

我：如圖，是Redis Sentinel（哨兵）的架構圖。Redis Sentinel（哨兵）主要功能包括主節點存活檢測、主從運行狀況檢測、自動故障轉移、主從切換。Redis Sentinel最小配置是一主一從。Redis的Sentinel系統能夠用來管理多個Redis服務器，該系統能夠執行如下四個任務：
一、監控：不斷檢查主服務器和從服務器是否正常運行。
二、通知：當被監控的某個redis服務器出現問題，Sentinel經過API腳本向管理員或者其餘應用程序發出通知。
三、自動故障轉移：當主節點不能正常工做時，Sentinel會開始一次自動的故障轉移操做，它會將與失效主節點是主從關係的其中一個從節點升級爲新的主節點，而且將其餘的從節點指向新的主節點，這樣人工干預就能夠免了。
四、配置提供者：在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高可用部分的主從複製和哨兵的基本原理。只要功夫深，鐵杵磨成針，平時準備好，面試不用慌。雖然面試不必定是這樣問的，但萬變不離其「宗」。（筆者以爲這種問答形式的博客很不錯，可讀性強並且讀後記的比較深入）

參考文章
juejin.im/post/5dbef8… juejin.im/post/5b7d22…