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

大家在就業(yè)的時(shí)候都會(huì)遇到面試的問題，面試題回答的如何關(guān)系到能否順利入職。長(zhǎng)沙中公優(yōu)就業(yè)java培訓(xùn)機(jī)構(gòu)的小編為大家總結(jié)了java分布式面試題基礎(chǔ)部分，希望對(duì)大家能夠有所幫助。

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

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

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

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

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

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

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

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

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

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

4.接口的冪等性的概念

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

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

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

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

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

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

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

dubbo啟動(dòng)時(shí)默認(rèn)有重試機(jī)制和超時(shí)機(jī)制。

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

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

7.重連機(jī)制會(huì)不會(huì)造成錯(cuò)誤

dubbo在調(diào)用服務(wù)不成功時(shí)，默認(rèn)會(huì)重試2次。

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

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

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

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

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

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

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

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

10.zookeeper watch機(jī)制

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

11.分布式集群下如何做到唯一序列號(hào)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

垂直分表

水平分表

15.zookeeper的選舉策略

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

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

以上就是長(zhǎng)沙中公優(yōu)就業(yè)java培訓(xùn)機(jī)構(gòu)的小編針對(duì)“java分布式面試題基礎(chǔ)部分”的內(nèi)容進(jìn)行的回答，希望對(duì)大家有所幫助，如有疑問，請(qǐng)?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為你服務(wù)。