大家在就業(yè)的時候都會遇到面試的問題，面試題回答的如何關(guān)系到能否順利入職。動力節(jié)點java培訓(xùn)機構(gòu)的小編為大家總結(jié)了java分布式面試題基礎(chǔ)部分，希望對大家能夠有所幫助。

Java面試題分布式基礎(chǔ)部分

1.Dubbo的底層實現(xiàn)原理和機制

–高性能和透明化的RPC遠程服務(wù)調(diào)用方案

–SOA服務(wù)治理方案

Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊，

適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費者機器數(shù)遠大于服務(wù)提供者機器數(shù)的情況

2.描述一個服務(wù)從發(fā)布到被消費的詳細過程

務(wù)。首先先獲取zk的配置信息，然后獲取需要暴露的url，然后調(diào)用registry.register方法將url注冊到zookeeper上去。

3.分布式系統(tǒng)怎么做服務(wù)治理

針對互聯(lián)網(wǎng)業(yè)務(wù)的特點，eg 突發(fā)的流量高峰、網(wǎng)絡(luò)延時、機房故障等，重點針對大規(guī)模跨機房的海量服務(wù)進行運行態(tài)治理，保障線上服務(wù)的高SLA，滿足用戶的體驗，常用的策略包括限流降級、服務(wù)嵌入遷出、服務(wù)動態(tài)路由和灰度發(fā)布等

4.接口的冪等性的概念

冪等的意思是同一個操作，重復(fù)執(zhí)行多次，跟執(zhí)行一次結(jié)果一致。消息冪等，即消息發(fā)送操作對于消息消費來說是冪等。也就是相同的消息發(fā)送多次，跟發(fā)送一次是一樣的，這個消息只會被消費一次。

5.消息中間件如何解決消息丟失問題

為了解決消息丟失問題，我們引入了一些重發(fā)機制，但也帶來的另外一個問題：消息重復(fù)，我們來看下都有哪些情況會導(dǎo)致消息重復(fù)：

消息發(fā)送超時，處于不確定狀態(tài)，導(dǎo)致重試發(fā)送消息，有可能之前的消息已經(jīng)發(fā)送成功，會出現(xiàn)消息重復(fù)的情況。解決的思路是，每個消息生成一個消息id，如果發(fā)送的消息Broker已經(jīng)存在了，則丟棄。這種解決辦法需要維護一個已經(jīng)接收的消息的message id list。

消息在Broker中只有一份，但是consumer重啟前，未及時更新offset，導(dǎo)致consumer重啟之后重復(fù)消費消息。

上游業(yè)務(wù)給每個message 分配一個message ID，下游業(yè)務(wù)在接收到message之后，執(zhí)行業(yè)務(wù)并且保存message ID，而且要講兩部分放到同一個事務(wù)中，保證業(yè)務(wù)執(zhí)行成功，message ID肯定保存，業(yè)務(wù)執(zhí)行失敗，message ID肯定不會保存下來，利用db中存儲的message id來做冪等。我們可以重新封裝producer client和consumer client，將這部分message ID分配和判重的邏輯封裝到client lib里面。

6.Dubbo的服務(wù)請求失敗怎么處理

dubbo啟動時默認有重試機制和超時機制。

超時機制的規(guī)則是如果在一定的時間內(nèi)，provider沒有返回，則認為本次調(diào)用失敗，

重試機制在出現(xiàn)調(diào)用失敗時，會再次調(diào)用。如果在配置的調(diào)用次數(shù)內(nèi)都失敗，則認為此次請求異常，拋出異常。

7.重連機制會不會造成錯誤

dubbo在調(diào)用服務(wù)不成功時，默認會重試2次。

Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務(wù)的質(zhì)量。

但是如果不合理的配置重試次數(shù)，當失敗時會進行重試多次，這樣在某個時間點出現(xiàn)性能問題，調(diào)用方再連續(xù)重復(fù)調(diào)用，系統(tǒng)請求變?yōu)檎Ｖ档膔etries倍，系統(tǒng)壓力會大增，容易引起服務(wù)雪崩，需要根據(jù)業(yè)務(wù)情況規(guī)劃好如何進行異常處理，何時進行重試。

8.對分布式事務(wù)的理解

本質(zhì)上來說，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

事務(wù)的ACID特性 原子性 一致性 隔離性 持久性 消息事務(wù)+最終一致性

CC提供了一個編程框架，將整個業(yè)務(wù)邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進入Cancel階段，會去恢復(fù)庫存。總之，TCC就是通過代碼人為實現(xiàn)了兩階段提交，不同的業(yè)務(wù)場景所寫的代碼都不一樣，復(fù)雜度也不一樣，因此，這種模式并不能很好地被復(fù)用。

9.如何實現(xiàn)負載均衡，有哪些算法可以實現(xiàn)?

經(jīng)常會用到以下四種算法：隨機(random)、輪訓(xùn)(round-robin)、一致哈希(consistent-hash)和主備(master-slave)。

10.zookeeper watch機制

Znode發(fā)生變化(Znode本身的增加，刪除，修改，以及子Znode的變化)可以通過Watch機制通知到客戶端。那么要實現(xiàn)Watch，就必須實現(xiàn)org.apache.zookeeper.Watcher接口，并且將實現(xiàn)類的對象傳入到可以Watch的方法中。Zookeeper中所有讀操作(getData()，getChildren()，exists())都可以設(shè)置Watch選項。

11.分布式集群下如何做到唯一序列號

Redis生成ID 這主要依賴于Redis是單線程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY來實現(xiàn)。

12.用過哪些MQ，怎么用的，和其他mq比較有什么優(yōu)缺點，MQ的連接是線程安全的嗎

RabbitMQ 支持 AMQP(二進制)，STOMP(文本)，MQTT(二進制)，HTTP(里面包裝其他協(xié)議)等協(xié)議。Kafka 使用自己的協(xié)議。

Kafka 自身服務(wù)和消費者都需要依賴 Zookeeper。

RabbitMQ 在有大量消息堆積的情況下性能會下降，Kafka不會。畢竟AMQP設(shè)計的初衷不是用來持久化海量消息的，而Kafka一開始是用來處理海量日志的。

總的來說，RabbitMQ 和 Kafka 都是十分優(yōu)秀的分布式的消息代理服務(wù)，只要合理部署，不作，基本上可以滿足生產(chǎn)條件下的任何需求。

13.MQ系統(tǒng)的數(shù)據(jù)如何保證不丟失

在數(shù)據(jù)生產(chǎn)時避免數(shù)據(jù)丟失的方法：

只要能避免上述兩種情況，那么就可以保證消息不會被丟失。

(1)就是說在同步模式的時候，確認機制設(shè)置為-1，也就是讓消息寫入leader和所有的副本。

(2)還有，在異步模式下，如果消息發(fā)出去了，但還沒有收到確認的時候，緩沖池滿了，在配置文件中設(shè)置成不限制阻塞超時的時間，也就說讓生產(chǎn)端一直阻塞，這樣也能保證數(shù)據(jù)不會丟失。

在數(shù)據(jù)消費時，避免數(shù)據(jù)丟失的方法：如果使用了storm，要開啟storm的ackfail機制;如果沒有使用storm，確認數(shù)據(jù)被完成處理之后，再更新offset值。低級API中需要手動控制offset值。

數(shù)據(jù)重復(fù)消費的情況，如果處理

(1)去重：將消息的唯一標識保存到外部介質(zhì)中，每次消費處理時判斷是否處理過;

(2)不管：大數(shù)據(jù)場景中，報表系統(tǒng)或者日志信息丟失幾條都無所謂，不會影響最終的統(tǒng)計分析結(jié)

14.列舉出你能想到的數(shù)據(jù)庫分庫分表策略;分庫分表后，如何解決全表查詢的問題

業(yè)務(wù)拆分、主從復(fù)制，數(shù)據(jù)庫分庫與分表

使用用戶ID是最常用的分庫的路由策略。用戶的ID可以作為貫穿整個系統(tǒng)用的重要字段。因此，使用用戶的ID我們不僅可以方便我們的查詢

垂直分表

水平分表

15.zookeeper的選舉策略

在zookeeper集群中也是一樣，每個節(jié)點都會投票，如果某個節(jié)點獲得超過半數(shù)以上的節(jié)點的投票，則該節(jié)點就是leader節(jié)點了。

zookeeper中有三種選舉算法，分別是LeaderElection,FastLeaderElection,AuthLeaderElection，F(xiàn)astLeaderElection此算法和LeaderElection不同的是它不會像后者那樣在每輪投票中要搜集到所有結(jié)果后才統(tǒng)計投票結(jié)果，而是不斷的統(tǒng)計結(jié)果，一旦沒有新的影響leader結(jié)果的notification出現(xiàn)就返回投票結(jié)果。這樣的效率更高。

以上就是動力節(jié)點java培訓(xùn)機構(gòu)的小編針對“java分布式面試題基礎(chǔ)部分”的內(nèi)容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。