1、Dubbo的底層實現原理和機制

–高性能和透明化的RPC遠程服務調用方案

–SOA服務治理方案

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

適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況

2、描述一個服務從發布到被消費的詳細過程

務。首先先獲取zk的配置信息，然後獲取需要暴露的url，然後調用registry.register方法將url註冊到zookeeper上去。

3、分布式系統怎麽做服務治理

針對互聯網業務的特點，eg 突發的流量高峰、網絡延時、機房故障等，重點針對大規模跨機房的海量服務進行運行態治理，保障線上服務的高SLA，滿足用戶的體驗，常用的策略包括限流降級、服務嵌入遷出、服務動態路由和灰度發布等

4、接口的冪等性的概念

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

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

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

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

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

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

6、

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

超時機制的規則是如果在一定的時間內，provider沒有返回，則認為本次調用失敗，

重試機制在出現調用失敗時，會再次調用。如果在配置的調用次數內都失敗，則認為此次請求異常，拋出異常。

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

dubbo在調用服務不成功時，默認會重試2次。

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

但是如果不合理的配置重試次數，當失敗時會進行重試多次，這樣在某個時間點出現性能問題，調用方再連續重復調用，

系統請求變為正常值的retries倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。

8、對分布式事務的理解

本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。

事務的ACID特性 原子性 一致性 隔離性 持久性

消息事務+最終一致性

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

9、如何實現負載均衡，有哪些算法可以實現？

經常會用到以下四種算法：隨機（random）、輪訓（round-robin）、一致哈希（consistent-hash）和主備（master-slave）。

10、Zookeeper的用途，選舉的原理是什麽？

11、數據的垂直拆分水平拆分。

12、zookeeper原理和適用場景

13、zookeeper watch機制

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

14、redis/zk節點宕機如何處理

15、分布式集群下如何做到唯一序列號

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

16、如何做一個分布式鎖

17、用過哪些MQ，怎麽用的，和其他mq比較有什麽優缺點，MQ的連接是線程安全的嗎

RabbitMQ 支持 AMQP（二進制），STOMP（文本），MQTT（二進制），HTTP（裏面包裝其他協議）等協議。Kafka 使用自己的協議。

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

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

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

18、MQ系統的數據如何保證不丟失

在數據生產時避免數據丟失的方法：

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

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

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

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

數據重復消費的情況，如果處理

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

（2）不管：大數據場景中，報表系統或者日誌信息丟失幾條都無所謂，不會影響最終的統計分析結

19、列舉出你能想到的數據庫分庫分表策略；分庫分表後，如何解決全表查詢的問題

業務拆分、主從復制，數據庫分庫與分表

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

垂直分表

水平分表

20、zookeeper的選舉策略

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

zookeeper中有三種選舉算法，分別是LeaderElection,FastLeaderElection,AuthLeaderElection，

FastLeaderElection此算法和LeaderElection不同的是它不會像後者那樣在每輪投票中要搜集到所有結果後才統計投票結果，而是不斷的統計結果，一旦沒有新的影響leader結果的notification出現就返回投票結果。這樣的效率更高。

21、全局ID

Snowflake

redis

java面試中經常會被到分布式面試題