1、什么是CAP理論？

CAP理論是指 當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時，一致性和可用性不可能同時保證。

• C：Consistent 一致性

• A：Availability 可用性

• P：Partition tolerance 分區(qū)容忍度

• 網(wǎng)絡(luò)分區(qū)：分布式系統(tǒng)的節(jié)點(diǎn)往往都是分布在不同的機(jī)器上進(jìn)行網(wǎng)絡(luò)隔離開的，這意味著必然會有網(wǎng)絡(luò)斷開的風(fēng)險(xiǎn)，網(wǎng)絡(luò)斷開也就意味著發(fā)生了網(wǎng)絡(luò)分區(qū)。

• 最終一致性：Redis可以保證最終一致性，從節(jié)點(diǎn)會努力追趕主節(jié)點(diǎn)，最終從節(jié)點(diǎn)的狀態(tài)會和主節(jié)點(diǎn)的狀態(tài)將保持一致。

2、redis對事務(wù)支持

redis對事務(wù)的支持主要可以概括如下：

• 隔離性：redis 是單進(jìn)程的程序，保證在執(zhí)行事務(wù)時，不會對事務(wù)進(jìn)行中斷，事務(wù)可以運(yùn)行直到執(zhí)行完所有事務(wù)隊(duì)列中的命令為止。所以redis的事務(wù)支持隔離性。

• redis會將一個事務(wù)中的所有命令序列化，然后按順序執(zhí)行。redis不可能在一個事務(wù)的執(zhí)行過程中插入執(zhí)行另一個客戶端發(fā)出的請求?？梢员ＷCRedis將這些命令作為一個單獨(dú)的隔離操作執(zhí)行。

redis操作事務(wù)的相關(guān)命令如下所示：

• MULTI：標(biāo)記一個事務(wù)塊的開始。

• EXEC：執(zhí)行所有事務(wù)塊內(nèi)的命令。

• DISCARD：取消事務(wù)，放棄執(zhí)行事務(wù)塊內(nèi)的所有命令。

• UNWATCH：取消 WATCH 命令對所有 key 的監(jiān)視。

• WATCH key [key ...]：監(jiān)視一個(或多個) key ，如果在事務(wù)執(zhí)行之前這個(或這些) key 被其他命令所改動，那么事務(wù)將被打斷。

需要注意的是redis的事務(wù)不支持回滾操作，redis以 MULTI 開始一個事務(wù)，然后將多個命令入隊(duì)到事務(wù)中，最后由 EXEC 命令觸發(fā)事務(wù)， 一并執(zhí)行事務(wù)中的所有命令。只有當(dāng)被調(diào)用的redis命令有語法錯誤時，這條命令才會執(zhí)行失敗，或者對某個鍵執(zhí)行不符合其數(shù)據(jù)類型的操作，但是應(yīng)該在將命令入隊(duì)列的時候就應(yīng)該并且能夠發(fā)現(xiàn)這些問題，所以redis的事務(wù)不支持進(jìn)行回滾操作。

3、消息隊(duì)列Kafka有了解嗎？

Kafka是一個消息隊(duì)列，可以實(shí)現(xiàn)發(fā)布訂閱模式，在異步通信或者生產(chǎn)者和消費(fèi)者需要解耦合的場景中經(jīng)常使用，可以對數(shù)據(jù)流進(jìn)行處理等。

Kafka的特性如下所示：

• Kafka支持消息的快速持久化

• 支持批量讀寫消息

• 支持消息分區(qū)，并且支持在線增加分區(qū)，提高了并發(fā)能力

• 支持為每個分區(qū)創(chuàng)建多個副本

Kafka可以實(shí)現(xiàn)消息的快速持久化的原因：

• KafKa將消息保存在磁盤中，并且讀寫磁盤的方式是順序讀寫，避免了隨機(jī)讀寫磁盤（尋道時間過長）導(dǎo)致的性能瓶頸。

• 磁盤的順序讀寫速度超過內(nèi)存隨機(jī)讀寫。

4、Kafka使用磁盤存儲，為什么會具有高性能的特點(diǎn)？

• 順序讀寫磁盤：

消息在磁盤中的方式是順序讀寫的，磁盤的順序讀寫速度超過內(nèi)存隨機(jī)讀寫。

• 頁緩存：

頁緩存是操作系統(tǒng)實(shí)現(xiàn)的一種主要的磁盤緩存，以此用來減少對磁盤I/O 的操作。具體就是把磁盤中的數(shù)據(jù)緩存到內(nèi)存中，把對磁盤的訪問變?yōu)閷?nèi)存的訪問。當(dāng)然，也會存在磁盤臟頁，以及合適時機(jī)會進(jìn)行刷盤操作。

• 零拷貝：

使用零拷貝（ Zero-Copy ）技術(shù)來進(jìn)一步提升Kafka性能。零拷貝是指將數(shù)據(jù)直接從磁盤文件復(fù)制到網(wǎng)卡設(shè)備中，而不需要經(jīng)由應(yīng)用程序之手。零拷貝大大提高了應(yīng)用程序的性能，減少了內(nèi)核和用戶模式之間的上下文切換。

5、Kafka中的核心概念

核心概念如下所示：

• 生產(chǎn)者（Producer）：

生產(chǎn)消息，并且按照一定的規(guī)則（分區(qū)分配規(guī)則）推送到Topic的分區(qū)中。

• 消費(fèi)者（Consumer）：

從Topic中拉取消息并且進(jìn)行消費(fèi)，消費(fèi)者自行維護(hù)消費(fèi)消息的位置（offset）。

• 主題（Topic）：

存儲消息的邏輯概念，是一個消息集合，Kafka根據(jù)topic對消息進(jìn)行歸類，發(fā)布到Kafka集群的每條消息都需要指定一個topic。

• 分區(qū)（partition）：

每個Topic可以劃分為多個分區(qū)，每個消息在分區(qū)中都會有一個唯一編號offset，kafka通過offset保證消息在分區(qū)中的順序，同一Topic的不同分區(qū)可以分配在不同的Broker上，partition以文件的形式存儲在文件系統(tǒng)中。

• 副本（replica）：

KafKa對消息進(jìn)行了冗余備份，每個分區(qū)有多個副本，每個副本中包含的消息是“一樣”的。每個副本中都會選舉出一個Leader副本，其余為Follower副本，F(xiàn)ollower副本僅僅是將數(shù)據(jù)從Leader副本拉到本地，然后同步到自己的Log中。

• 消費(fèi)者組（Consumer Group）：

每個consumer都屬于一個consumer group，每條消息只能被consumer group中的一個Consumer消費(fèi)，但可以被多個consumer group消費(fèi)。

• Broker：

一個單獨(dú)的server就是一個Broker，主要用來接收生產(chǎn)者發(fā)過來的消息，分配offset，并且保存到磁盤中。

• Cluster & Controller：

多個Broker可以組成一個Cluster集群，每個集群選舉一個Broker來作為Controller，充當(dāng)指揮中心。Controller負(fù)責(zé)管理分區(qū)的狀態(tài)，管理每個分區(qū)的副本狀態(tài)，監(jiān)聽ZooKeeper中數(shù)據(jù)的變化等工作。

• 日志壓縮與保留策略：

不管消費(fèi)者是否已經(jīng)消費(fèi)了消息，Kafka都會保存這些消息（持久化到磁盤）,通過配置相應(yīng)的保留策略，定時刪除陳舊的消息。所謂日志壓縮，就是定時進(jìn)行相同key值得合并，只保留最新的Key-Value值。

6、簡單介紹下Kafka中的副本機(jī)制吧

在分布式的存儲中，進(jìn)行冗余備份是一種常見的設(shè)計(jì)，主要的設(shè)計(jì)方案有同步復(fù)制和異步復(fù)制。

同步復(fù)制：

當(dāng)所有的Follower副本都將消息復(fù)制完成，這條消息才會被認(rèn)為是提交完成，一旦有一個Follower副本出現(xiàn)故障，就會導(dǎo)致消息無法提交，極大的影響到了系統(tǒng)的性能。

異步復(fù)制：

當(dāng)Leader副本接收到生產(chǎn)者發(fā)送的消息后就認(rèn)為當(dāng)前消息提交成功。Follower副本異步的從Leader副本同步消息，但是不可以保證同步速度，當(dāng)Leader副本突然宕機(jī)的時候，可能Follower副本中的消息落后太多，導(dǎo)致消息的丟失。

考慮到同步復(fù)制和異步復(fù)制的優(yōu)缺點(diǎn)，Kafka引入了ISR集合。

ISR（In-Sync-Replica）集合：

可用副本集合，ISR集合表示當(dāng)前“可用”且消息量與Leader相差不多的副本集合，需要滿足如下條件：

• 副本所在節(jié)點(diǎn)必須維持著與ZooKeeper的連接。

• 副本最后一條信息的offset與Leader副本的最后一條消息的offset之間的差值不能超過指定的閾值。

HW和LEO標(biāo)志：

• HW（HighWatermark）表示高水位，標(biāo)記了一個特殊的offset，當(dāng)消費(fèi)者處理消息的時候，只能拉取到HW之前的消息。HW也是由Leader副本管理的。

• LEO（Log End Offset）是所有副本都會有的一個offset標(biāo)記。

ISR、HW和LEO的工作配合機(jī)制：

• producer向此分區(qū)中推送消息

• Leader副本將消息追加到Log中，并且遞增其LEO

• Follower副本從Leader副本中拉取消息進(jìn)行同步

• Follower副本將消息更新到本地Log中，并且遞增其LEO

• 當(dāng)ISR集合中的所有副本都完成了對offset的消息同步，Leader副本會遞增其HW

優(yōu)勢：

• 同步復(fù)制會導(dǎo)致高延遲，異步復(fù)制可能會造成消息的丟失。

• KafKa引入的ISR集合解決了同步復(fù)制和異步復(fù)制的缺點(diǎn)。

• 當(dāng)Follower副本延遲過高時，將會被踢出ISR集合，避免了高延遲的Follower副本影響整個KafKa集群性能。

• 當(dāng)Leader副本所在的Broker宕機(jī)，會優(yōu)先將ISR集合中的Follower副本選舉為Leader。

7、Kafka的文件存儲機(jī)制

Kafka中消息是以topic進(jìn)行分類的，生產(chǎn)者通過topic向Kafka broker發(fā)送消息，消費(fèi)者通過topic讀取數(shù)據(jù)。

然而topic在物理層面又能以partition為分組，一個topic可以分成若干個partition，partition還可以細(xì)分為segment，一個partition物理上由多個segment組成。

在server.properties中可以設(shè)置文件的存儲位置，默認(rèn)為log.dirs=/tmp/kafka-logs。當(dāng)我們創(chuàng)建一個topic的時候，可以在/tmp/kafka-logs目錄中看到對應(yīng)分區(qū)個數(shù)的目錄數(shù)。在Kafka文件存儲中，同一個topic下有多個不同的partition，每個partiton為一個目錄，partition的名稱規(guī)則為：topic名稱 有序序號，第一個序號從0開始計(jì)，最大的序號為partition數(shù)量減1

8、為什么Kafka中的分區(qū)只支持增長，不支持減小分區(qū)個數(shù)的操作？

• 刪除掉的分區(qū)的消息不好處理，若丟棄則可靠性得不到保證

• 如果插入現(xiàn)有分區(qū)的尾部，則一些帶時間戳的消息會對消費(fèi)者有影響

• 如果消息量大的話，復(fù)制到其它分區(qū)也會很耗費(fèi)資源；

如果你非要減小分區(qū)個數(shù)，那么可以新創(chuàng)建一個分區(qū)數(shù)比較小的topic，將現(xiàn)有topic中的消息按照一定的邏輯復(fù)制過去。

9、Kafka消息傳輸?shù)娜笳Z義

afka有以下三種可能的傳輸保障（delivery guarantee）:

• At most once: 最多一次，消息可能會丟，但絕不會重復(fù)傳輸

• At least once：最少一次，消息絕不會丟，但可能會重復(fù)傳輸

• Exactly once：恰好一次，每條消息肯定會被傳輸一次且僅傳輸一次

At most once：最多消費(fèi)一次，絕對不會重復(fù)消費(fèi)。那么Kafka如何保證At most once語義呢？

• 生產(chǎn)者Producer來生產(chǎn)消息的時候，當(dāng)寫數(shù)據(jù)失敗的時候，broker直接跳過該消息，導(dǎo)致消息丟失，消費(fèi)者無法消費(fèi)該消息。

• 消費(fèi)者在拉取消息之后，直接提交消息位移offset，但是沒有完全消費(fèi)完拉取消息即發(fā)生故障，下次會直接從剛剛offset的位置進(jìn)行消費(fèi)，剛剛故障時刻-offset之間的消息丟失。

At least once：最少一次，消息絕不會丟。那么Kafka如何保證最少消費(fèi)一次呢？

生產(chǎn)者在生產(chǎn)數(shù)據(jù)的時候，以及寫入了broker中，但是由于broker上的異常，導(dǎo)致生產(chǎn)者并沒有成功的收到ACK，之后會進(jìn)行重試操作，導(dǎo)致消息被寫入了多次。

Exactly once：恰好消費(fèi)一次，那么Kafka如何保證恰好一次的語義呢？

• 生產(chǎn)者生產(chǎn)消息的時候保證冪等性。對于同一個數(shù)據(jù)無論操作多少次都只寫入一條數(shù)據(jù)，如果重復(fù)寫入，則執(zhí)行不成功。

• 跨partition的原子性寫操作。broker寫入數(shù)據(jù)的時候，保證原子性操作，要么寫入成功，要么寫入失敗。（不成功不斷進(jìn)行重試）