java分布式面試題基礎部分

大家在就業(yè)的時候都會遇到面試的問題，面試題回答的如何關系到能否順利入職。長沙中公優(yōu)就業(yè)java培訓機構的小編為大家總結了java分布式面試題基礎部分，希望對大家能夠有所幫助。

Java面試題分布式基礎部分

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

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

–SOA服務治理方案

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

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

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

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

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

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

4.接口的冪等性的概念

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

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

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

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

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

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

6.Dubbo的服務請求失敗怎么處理

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

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

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

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

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

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

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

8.對分布式事務的理解

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

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

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

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

經(jīng)常會用到以下四種算法：隨機(random)、輪訓(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())都可以設置Watch選項。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務拆分、主從復制，數(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不同的是它不會像后者那樣在每輪投票中要搜集到所有結果后才統(tǒng)計投票結果，而是不斷的統(tǒng)計結果，一旦沒有新的影響leader結果的notification出現(xiàn)就返回投票結果。這樣的效率更高。

以上就是長沙中公優(yōu)就業(yè)java培訓機構的小編針對“java分布式面試題基礎部分”的內(nèi)容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務。