java面試題：分佈式

分佈式分爲分佈式緩存(Redis)、分佈式鎖(Redis或Zookeeper)、分佈式服務(Dubbo或SpringCloud)、分佈式服務協調(Zookeeper)、分佈式消息隊列(Kafka、RabbitMq)、分佈式Session、分佈式事務、分佈式搜索(elastaticSearch)等。 不可能全部分佈式內容都熟悉，必定要在某個領域有所專長。 ###分佈式理論 Q:分佈式有哪些理論？ CAP、BASE。 分佈式CAP理論，任何一個分佈式系統都沒法同時知足Consistency(一致性)、Availability(可用性)、Partition tolerance(分區容錯性) 這三個基本需求。最多隻能知足其中兩項。 而Partition tolerance(分區容錯性) 是必須的，所以通常是CP，或者AP。 Q:你怎麼理解分佈式一致性？ 數據一致性一般指關聯數據之間的邏輯關係是否正確和完整。 在分佈式系統中，數據一致性每每指的是因爲數據的複製，不一樣數據節點中的數據內容是否完整而且相同。 一致性還分爲強一致性，弱一致性，還有最終一致性。 強一致性就是立刻就保持一致。 最終一致性是指通過一段時間後，能夠保持一致。

分佈式事務

Q:你怎麼理解分佈式事務？分佈式事務的協議有哪些？ 分佈式事務是指會涉及到操做多個數據庫的事務。目的是爲了保證分佈式系統中的數據一致性。 分佈式事務類型：二階段提交2PC，三階段提交3PC。 2PC：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。 3PC：三個階段：CanCommit、PreCommit、DoCommit Q:分佈式事務的解決方案有哪些？ 分佈式事務解決方案：補償機制TCC、XA、消息隊列MQ。 詳情見：https://www.cnblogs.com/expiator/p/9841703.html 面試題詳細答案見：https://juejin.im/post/5d70b0535188251637727de8 Q:怎麼保證分佈式系統的冪等性？ ###Rpc Q:講一下Dubbo 服務提供者提供服務，服務消費者能夠經過Rpc進行服務消費。 Q:Dubbo支持哪些協議？ Dubbo支持Dubbo、rmi、hessian、http、webservice、thrift、Redis等多種協議 Q:Dubbo默認的協議是什麼？ Dubbo協議。 Q:Dubbo的序列化有哪些方式？ Dubbo協議。
鏈接方式：長鏈接。默認協議：dubbo協議。序列化：hession二進制。
其餘協議： rmi協議。鏈接方式：短鏈接。序列化：java自帶的二進制 hessian。鏈接方式：短鏈接。序列化：表單序列化 Q:Dubbo和SpringCloud有哪些區別？ Dubbo是Soa(面向服務的架構)，SpringCloud是微服務架構，除了服務，還有註冊中心、熔斷、配置中心。 Dubbo基於Rpc(遠程過程調用)，SpringCloud基於restFul，基於http協議。 Q:Soa和微服務架構，有哪些區別？ Q:除了Zookeeper，你用過哪些註冊中心?有什麼區別？ Zookeeper，Redis，Eureka Zookeeper，是分佈式中的CP，可以更好地保證分佈式一致性。 Redis基於發佈/訂閱模式。 Eureka在SpringCloud中應用較多。Eureka是分佈式中的AP，也就是注重可用性。 Q:若是想實現一個Rpc框架，須要考慮哪些東西？ 動態代理、反射、序列化、反序列化、網絡通訊(netty)、編解碼、服務發現和註冊、心跳與鏈路檢測 Q:Dubbo的服務提供者、服務消費者須要配置哪些信息？ 服務提供者須要配置ip、端口、Dubbo協議、註冊中心地址等 Q:Dubbo有哪些負載均衡策略？ 一致性Hash均衡算法、隨機調用法、輪詢法、最少活動調用法。 Q:講一下Dubbo的SPI機制。 Q:大家用的是哪一個版本的Dubbo? Q:大家的服務劃分了幾個模塊？分別是哪些模塊？

###Redis Q:Redis有哪些優點？ 1.速度快，由於數據存在內存中 2.支持豐富數據類型，支持string，list，set，sorted set，hash 3.支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行 4.豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除 5.單線程，單進程，採用IO多路複用技術。 Q:Redis支持哪些數據結構？ string(字符串),hash(哈希),list(隊列),set(集合)及zset(sorted set:有序集合)。 Q:Redis的數據結構，有哪些應用場景？ string，簡單地get/set緩存。 hash，能夠緩存用戶資料。好比命令： hmset user1 name "lin" sex "male" age "25" ，緩存用戶user1的資料，姓名爲lin，性別爲男，年齡25。 list，能夠作隊列。往list隊列裏面push數據，而後再pop出來。 zset，能夠用來作排行榜。 詳情見：https://www.cnblogs.com/expiator/p/10274151.html Q:Redis的持久化方式有哪些？有哪些優缺點？ aof，就是備份操做記錄。aof因爲是備份操做命令，備份快，恢復慢。 rdb，就是備份全部數據，使用了快照。rdb恢復數據比較快。 Q:aof文件過大，怎麼處理？ 會進行aof文件重寫。 1.隨着AOF文件愈來愈大，裏面會有大部分是重複命令或者能夠合併的命令 2.重寫的好處：減小AOF日誌尺寸，減小內存佔用，加快數據庫恢復時間。 執行一個 AOF文件重寫操做，重寫會建立一個當前 AOF 文件的體積優化版本。 詳情見： https://blog.csdn.net/stevendbaguo/article/details/82855726 Q:講一下Redis的事務 先以 MULTI 開始一個事務， 而後將多個命令入隊到事務中， 最後由 EXEC 命令觸發事務， 一併執行事務中的全部命令。若是想放棄這個事務，可使用DISCARD命令。 Redis事務沒法回滾，那怎麼處理？ Q:怎麼設置Redis的key的過時時間？ key的的過時時間經過EXPIRE key seconds命令來設置數據的過時時間。返回1代表設置成功，返回0代表key不存在或者不能成功設置過時時間。 Q:Redis的過時策略有哪些？ Redis key過時的方式有三種： 被動刪除：當讀/寫一個已通過期的key時，會觸發惰性刪除策略，直接刪除掉這個過時key 主動刪除：因爲惰性刪除策略沒法保證冷數據被及時刪掉，因此Redis會按期主動淘汰一批已過時的key 當前已用內存超過maxmemory限定時，觸發主動清理策略，也就是Redis的內存回收策略。 Q:Redis 的內存回收機制都有哪些？ LRU、TTL。 noeviction：默認策略，不會刪除任何數據，拒絕全部寫入操做並返回客戶端錯誤信息，此時Redis只響應讀操做。 volatitle-lru：根據LRU算法刪除設置了超時屬性的鍵，知道騰出足夠空間爲止。若是沒有可刪除的鍵對象，回退到noeviction策略。 allkeys-lru：根據LRU算法刪除鍵，無論數據有沒有設置超時屬性，直到騰出足夠空間爲止。 allkeys-random：隨機刪除全部鍵，知道騰出足夠空間爲止。 volatitle-random：隨機刪除過時鍵，知道騰出足夠空間爲止。 volatitle-ttl：根據鍵值對象的ttl屬性，刪除最近將要過時數據。若是沒有，回退到noeviction策略 Q:手寫一下LRU算法 。 Q:Redis如何實現分佈式鎖？ 使用setnx命令。 setnx key value，當key不存在時，將 key 的值設爲 value ，返回1。若給定的 key 已經存在，則setnx不作任何動做，返回0。 當setnx返回1時，表示獲取鎖，作完操做之後del key，表示釋放鎖，若是setnx返回0表示獲取鎖失敗。 **Q:Redis實現的分佈式鎖，若是某個系統獲取鎖後，宕機了怎麼辦？ ** Redis宕機的話，會經過Redis集羣的哨兵模式，將某個從機變成新的主機。 系統模塊宕機的話，能夠經過設置過時時間(就是設置緩存失效時間)解決。系統宕機時鎖阻塞，過時後鎖釋放。 Q:設置緩存失效時間，那若是前一個線程把這個鎖給刪除了呢？ Q:Redis作分佈式鎖，Redis作了主從，若是設置鎖以後，主機在傳輸到從機的時候掛掉了，從機尚未加鎖信息，如何處理？ 可使用開源框架Redisson，採用了redLock。(待補充) Q:講一下Redis的redLock。 Q:Redis的搭建有哪些模式？ 主從模式、哨兵模式、Cluster（集羣）模式。 最好是用集羣模式。 詳情見：https://new.qq.com/omn/20180126/20180126G00THE.html Q:你用過的Redis是多主多從的，仍是一主多從的？集羣用到了多少節點？用到了多少個哨兵？ 集羣模式。三主三從。 Q:Redis採用多主多從的集羣模式，各個主節點的數據是否一致？ Q:Redis集羣有哪些特性？ master和slaver。主從複製。讀寫分離。哨兵模式。 Q:Redis集羣數據分片的原理是什麼？ Redis數據分片原理是哈希槽。 Redis 集羣有 16384 個哈希槽。 每個 Redis 集羣中的節點都承擔一個哈希槽的子集。 哈希槽讓在集羣中添加和移除節點很是容易。例如，若是我想添加一個新節點 D，我須要從節點 A，B， C 移動一些哈希槽到節點 D。一樣地，若是我想從集羣中移除節點 A，我只須要移動 A 的哈希槽到 B 和 C。 當節點 A 變成空的之後，我就能夠從集羣中完全刪除它。 由於從一個節點向另外一個節點移動哈希槽並不須要中止操做，因此添加和移除節點，或者改變節點持有的哈希槽百分比，都不須要任何停機時間(downtime)。 Q:集羣的拓撲結構有沒有了解過？集羣是怎麼鏈接的？ 無中心結構。Redis-Cluster採用無中心結構，每一個節點保存數據和整個集羣狀態,每一個節點都和其餘全部節點鏈接。 Q:講一下Redis主從複製的過程。 從機發送SYNC(同步)命令，主機接收後會執行BGSAVE(異步保存)命令備份數據。 主機備份後，就會向從機發送備份文件。主機以後還會發送緩衝區內的寫命令給從機。 當緩衝區命令發送完成後，主機執行一條寫命令，就會往從機發送同步寫入命令。 更詳細的步驟見： https://www.cnblogs.com/expiator/p/9881989.html Q:講一下Redis哨兵機制。 下面是Redis官方文檔對於哨兵功能的描述： 監控（Monitoring）：哨兵會不斷地檢查主節點和從節點是否運做正常。 自動故障轉移（Automatic Failover）：當主節點不能正常工做時，哨兵會開始自動故障轉移操做，它會將失效主節點的其中一個從節點升級爲新的主節點，並讓其餘從節點改成複製新的主節點。 配置提供者（Configuration Provider）：客戶端在初始化時，經過鏈接哨兵來得到當前Redis服務的主節點地址。 通知（Notification）：哨兵能夠將故障轉移的結果發送給客戶端。 ##緩存 Q:緩存雪崩是什麼？ 若是緩存數據設置的過時時間是相同的，而且Redis剛好將這部分數據所有刪光了。這就會致使在這段時間內，這些緩存同時失效，所有請求到數據庫中。這就是緩存雪崩。 怎麼解決緩存雪崩？ 解決方法：在緩存的時候給過時時間加上一個隨機值，這樣就會大幅度的減小緩存在同一時間過時。 Q:緩存穿透是什麼？ 緩存穿透是指查詢一個必定不存在的數據。因爲緩存不命中，而且出於容錯考慮，若是從數據庫查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到數據庫去查詢，失去了緩存的意義。 怎麼解決緩存穿透？ Q:什麼是緩存與數據庫雙寫一致問題？ 讀的時候，先讀緩存，緩存沒有的話，就讀數據庫，而後取出數據後放入緩存，同時返回響應。 更新的時候，先更新數據庫，而後再刪除緩存。 Q:先更新數據庫，再刪除緩存。若是刪除緩存失敗了，那麼會致使數據庫中是新數據，緩存中是舊數據，數據就出現了不一致，怎麼辦？ 解答：先刪除緩存，再更新數據庫。若是數據庫更新失敗了，那麼數據庫中是舊數據，緩存中是空的，那麼數據不會不一致。 由於讀的時候緩存沒有，因此去讀了數據庫中的舊數據，而後更新到緩存中。 ###Zookeeper Q:Zookeeper的原理是什麼？ Q:Zookeeper是怎麼保證一致性的？ zab協議。 zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，zab就進入了恢復模式，當領導者被選舉出來，且大多數server完成了和 leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和server具備相同的系統狀態。

Q:Zookeeper有哪些應用場景？ Zookeeper能夠做爲服務協調的註冊中心。還能夠作分佈式鎖(若是沒有用過度布式鎖就不要說) Q:Zookeeper爲何能作註冊中心？ Zookeeper的數據模型是樹型結構，由不少數據節點組成，zk將全量數據存儲在內存中，可謂是高性能，並且支持集羣，可謂高可用。 另外支持事件監聽(watch命令)。 Zookeeper能夠做爲一個數據發佈/訂閱系統。 Q:Zookeeper的節點有哪些類型？有什麼區別？ 臨時節點，永久節點。 更加細分就是臨時有序節點、臨時無序節點、永久有序節點、永久無序節點。　　 臨時節點： 當建立臨時節點的程序停掉以後，這個臨時節點就會消失，存儲的數據也沒有了。 Q:Zookeeper作爲註冊中心，主要存儲哪些數據？存儲在哪裏？ ip、端口，還有心跳機制。 數據存儲在Zookeeper的節點上面。 Q:心跳機制有什麼用？ Q:Zookeeper的廣播模式有什麼缺陷？ 廣播風暴。 Q:Zookeeper是怎麼實現分佈式鎖的？ 分佈式鎖：基於Zookeeper一致性文件系統,實現鎖服務。鎖服務分爲保存獨佔及時序控制兩類。 保存獨佔：將Zookeeper上的一個znode看做是一把鎖，經過createznode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除本身建立的distribute_lock 節點就釋放鎖。 時序控制：基於/distribute_lock鎖，全部客戶端在它下面建立臨時順序編號目錄節點，和選master同樣，編號最小的得到鎖，用完刪除，依次方便。 更詳細的回答以下： 其實基於Zookeeper，就是使用它的臨時有序節點來實現的分佈式鎖。 原理就是：當某客戶端要進行邏輯的加鎖時，就在Zookeeper上的某個指定節點的目錄下，去生成一個惟一的臨時有序節點， 而後判斷本身是不是這些有序節點中序號最小的一個，若是是，則算是獲取了鎖。若是不是，則說明沒有獲取到鎖，那麼就須要在序列中找到比本身小的那個節點，並對其調用exist()方法，對其註冊事件監聽，當監聽到這個節點被刪除了，那就再去判斷一次本身當初建立的節點是否變成了序列中最小的。若是是，則獲取鎖，若是不是，則重複上述步驟。 當釋放鎖的時候，只需將這個臨時節點刪除便可。 Q:講一下Zookeeper的讀寫機制。 Leader主機負責讀和寫。 Follower負責讀，並將寫操做轉發給Leader。Follower還參與Leader選舉投票，參與事務請求Proposal投票。 Observer充當觀察者的角色。Observer和Follower的惟一區別在於：Observer不參與任何投票。 Q:講一下Zookeeper的選舉機制。 Leader不可用時，會從新選舉Leader。超過半數的Follower選舉投票便可，Observer不參與投票。 Q:大家的zookeeper集羣配置了幾個節點？ 3個節點。注意，zookeeper集羣節點，最好是奇數個的。 集羣中的zookeeper節點須要超過半數，整個集羣對外才可用。 這裏所謂的整個集羣對外才可用，是指整個集羣還能選出一個Leader來，zookeeper默認採用quorums來支持Leader的選舉。 若是有2個zookeeper，那麼只要有1個死了zookeeper就不能用了，由於1沒有過半，因此2個zookeeper的死亡容忍度爲0；同理，要是有3個zookeeper，一個死了，還剩下2個正常的，過半了，因此3個zookeeper的容忍度爲1；同理你多列舉幾個：2->0;3->1;4->1;5->2;6->2會發現一個規律，2n和2n-1的容忍度是同樣的，都是n-1，因此爲了更加高效，何須增長那一個沒必要要的zookeeper呢。 Q:zookeeper的集羣節點，若是不是奇數的，可能會出現什麼問題？ 可能會出現腦裂。 假死：因爲心跳超時（網絡緣由致使的）認爲master死了，但其實master還存活着。 腦裂：因爲假死會發起新的master選舉，選舉出一個新的master，但舊的master網絡又通了，致使出現了兩個master ，有的客戶端鏈接到老的master 有的客戶端連接到新的master。 詳情見：https://my.oschina.net/wangen2009/blog/2994188 ###消息隊列 Q:爲何使用消息隊列？消息隊列有什麼優勢和缺點？Kafka、ActiveMQ、RabbitMq、RocketMQ 都有什麼優勢和缺點？ 消息隊列解耦，削峯，限流。 Q:如何保證消息隊列的高可用？ Q:如何保證消息不被重複消費？（如何保證消息消費的冪等性） Q:如何保證消息的可靠性傳輸？（如何處理消息丟失的問題） Q:如何保證消息的順序性？ Q:如何解決消息隊列的延時以及過時失效問題？消息隊列滿了之後該怎麼處理？有幾百萬消息持續積壓幾小時，說說怎麼解決？ Q:若是讓你寫一個消息隊列，該如何進行架構設計啊？說一下你的思路。

###Kafka
參考資料： Kafka 入門一篇文章就夠了 Q:講一下Kafka。 Kafka的簡單理解 Q:Kafka相對其餘消息隊列，有什麼特色？ 持久化：Kafka的持久化能力比較好，經過磁盤持久化。而RabbitMQ是經過內存持久化的。 吞吐量：Rocket的併發量很是高。 消息處理：RabbitMQ的消息不支持批量處理，而RocketMQ和Kafka支持批量處理。 高可用：RabbitMQ採用主從模式。Kafka也是主從模式，經過Zookeeper管理，選舉Leader，還有Replication副本。 事務：RocketMQ支持事務，而Kafka和RabbitMQ不支持。 Q:Kafka有哪些模式？ 若是一個生產者或者多個生產者產生的消息可以被多個消費者同時消費的狀況，這樣的消息隊列稱爲"發佈訂閱模式"的消息隊列 Q:Kafka做爲消息隊列，有哪些優點？ 分佈式的消息系統。 高吞吐量。即便存儲了許多TB的消息，它也保持穩定的性能。 數據保留在磁盤上，所以它是持久的。 Q:Kafka爲何處理速度會很快？ 零拷貝：Kafka 實現了"零拷貝"原理來快速移動數據，避免了內核之間的切換。 消息壓縮、分批發送：Kafka 能夠將數據記錄分批發送，從生產者到文件系統（Kafka 主題日誌）到消費者，能夠端到端的查看這些批次的數據。 批處理可以進行更有效的數據壓縮並減小 I/O 延遲。 順序讀寫：Kafka 採起順序寫入磁盤的方式，避免了隨機磁盤尋址的浪費。 Q:講一下Kafka中的零拷貝。 數據的拷貝從內存拷貝到kafka服務進程那塊，又拷貝到socket緩存那塊，整個過程耗費的時間比較高，kafka利用了Linux的sendFile技術（NIO），省去了進程切換和一次數據拷貝，讓性能變得更好。 Q:Kafka的偏移量是什麼？ 消費者每次消費數據的時候，消費者都會記錄消費的物理偏移量（offset）的位置。等到下次消費時，他會接着上次位置繼續消費 Q:Kafka的生產者，是如何發送消息的？ 生產者的消息是先被寫入分區中的緩衝區中，而後分批次發送給 Kafka Broker。 生產者的消息發送機制，有同步發送和異步發送。 同步發送消息都有個問題，那就是同一時間只能有一個消息在發送，這會形成許多消息沒法直接發送，形成消息滯後，沒法發揮效益最大化。 異步發送消息的同時可以對異常狀況進行處理，生產者提供了Callback 回調。 Q:Kafka生產者發送消息，有哪些分區策略？ Kafka 的分區策略指的就是將生產者發送到哪一個分區的算法。 有順序輪詢、隨機輪詢、key-ordering 策略。 key-ordering 策略：Kafka 中每條消息都會有本身的key，一旦消息被定義了 Key，那麼你就能夠保證同一個 Key 的全部消息都進入到相同的分區裏面，因爲每一個分區下的消息處理都是有順序的，故這個策略被稱爲按消息鍵保序策略。

Q:Kafka爲何要分區？ 實現負載均衡和水平擴展。 Kafka能夠將主題(Topic)劃分爲多個分區（Partition），會根據分區規則選擇把消息存儲到哪一個分區中，只要若是分區規則設置的合理，那麼全部的消息將會被均勻的分佈到不一樣的分區中，這樣就實現了負載均衡和水平擴展。另外，多個訂閱者能夠從一個或者多個分區中同時消費數據，以支撐海量數據處理能力。 Q:Kafka如何保證消息的順序性？ Kafka 能夠保證同一個分區裏的消息是有序的。也就是說消息發送到一個Partition 是有順序的。 Q:Kafka的消費者羣組Consumer Group訂閱了某個Topic，假如這個Topic接收到消息並推送，那整個消費者羣組能收到消息嗎？ http://kafka.apache.org/intro Kafka官網中有這樣一句"Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. " 表示推送到topic上的record，會被傳遞到已訂閱的消費者羣組裏面的一個消費者實例。 Q:Kafka消息消費者宕機了，怎麼確認有沒有收到消息？ ack機制，若是接收方收到消息後，會返回一個確認字符。 Q:講一下Kafka的ack機制。 acks 參數指定了要有多少個分區副本接收消息，生產者才認爲消息是寫入成功的。此參數對消息丟失的影響較大。 若是 acks = 0，就表示生產者也不知道本身產生的消息是否被服務器接收了，它才知道它寫成功了。若是發送的途中產生了錯誤，生產者也不知道，它也比較懵逼，由於沒有返回任何消息。這就相似於 UDP 的運輸層協議，只管發，服務器接受不接受它也不關心。 若是 acks = 1，只要集羣的 Leader 接收到消息，就會給生產者返回一條消息，告訴它寫入成功。若是發送途中形成了網絡異常或者 Leader 還沒選舉出來等其餘狀況致使消息寫入失敗，生產者會受到錯誤消息，這時候生產者每每會再次重發數據。由於消息的發送也分爲 同步 和 異步，Kafka 爲了保證消息的高效傳輸會決定是同步發送仍是異步發送。若是讓客戶端等待服務器的響應（經過調用 Future 中的 get() 方法），顯然會增長延遲，若是客戶端使用回調，就會解決這個問題。 若是 acks = all，這種狀況下是隻有當全部參與複製的節點都收到消息時，生產者纔會接收到一個來自服務器的消息。不過，它的延遲比 acks =1 時更高，由於咱們要等待不僅一個服務器節點接收消息。 參考資料： https://juejin.im/post/5ddf5659518825782d599641 Q:Kafka如何避免消息丟失？ 1.生產者丟失消息的狀況： 生產者(Producer) 調用send方法發送消息以後，消息可能由於網絡問題並無發送過去。 因此，咱們不能默認在調用send方法發送消息以後消息消息發送成功了。爲了肯定消息是發送成功，咱們要判斷消息發送的結果。 能夠採用爲其添加回調函數的形式，獲取回調結果。 若是消息發送失敗的話，咱們檢查失敗的緣由以後從新發送便可！ 能夠設置 Producer 的retries（重試次數）爲一個比較合理的值，通常是 3 ，可是爲了保證消息不丟失的話通常會設置比較大一點。 設置完成以後，當出現網絡問題以後可以自動重試消息發送，避免消息丟失。 2.消費者丟失消息的狀況： 當消費者拉取到了分區的某個消息以後，消費者會自動提交了 offset。自動提交的話會有一個問題， 試想一下，當消費者剛拿到這個消息準備進行真正消費的時候，忽然掛掉了，消息實際上並無被消費，可是 offset 卻被自動提交了。 手動關閉閉自動提交 offset，每次在真正消費完消息以後以後再本身手動提交 offset 。 3.Kafka丟失消息： a.假如 leader 副本所在的 broker 忽然掛掉，那麼就要從 follower 副本從新選出一個 leader ，可是 leader 的數據還有一些沒有被 follower 副本的同步的話，就會形成消息丟失。 所以能夠設置ack=all。 b.設置 replication.factor >= 3 爲了保證 leader 副本能有 follower 副本能同步消息，咱們通常會爲 topic 設置 replication.factor >= 3。這樣就能夠保證每一個 分區(partition) 至少有 3 個副本。雖然形成了數據冗餘，可是帶來了數據的安全性。 詳情參考：https://blog.csdn.net/qq_34337272/article/details/104903388?fps=1&locationNum=2 Q:Kafka怎麼保證可靠性？(存疑) 在Kafka中主要經過ISR機制來保證消息的可靠性。 ISR（in sync replica）：是Kafka動態維護的一組同步副本，在ISR中有成員存活時，只有這個組的成員才能夠成爲leader，內部保存的爲每次提交信息時必須同步的副本（acks = all時），每當leader掛掉時，在ISR集合中選舉出一個follower做爲leader提供服務，當ISR中的副本被認爲壞掉的時候，會被踢出ISR，當從新跟上leader的消息數據時，從新進入ISR。 詳情見： https://www.jianshu.com/p/ebeaa7593d83 Q:Kafka怎麼保證一致性？(存疑) 一致性定義：若某條消息對client可見，那麼即便Leader掛了，在新Leader上數據依然能夠被讀到。 HW-HighWaterMark: client能夠從Leader讀到的最大msg offset，即對外可見的最大offset， HW=max(replica.offset) 對於Leader新收到的msg，client不能馬上消費，Leader會等待該消息被全部ISR中的replica同步後，更新HW，此時該消息才能被client消費，這樣就保證了若是Leader fail，該消息仍然能夠重新選舉的Leader中獲取。 對於來自內部Broker的讀取請求，沒有HW的限制。同時，Follower也會維護一份本身的HW，Folloer.HW = min(Leader.HW, Follower.offset) 詳情見：https://www.jianshu.com/p/f0449509fb11 Q:Kafka怎麼處理重複消息？怎麼避免重複消費？ 通常狀況下，kafka重複消費都是因爲未正常提交offset形成的。 使用的是spring-Kafka，因此把Kafka消費者的配置enable.auto.commit設爲false，禁止Kafka自動提交offset，從而使用spring-Kafka提供的offset提交策略。 spring-Kafka中的offset提交策略能夠保證一批消息數據沒有完成消費的狀況下，也能提交offset，從而避免了提交失敗而致使永遠重複消費的問題。

如何去重：將消息的惟一標識保存起來，每次消費時判斷是否處理過便可。 Q:Kafka消息是採用pull模式，仍是push模式？ pull模式。 Q:pull模式和push模式，各有哪些特色？ pull模式，準確性？能夠較大保證消費者能獲取到消息。 push模式，即時性？能夠在broker獲取消息後立刻送達消費者。 Q:講一下Kafka集羣的Leader選舉機制。 Kafka在Zookeeper上針對每一個Topic都維護了一個ISR（in-sync replica---已同步的副本）的集合，集合的增減Kafka都會更新該記錄。若是某分區的Leader不可用，Kafka就從ISR集合中選擇一個副本做爲新的Leader。

###分庫分表 Q:數據庫如何處理海量數據？ 分庫分表，主從架構，讀寫分離 Q:數據庫分庫分表，什麼時候分？怎麼分？ 水平分庫/分表，垂直分庫/分表 水平分庫/表，各個庫和表的結構如出一轍。 垂直分庫/表，各個庫和表的結構不同。 Q:讀寫分離怎麼作？ 主機負責寫，從機負責讀。

###分佈式、高併發場景 Q:在實踐中，遇到過哪些併發的業務場景？ 秒殺。好比搶商品，搶紅包。 Q:如何設計一個秒殺/搶券系統？ 能夠經過隊列配合異步處理實現秒殺。 使用redis的list，將商品push進隊列，pop出隊列。 異步操做不會阻塞，不會消耗太多時間。 Q:如何提升搶券系統的性能？ 使用多個list。 使用多線程從隊列中拉取數據。 集羣提升可用性。 MQ異步處理，削峯。 Q:秒殺怎麼避免少賣或超賣？ redis是單進程單線程的，操做具備原子性，不會致使少賣或者超賣。 另外，也能夠設置一個版本號version，樂觀鎖機制。

###系統架構與設計 Q:如何提升系統的併發能力？ 使用分佈式系統。 部署多臺服務器，並作負載均衡。 使用緩存(Redis)集羣。 數據庫分庫分表 + 讀寫分離。 引入消息中間件集羣。 Q:設計一個紅包系統，須要考慮哪些問題，如何解決？(本質上也是秒殺系統) Q:若是讓你設計一個消息隊列，你會怎麼設計？ ###SpringCloud(微服務) Q:你用過SpringCloud的哪些組件？ 服務協調，註冊中心，熔斷，降級，配置中心，網關。 Q:講一下熔斷和降級的區別？ Q:熔斷有哪幾種方隔離方式？ 線程池隔離。信號量隔離。 Q:Zuul網關，有什麼功能？ Q:Zuul網關如何實現路由？ 參考資料： Java 工程師進階知識徹底掃盲 【Java學習+面試指南】 石杉的架構筆記