1、Dubbo的底層實現原理和機制node
–高性能和透明化的RPC遠程服務調用方案redis
–SOA服務治理方案算法
Dubbo缺省協議採用單一長鏈接和NIO異步通信，數據庫
適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況apache
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的服務請求失敗怎麼處理
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