一、注冊(cè)中心

策略：服務(wù)注冊(cè)原理、注冊(cè)中心結(jié)構(gòu)、zookeeper的原理、幾個(gè)注冊(cè)中心的區(qū)別、分布式算法、分布式事務(wù)。

項(xiàng)目細(xì)節(jié)：服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)注銷(xiāo)、監(jiān)聽(tīng)機(jī)制

1. 介紹一下服務(wù)注冊(cè)中心怎么做的？

   （1）服務(wù)發(fā)現(xiàn)：

   • 服務(wù)注冊(cè)/反注冊(cè)：保存服務(wù)提供者和服務(wù)調(diào)用者的信息
   • 服務(wù)訂閱/取消訂閱：服務(wù)調(diào)用者訂閱服務(wù)提供者的信息，最好有實(shí)時(shí)推送的功能
   • 服務(wù)路由（可選）：具有篩選整合服務(wù)提供者的能力。

   （2）服務(wù)配置（不包括其它無(wú)關(guān)配置）：

   • 配置訂閱：服務(wù)提供者和服務(wù)調(diào)用者訂閱微服務(wù)相關(guān)的配置
   • 配置下發(fā)（可選）：主動(dòng)將配置推送給服務(wù)提供者和服務(wù)調(diào)用者

   （3）服務(wù)健康檢測(cè)

   • 檢測(cè)服務(wù)提供者的健康情況

2. 一個(gè)注冊(cè)中心,至少需要具備哪些條件?

   （項(xiàng)目中RPC服務(wù)注冊(cè)中心需要注意什么?）

   （如果讓你設(shè)計(jì)一個(gè)服務(wù)注冊(cè)中心，怎么設(shè)計(jì)？）

   服務(wù)注冊(cè)接口：服務(wù)提供者通過(guò)調(diào)用服務(wù)注冊(cè)接口來(lái)完成服務(wù)注冊(cè)。

   服務(wù)反注冊(cè)接口：服務(wù)提供者通過(guò)調(diào)用服務(wù)反注冊(cè)接口來(lái)完成服務(wù)注銷(xiāo)。

   心跳匯報(bào)接口：服務(wù)提供者通過(guò)調(diào)用心跳匯報(bào)接口完成節(jié)點(diǎn)存活狀態(tài)上報(bào)。

   服務(wù)訂閱接口：服務(wù)消費(fèi)者通過(guò)調(diào)用服務(wù)訂閱接口完成服務(wù)訂閱，獲取可用的服務(wù)提供者節(jié)點(diǎn)列表。

   服務(wù)變更查詢(xún)接口：服務(wù)消費(fèi)者通過(guò)調(diào)用服務(wù)變更查詢(xún)接口，獲取最新的可用服務(wù)節(jié)點(diǎn)列表。

   服務(wù)查詢(xún)接口：查詢(xún)注冊(cè)中心當(dāng)前注冊(cè)了哪些服務(wù)信息。

   服務(wù)修改接口：修改注冊(cè)中心中某一服務(wù)的信息。

3. 注冊(cè)中心單機(jī)還是分布式的，其中一個(gè)掛了怎么辦？一致性，可靠性怎么保證的？超時(shí)控制，加鎖和管道支持并發(fā)，單機(jī)（考慮了多機(jī)情況

4. 常用的服務(wù)注冊(cè)中心, 注冊(cè)中心的差異

5. 為什么用Zookeeper做注冊(cè)中心？(優(yōu)點(diǎn)，與其他選型對(duì)比下)

   （使用zookeeper有什么好處？）

   （說(shuō)一下zookeeper，為什么使用zookeeper，不選其他注冊(cè)中心？）

   （了解Nacos和Zookeeper的區(qū)別嗎？）

   （為什么不選擇Redis作為注冊(cè)中心？（zookeeper臨時(shí)節(jié)點(diǎn)自動(dòng)宕機(jī)自動(dòng)清除））

   （為什么要用Zookeeper（服務(wù)注冊(cè)、發(fā)現(xiàn)））

   （Zookeeper和Eureka分別是滿(mǎn)足CAP中的哪些）

6. 集群一般有幾個(gè)節(jié)點(diǎn)，為什么？

   5個(gè)，宕機(jī)后選舉要大于一半成為leader。

7. socket過(guò)程中發(fā)生的系統(tǒng)調(diào)用

8. zookeeper服務(wù)發(fā)現(xiàn)

9. zookeeper服務(wù)容災(zāi)？zookeeper服務(wù)節(jié)點(diǎn)掛掉之后，怎么刪除它？

   容災(zāi)：在集群若干臺(tái)故障后，整個(gè)集群仍然可以對(duì)外提供可用的服務(wù)。

   一般配置奇數(shù)臺(tái)去構(gòu)成集群，以避免資源的浪費(fèi)。

   三機(jī)房部署是最常見(jiàn)的、容災(zāi)性最好的部署方案。

   刪除：使用臨時(shí)節(jié)點(diǎn)，會(huì)話(huà)失效，節(jié)點(diǎn)自動(dòng)清除。

10. Zookeeper有幾種角色？

    群首（leader），追隨者（follower），觀察者（observer）

11. CAP理論解釋下？P是什么？

    • 一致性（Consistency）多個(gè)副本之間的數(shù)據(jù)一致性

    • 可用性（Availability）在合理規(guī)定的時(shí)間內(nèi)，是否能返回一個(gè)明確的結(jié)果。

    • 分區(qū)容錯(cuò)性（Partition tolerance）在分區(qū)故障下，仍然可以對(duì)外提供正常的服務(wù)。

      一個(gè)分布式系統(tǒng)在以上三個(gè)特性中：最多滿(mǎn)足其中的兩個(gè)特性。

12. Zookeeper集群節(jié)點(diǎn)宕機(jī)了怎么發(fā)現(xiàn)剔除的？

    發(fā)現(xiàn)：watcher機(jī)制

    剔除：臨時(shí)節(jié)點(diǎn)？

13. 服務(wù)熔斷和服務(wù)降級(jí)有什么區(qū)別？

    **服務(wù)熔斷：**如果某個(gè)目標(biāo)服務(wù)調(diào)用慢或者有大量超時(shí)，此時(shí)，熔斷該服務(wù)的調(diào)用，對(duì)于后續(xù)調(diào)用請(qǐng)求，不在繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。

    **服務(wù)降級(jí)：**當(dāng)服務(wù)器壓力劇增的情況下，根據(jù)當(dāng)前業(yè)務(wù)情況及流量對(duì)一些服務(wù)和頁(yè)面有策略的降級(jí)，以此釋放服務(wù)器資源以保證核心任務(wù)的正常運(yùn)行。

14. zookeeper原理？羊群效應(yīng)，怎么解決，解決之后又有什么問(wèn)題，又怎么解決，純粹搞成了循環(huán)依賴(lài)了。zab協(xié)議，具體說(shuō)來(lái)。

    羊群效應(yīng)：

15. ZAB算法講一下（講了ZAB是paxos的改版，Mysql是paxos、redis sentinel是raft、zookeeper是ZAB、ZAB的具體實(shí)現(xiàn)）

16. zk的分布式算法zab，如果選舉的時(shí)候zxid都相同呢？（比較SID）

17. dubbo 怎么注冊(cè)到zookeeper以及 dubbo 協(xié)議，zookeeper協(xié)議，

18. zookeeper的節(jié)點(diǎn)類(lèi)型?（持久，臨時(shí)，順序）

19. 分布式數(shù)據(jù)一致性協(xié)議都知道哪些（2PC 3PC Paxos）

20. Raft了不了解

21. 分布式事務(wù)的幾種解決方案（2PC，3PC，TCC，基于消息，然后順帶講了一下優(yōu)缺點(diǎn)） 分布式事務(wù)的幾種方式吧（2pc、3pc、tcc、基于消息）以及區(qū)別

22. Zookeeper 是如何保證一致性的？

    zookeeper 的一致性，為了防止單機(jī)掛掉，zookeeper維護(hù)了一個(gè)集群，實(shí)現(xiàn)自身的高可用。

    重點(diǎn)回答zookeeper的ZAB協(xié)議

    事務(wù)的順序一致性：全局唯一事務(wù)ID,ZXID

23. 你知道Zookeeper的分布式鎖實(shí)現(xiàn)方式嗎？（臨時(shí)節(jié)點(diǎn)，如果服務(wù)器掛了，鎖會(huì)自己消失）

24. ZooKeeper的作用？

    項(xiàng)目答：注冊(cè)中心。

    擴(kuò)展答：

    1.數(shù)據(jù)發(fā)布/訂閱

    2.自動(dòng)化的DNS服務(wù)

    3.數(shù)據(jù)庫(kù)復(fù)制處理

    4.基于zookeeper分布式系統(tǒng)機(jī)器間的通信方式

    5.命名服務(wù)

    6.集群管理（監(jiān)控、控制）

    7.Master選舉

    8.分布式鎖

    9.分布式隊(duì)列

25. zookeeper有什么特性，講一下（臨時(shí)節(jié)點(diǎn)、持久節(jié)點(diǎn)、ZAB）

26. 服務(wù)下線(xiàn)還有沒(méi)有別的實(shí)現(xiàn)方法（這就算引導(dǎo)了，結(jié)合前面的問(wèn)題，使用臨時(shí)節(jié)點(diǎn)）

27. zookeeper宕機(jī)與dubbo直連的情況？

    zookeeper注冊(cè)中心宕機(jī)–>dubbo直連,可以調(diào)服務(wù)

    zookeeper宕機(jī)了，消費(fèi)者可以通過(guò)本地緩存通信調(diào)提供者的服務(wù)

    現(xiàn)象：zookeeper注冊(cè)中心宕機(jī)，還可以消費(fèi)dubbo暴露的服務(wù)。
    原因：健壯性

    監(jiān)控中心宕掉不影響使用，只是丟失部分采樣數(shù)據(jù)
    數(shù)據(jù)庫(kù)宕掉后，注冊(cè)中心仍能通過(guò)緩存提供服務(wù)列表查詢(xún)，但不能注冊(cè)新服務(wù)
    注冊(cè)中心對(duì)等集群，任意一臺(tái)宕掉后，將自動(dòng)切換到另一臺(tái)
    注冊(cè)中心全部宕掉后，服務(wù)提供者和服務(wù)消費(fèi)者仍能通過(guò)本地緩存通訊
    服務(wù)提供者無(wú)狀態(tài)，任意一臺(tái)宕掉后，不影響使用
    服務(wù)提供者全部宕掉后，服務(wù)消費(fèi)者應(yīng)用將無(wú)法使用，并無(wú)限次重連等待服務(wù)提供者恢復(fù)
    

28. 任何一個(gè)請(qǐng)求(流量)過(guò)來(lái)都會(huì)打到注冊(cè)中心么?（不會(huì)，第一次會(huì)，有本地緩存）

29. 有一大批流量總是被打到一個(gè)實(shí)例上面,這個(gè)實(shí)例的兄弟實(shí)例分到的流量很少,怎么辦?

    (通過(guò)合理負(fù)載均衡)

30. 有一個(gè)實(shí)例掛了怎么辦?

    （zookeeper心跳檢測(cè)更新列表并利用watcher機(jī)制發(fā)給服務(wù)消費(fèi)者）

31. 注冊(cè)中心怎么進(jìn)行心跳檢測(cè)

32. 注冊(cè)中心對(duì)于服務(wù)端掉線(xiàn)時(shí)怎么處理

    (移出ip鏈表，發(fā)送給服務(wù)消費(fèi)者，等待服務(wù)器上線(xiàn)，重新連接)

33. 服務(wù)端用的哪個(gè)類(lèi)監(jiān)聽(tīng)的（ServerSocket）

34. 自己實(shí)現(xiàn)的定時(shí)器是啥？

35. RPC心跳怎么實(shí)現(xiàn)的？

    是服務(wù)端給服務(wù)注冊(cè)中心心跳還是服務(wù)端給客戶(hù)端心跳？

    服務(wù)調(diào)用方怎么知道服務(wù)不可用了？

    (zookeeper的心跳檢測(cè)+更新ip列表+watcher發(fā)送給服務(wù)調(diào)用方)：注冊(cè)中心發(fā)送

    (利用netty的IdleStateHandler實(shí)現(xiàn)心跳服務(wù))：客戶(hù)端給服務(wù)端發(fā)送PING消息

36. 怎么實(shí)現(xiàn)的類(lèi)似本地調(diào)用？

    本地知道類(lèi)名+服務(wù)名，直接調(diào)用

37. 如果是你如何設(shè)計(jì)一個(gè)nacos ，rpc如何調(diào)用。

38. 如果注冊(cè)中心服務(wù)器宕機(jī)怎么保證高可用？

    高可用：通過(guò)設(shè)置減少系統(tǒng)不能提供服務(wù)的時(shí)間。

    在zookeeper主要考慮***容災(zāi)和擴(kuò)容***兩方面提高高可用。

39. 服務(wù)的地址怎么知道？(注冊(cè)中心)

40. 服務(wù)注冊(cè)信息的拆分要怎么做?

41. 服務(wù)注冊(cè)中心的功能除了放在額外的服務(wù)器上實(shí)現(xiàn)還能放在哪里？怎么實(shí)現(xiàn)?

42. RPC服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)注銷(xiāo)怎么做的？

    服務(wù)注冊(cè)怎么進(jìn)行服務(wù)注銷(xiāo)監(jiān)聽(tīng)?

    RPC項(xiàng)目zookeeper怎么實(shí)現(xiàn)注冊(cè)、發(fā)現(xiàn)的？（臨時(shí)節(jié)點(diǎn)存儲(chǔ)ip+端口+負(fù)載均衡策略）

43. 了解過(guò)zookeeper的問(wèn)題嗎?

    （崩潰恢復(fù)無(wú)法提供服務(wù)、寫(xiě)的性能瓶頸是一個(gè)問(wèn)題、選舉過(guò)程速度緩慢、無(wú)法進(jìn)行有效的權(quán)限控制）

二、序列化與反序列化以及協(xié)議

JSON：

• JSON 進(jìn)行序列化的額外空間開(kāi)銷(xiāo)比較大，對(duì)于大數(shù)據(jù)量服務(wù)這意味著需要巨大的內(nèi)存和磁盤(pán)開(kāi)銷(xiāo)；
• JSON 沒(méi)有類(lèi)型，但像 Java 這種強(qiáng)類(lèi)型語(yǔ)言，需要通過(guò)反射統(tǒng)一解決，所以性能不會(huì)太好（比如反序列化時(shí)先反序列化為String類(lèi)，要自己通過(guò)反射還原）。

Kryo：

• 使用變長(zhǎng)的int和long保證這種基本數(shù)據(jù)類(lèi)型序列化后盡量小
• 需要傳入完整類(lèi)名或者利用 register() 提前將類(lèi)注冊(cè)到Kryo上，其類(lèi)與一個(gè)int型的ID相關(guān)聯(lián)，序列中只存放這個(gè)ID，因此序列體積就更小
• 不是線(xiàn)程安全的，要通過(guò)ThreadLocal或者創(chuàng)建Kryo線(xiàn)程池來(lái)保證線(xiàn)程安全
• 不需要實(shí)現(xiàn)Serializable接口
• 字段增、減，序列化和反序列化時(shí)無(wú)法兼容
• 必須擁有無(wú)參構(gòu)造函數(shù)

Hessian：

• 使用固定長(zhǎng)度存儲(chǔ)int和long
• 將所有類(lèi)字段信息都放入序列化字節(jié)數(shù)組中，直接利用字節(jié)數(shù)組進(jìn)行反序列化，不需要其他參與，因?yàn)榇娴臇|西多處理速度就會(huì)慢點(diǎn)。
• 把復(fù)雜對(duì)象的所有屬性存儲(chǔ)在一個(gè)Map中進(jìn)行序列化。所以在父類(lèi)、子類(lèi)存在同名成員變量的情況下，Hessian序列化時(shí)，先序列化子類(lèi)，然后序列化父類(lèi)，因此反序列化結(jié)果會(huì)導(dǎo)致子類(lèi)同名成員變量被父類(lèi)的值覆蓋
• 需要實(shí)現(xiàn)Serializable接口
• 兼容字段增、減，序列化和反序列化
• 必須擁有無(wú)參構(gòu)造函數(shù)
• Java 里面一些常見(jiàn)對(duì)象的類(lèi)型不支持，比如：
  • Linked 系列，LinkedHashMap、LinkedHashSet 等；
  • Locale 類(lèi)，可以通過(guò)擴(kuò)展 ContextSerializerFactory 類(lèi)修復(fù)；
  • Byte/Short 反序列化的時(shí)候變成 Integer。

Protobuf：

• 序列化后體積相比 JSON、Hessian 小很多
• IDL 能清晰地描述語(yǔ)義，所以足以幫助并保證應(yīng)用程序之間的類(lèi)型不會(huì)丟失，無(wú)需類(lèi)似XML 解析器；
• 序列化反序列化速度很快，不需要通過(guò)反射獲取類(lèi)型；
• 打包生成二進(jìn)制流
• 預(yù)編譯過(guò)程不是必須的

策略：幾個(gè)序列化協(xié)議的區(qū)別以及優(yōu)缺點(diǎn)、Kryo的原理和安全性、兩個(gè)接口區(qū)別。

項(xiàng)目細(xì)節(jié)：在項(xiàng)目怎么定義序列化協(xié)議，怎么定義序列化相關(guān)的類(lèi)以及項(xiàng)目序列化的細(xì)節(jié)，

1. 序列化和反序列化有什么作用

   （1）實(shí)現(xiàn)了數(shù)據(jù)的持久化：永久性保存對(duì)象，保存對(duì)象的字節(jié)序列到本地文件或者數(shù)據(jù)庫(kù)中；
   （2）序列化實(shí)現(xiàn)遠(yuǎn)程通：通過(guò)序列化以字節(jié)流的形式使對(duì)象在網(wǎng)絡(luò)中進(jìn)行傳遞和接收；
   （3）通過(guò)序列化在進(jìn)程間傳遞對(duì)象；

2. Serializable和Externalizable懂嗎？（不知道Externalizable）

   1、Serializable序列化時(shí)不會(huì)調(diào)用默認(rèn)的構(gòu)造器，而Externalizable序列化時(shí)會(huì)調(diào)用默認(rèn)構(gòu)造器的！

   2、Serializable：一個(gè)對(duì)象想要被序列化，它的類(lèi)就要實(shí)現(xiàn) 此接口，這個(gè)對(duì)象的所有屬性都可以被序列化和反序列化來(lái)保存、傳遞。

   Externalizable：自定義序列化可以控制序列化的過(guò)程和決定哪些屬性不被序列化。

   3、使用Externalizable時(shí)，必須按照寫(xiě)入時(shí)的確切順序讀取所有字段狀態(tài)。否則會(huì)產(chǎn)生異常。

3. serializable關(guān)鍵字的作用（實(shí)現(xiàn)原理）？幾種序列化協(xié)議？ProtoBuff的優(yōu)點(diǎn)？

4. 序列化傳輸？

5. 有沒(méi)有閱讀過(guò)序列化（Java Serialization、Fastjson）之后的數(shù)據(jù)

6. RPC 不同序列化協(xié)議了解嗎？?jī)?yōu)缺點(diǎn)是？各種序列號(hào)協(xié)議的特點(diǎn)？序列化方式有哪幾個(gè)，區(qū)別是什么，自己寫(xiě)過(guò)嗎？

   優(yōu)點(diǎn)	缺點(diǎn)
   Kryo	速度快，序列化后體積小	跨語(yǔ)言支持較復(fù)雜
   Hessian	默認(rèn)支持跨語(yǔ)言	較慢
   Protostuff	速度快，基于protobuf	需靜態(tài)編譯
   Protostuff-Runtime	無(wú)需靜態(tài)編譯，但序列化前需預(yù)先傳入schema	不支持無(wú)默認(rèn)構(gòu)造函數(shù)的類(lèi)，反序列化時(shí)需用戶(hù)自己初始化序列化后的對(duì)象，其只負(fù)責(zé)將該對(duì)象進(jìn)行賦值
   Java	使用方便，可序列化所有類(lèi)	速度慢，占空間

7. 為什么選用ProtoBuff？

8. 為什么選KRYO序列化？（面試官提示了壓縮)，java 的壓縮算法

9. 序列化怎么做的（序列化怎么實(shí)現(xiàn)）？Kryo原理了解嗎？

10. 你說(shuō)到你自定義了一個(gè)簡(jiǎn)單協(xié)議，自定義的協(xié)議頭里包括哪些內(nèi)容，多少字節(jié)，各自的作用是什么（魔數(shù)，消息長(zhǎng)度，請(qǐng)求id，消息類(lèi)型）

11. 由RPC項(xiàng)目問(wèn)到了序列化反序列化，問(wèn)到了對(duì)象有一個(gè)屬性是對(duì)象引用，怎么序列化。

12. 如何實(shí)現(xiàn)編解碼及序列化？

13. 那你這個(gè)序列化還是針對(duì)Java語(yǔ)言的，如何實(shí)現(xiàn)跨語(yǔ)言的序列化或者RPC框架？

    Java

    RPC框架要想跨語(yǔ)言，本質(zhì)是在解決序列化/反序列化的跨語(yǔ)言問(wèn)題

三、Netty

策略：BIO、NIO、AIO三者區(qū)別

1.TCP 的粘包的概念是對(duì)的嗎（面試官：TCP 是面向字節(jié)流的，所以這個(gè)概念本身是一個(gè)偽概念，本身就是可以粘的。但是這種現(xiàn)象還是要解決的）

1. 簡(jiǎn)述AIO、BIO、NIO的具體使用、區(qū)別及原理

2. BIO，NIO，AIO的痛點(diǎn)，怎么優(yōu)化?

3. IO/NIO/AIO區(qū)別？介紹Reactor，介紹Proactor？

   為什么BIO比NIO性能差？簡(jiǎn)單講講區(qū)別？

   假設(shè)有100個(gè)連接，采用NIO的方式要服務(wù)端要分配幾個(gè)線(xiàn)程，采用BIO的方式呢？

   為啥要用異步IO不用多線(xiàn)程，不是一樣可以加速嗎？

4. 說(shuō)說(shuō)你對(duì)Netty的認(rèn)識(shí)？

5. NIO中Channel的作用

6. NIO的設(shè)計(jì)架構(gòu)？JDK中NIO有哪些重要組件？

7. 為什么選用Netty來(lái)做通信框架？還知道其他網(wǎng)絡(luò)通信框架？

8. Netty怎么實(shí)現(xiàn)高性能的？Netty高性能主要依賴(lài)了哪些特性？Netty為什么快（基于NIO+零拷貝）Netty為啥效率高（零拷貝，線(xiàn)程模型）

9. netty bytebuf工作原理，和NIO里buffer區(qū)別？

10. 除了Netty還知道哪些網(wǎng)絡(luò)傳輸框架嗎？

11. 為什么大多數(shù)rpc框架都用netty（聊了下Netty的特點(diǎn)）？你為什么會(huì)用到Netty?

12. 同步、異步調(diào)用方式的具體實(shí)現(xiàn)

13. Netty使用場(chǎng)景

14. Netty的線(xiàn)程模型

15. RPC過(guò)程網(wǎng)絡(luò)上發(fā)生了什么

16. RPC多個(gè)請(qǐng)求是在一個(gè)連接完成的嗎

17. Netty服務(wù)調(diào)用如何變成同步的？（不知道）（回答netty中的Reactor模型）

    Netty異步編程怎么做的？

18. 基于Netty實(shí)現(xiàn)通信，使用了哪些TCP優(yōu)化參數(shù)？

    你說(shuō)網(wǎng)絡(luò)通信使用的Netty，你都通過(guò)那些設(shè)置對(duì)Netty進(jìn)行過(guò)調(diào)優(yōu)（我表示Netty的bootstrap的option設(shè)置基本都是模仿Netty官方案例搞的，然后他問(wèn)了我backlog是什么意思）

19. tcp粘包

    粘包半包怎么解決的（LineBased和LengthBased,我是用的是LineBased）

    為什么要使用LineBased，怎么分割的（/r/n，當(dāng)時(shí)沒(méi)有考慮太多，覺(jué)得這個(gè)比較簡(jiǎn)單）

20. Netty解決粘包的幾種方式

    Netty 拆包粘包的實(shí)質(zhì)，Netty線(xiàn)程池中的線(xiàn)程建立連接之后，這條連接是不是始終于這個(gè)請(qǐng)求，對(duì)于Netty來(lái)說(shuō)是不是只占用服務(wù)端的一個(gè)套接字，了解zero copy嘛

    項(xiàng)目中如何解決粘包、拆包的問(wèn)題（基于字符或者基于長(zhǎng)度）

    你這個(gè)報(bào)文傳輸?shù)臅r(shí)候會(huì)不會(huì)遇到報(bào)文粘連的情況？如何解決？

21. Netty底層原理

22. Netty中的select過(guò)程

23. 零拷貝講講（mmap優(yōu)化，sendfile）

24. Netty的兩個(gè)線(xiàn)程池，為什么兩個(gè)，有什么區(qū)別，具體說(shuō)來(lái)。

    Netty初始化的時(shí)候需要初始化兩個(gè)線(xiàn)程池，你能簡(jiǎn)單說(shuō)一說(shuō)嗎？

25. 怎么實(shí)現(xiàn)保持長(zhǎng)連接的（Netty保證的，應(yīng)該是使用了TCP的長(zhǎng)連接特性）

26. 如何實(shí)現(xiàn)心跳保持（IDLE編解碼器監(jiān)聽(tīng)事件）

27. 多少個(gè)線(xiàn)程，為什么這么設(shè)置？（netty自帶的，默認(rèn)CPU*2）

四、負(fù)載均衡

策略：負(fù)載均衡算法（四種）、負(fù)載均衡器設(shè)置、負(fù)載均衡作用

項(xiàng)目實(shí)現(xiàn)：

1. 項(xiàng)目中負(fù)載均衡怎么實(shí)現(xiàn)的（看項(xiàng)目代碼）

   怎么實(shí)現(xiàn)負(fù)載均衡策略的（我只做了最簡(jiǎn)單的輪詢(xún)、加權(quán)、隨機(jī)，通過(guò)在zookeeper中配置，然后將引用按照權(quán)重將Channel的引用加入到一個(gè)List當(dāng)中）

先設(shè)置一個(gè)負(fù)載均衡接口LoadBalancer，然后用繼承接口得到輪詢(xún)、隨機(jī)兩個(gè)類(lèi)，然后在NacosServiceDiscovery設(shè)置一個(gè)loadBalancer屬性及它的函數(shù)，

在SocketTestClient的創(chuàng)建client時(shí)傳入loadBalancer參數(shù)到SocketClient類(lèi)中，serviceDiscovery

測(cè)試類(lèi)中

SocketClient client = new SocketClient(CommonSerializer.KRYO_SERIALIZER, new RoundRobinLoadBalancer());

構(gòu)造函數(shù)

serviceDiscovery = new NacosServiceDiscovery(loadBalancer);

NacosServiceDiscovery中

public NacosServiceDiscovery(LoadBalancer loadBalancer){
if (loadBalancer == null){
this.loadBalancer = new RandomLoadBalancer();
}else {this.loadBalancer = loadBalancer;}}

lookupService方法調(diào)用

Instance instance = loadBalancer.select(instances);

1. 項(xiàng)目中負(fù)載均衡算法用到那些

   輪詢(xún)、隨機(jī)

2. 解釋一下什么是負(fù)載均衡？

   指將負(fù)載（工作任務(wù)）進(jìn)行平衡、分?jǐn)偟蕉鄠€(gè)操作單元上進(jìn)行運(yùn)行

   之后結(jié)合算法回答

3. 負(fù)載均衡了解哪些(dubbo的四種策略說(shuō)了下（輪詢(xún)、隨機(jī)、一致性哈希、最小活躍數(shù)）

   (1) RandomLoadBalance:隨機(jī)負(fù)載均衡。隨機(jī)的選擇一個(gè)。是Dubbo的默認(rèn)負(fù)載均衡策略(Dubbo 中的隨機(jī)負(fù)載是按照權(quán)重設(shè)置隨機(jī)概率)。

   (2) RoundRobinLoadBalance:輪詢(xún)負(fù)載均衡。輪詢(xún)選擇一個(gè)(Dubbo中有權(quán)重的概念，按公約后的權(quán)重設(shè)置輪詢(xún)比率)。

   問(wèn)題：存在慢的提供者請(qǐng)求的問(wèn)題，比如：第二胎機(jī)器很慢，但沒(méi)掛，當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那，久而久之，所有請(qǐng)求都卡在調(diào)到第二臺(tái)上

   (3) LeastActiveLoadBalance:最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī)?；钴S數(shù)指調(diào)用前后計(jì)數(shù)差。

   好處：使慢的 Provider 收到更少請(qǐng)求，因?yàn)樵铰?Provider 的調(diào)用前后計(jì)數(shù)差會(huì)越大。

   (4) ConsistentHashLoadBalance:一致性哈希負(fù)載均衡。一致性hash：添加刪除機(jī)器前后映射關(guān)系一致，當(dāng)然，不是嚴(yán)格一致。實(shí)現(xiàn)的關(guān)鍵是環(huán)形Hash空間。將數(shù)據(jù)和機(jī)器都hash到環(huán)上，數(shù)據(jù)映射到順時(shí)針離自己最近的機(jī)器中。

   好處：當(dāng)某一臺(tái)提供者掛時(shí)，原本該發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其他提供者，不會(huì)引起劇烈變動(dòng)

4. RPC調(diào)用中使用隨機(jī)算法和輪轉(zhuǎn)算法做負(fù)載均衡的優(yōu)缺點(diǎn)

   優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，水平擴(kuò)展方便

   缺點(diǎn)：因?yàn)橄嗤恼?qǐng)求會(huì)被落到不同的機(jī)器上，浪費(fèi)內(nèi)存啊，內(nèi)存有限，Cache會(huì)被淘汰，頻繁淘汰，當(dāng)然使得命中率低下啊。

5. dubbo負(fù)載均衡算法，一致性哈希的實(shí)現(xiàn)？

   1.問(wèn)簡(jiǎn)單的話(huà)，用4.(4)

   2.難的話(huà)源碼

6. Dubbo為什么推薦基于隨機(jī)的負(fù)載均衡？

   1.實(shí)現(xiàn)簡(jiǎn)單，水平擴(kuò)展方便

   2.在一個(gè)截面上碰撞的概率高，但調(diào)用越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重

7. 負(fù)載均衡作用

   （1）根據(jù)集群中每個(gè)節(jié)點(diǎn)的負(fù)載情況將用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)到合適的節(jié)點(diǎn)上, 以避免單點(diǎn)壓力過(guò)大的問(wèn)題

   （2）負(fù)載均衡可實(shí)現(xiàn)集群高可用及伸縮性

   高可用：某個(gè)節(jié)點(diǎn)故障時(shí)，負(fù)載均衡器會(huì)將用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)到其他節(jié)點(diǎn),從而保證所有服務(wù)持續(xù)可用.

   伸縮性：根據(jù)系統(tǒng)整體負(fù)載情況，可以很容易地添加或移除節(jié)點(diǎn)。

8. 如何設(shè)計(jì)負(fù)載均衡器

   負(fù)載均衡器工作原理有兩大方法：

   1. 接收客戶(hù)端請(qǐng)求，將請(qǐng)求轉(zhuǎn)發(fā)給集群中的各臺(tái)服務(wù)器處理，服務(wù)器將處理結(jié)果返回給負(fù)載均衡器，負(fù)載均衡器將處理結(jié)果轉(zhuǎn)發(fā)給相應(yīng)的客戶(hù)端。
   2. 接收客戶(hù)端請(qǐng)求，將請(qǐng)求轉(zhuǎn)發(fā)給集群中的各臺(tái)服務(wù)器處理，服務(wù)器將處理結(jié)果直接返回給相應(yīng)的客戶(hù)端。

9. 負(fù)載均衡如何保證健壯性？

   （采用心跳機(jī)制檢測(cè)宕機(jī)節(jié)點(diǎn)。）

10. 一個(gè)服務(wù)可能有多臺(tái)機(jī)器可以調(diào)用?（利用負(fù)載均衡算法）

五、RPC 和 HTTP

1. RPC 有沒(méi)有可能會(huì)用 HTTP 協(xié)議？（有，如 grpc 就是 HTTP2.0）

2. RPC 和 HTTP的對(duì)比？為什么要用 RPC？

   1、傳輸協(xié)議：

   RPC：基于HTTP協(xié)議，TCP協(xié)議

   HTTP：基于HTTP協(xié)議

   2、傳輸效率：

   RPC：(1)使用自定義的TCP協(xié)議，請(qǐng)求報(bào)文體積更小，

   (2)使用HTTP2協(xié)議，也可以很好的減小報(bào)文體積，提高傳輸效率

   HTTP：(1)基于http1.1的協(xié)議，請(qǐng)求中會(huì)包含很多無(wú)用的內(nèi)容，

   (2)基于HTTP2.0，那么簡(jiǎn)單的封裝下可以作為一個(gè)RPC來(lái)使用，這時(shí)標(biāo)準(zhǔn)的RPC框架更多的是服務(wù)治理。

   3、性能消耗：

   RPC：可以基于thrift實(shí)現(xiàn)高效的二進(jìn)制傳輸

   HTTP：大部分是基于JSON實(shí)現(xiàn)的，字節(jié)大小和序列化耗時(shí)都比thrift要更消耗性能

   4、負(fù)載均衡：

   RPC：基本自帶了負(fù)載均衡策略

   HTTP：需要配置Nginx、HAProxy配置

   5、服務(wù)治理：（下游服務(wù)新增，重啟，下線(xiàn)時(shí)如何不影響上游調(diào)用者）

   RPC：能做到自動(dòng)通知，不影響上游

   HTTP：需要事先通知，如修改NGINX配置。

3. RPC 傳輸速度比 HTTP 更快嗎？

   不一定，但一般會(huì)快。取決于序列化協(xié)議和傳輸協(xié)議，

   比如二進(jìn)制編碼肯定比 JSON 節(jié)省體積，自定義 tcp 協(xié)議/HTTP2.0 比 tcp/HTTP1.1 要快

4. 用的TCP還是HTTP2傳輸?shù)模?/p>

   自己項(xiàng)目、DUBBO：TCP

   grpc：http2.0

5. HTTP 和 RPC 的關(guān)系? RPC 和 HTTP 的區(qū)別?

6. 為什么spring cloud用的是http

   HTTP Restful本身輕量，易用，適用性強(qiáng)，可以很容易的跨語(yǔ)言，跨平臺(tái)，或者與已有系統(tǒng)交互，

   目前很多大型項(xiàng)目多語(yǔ)言共存，http是最通用的協(xié)議，可以很好地解決跨語(yǔ)言跨平臺(tái)兼容性

7. 為什么我們要使用RPC而不是使用HTTP？

8. 你這個(gè)RPC框架是基于HTTP請(qǐng)求的嗎？

   不是，基于TCP

9. RPC 是用的時(shí)候連一次，還是連一次后就長(zhǎng)連接？

   自己的RPC是長(zhǎng)連接（Netty 中提供了 IdleStateHandler 類(lèi)專(zhuān)門(mén)用于處理心跳，所以是長(zhǎng)連接

   沒(méi)有這個(gè)，默認(rèn)一般是短連接）

   （這個(gè)被問(wèn)過(guò)好幾次，我猜是長(zhǎng)連接，有大佬知道嗎）文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-772006.html

到了這里，關(guān)于分布式【RPC 常見(jiàn)面試題】的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！