1、Dubbo的容錯機制有哪些?
Dubbo官網(wǎng)提出總共有六種容錯策略
● Failover Cluster模式
失敗自動切換,當出現(xiàn)失敗,重試其它服務(wù)器。(默認)
● Failfast Cluster
快速失敗,只發(fā)起一次調(diào)用,失敗立即報錯。通常用于非冪等性的寫操作,比如新增記錄。
● Failsafe Cluster
失敗安全,出現(xiàn)異常時,直接忽略。通常用于寫入審計日志等操作。
● Failback Cluster
失敗自動恢復,后臺記錄失敗請求,定時重發(fā)。通常用于消息通知操作。
● Forking Cluster
并行調(diào)用多個服務(wù)器,只要一個成功即返回。通常用于實時性要求較高的讀操作,但需要浪費更多服務(wù)資源。可通過forks=”2”來設(shè)置最大并行數(shù)。
● Broadcast Cluster
廣播調(diào)用所有提供者,逐個調(diào)用,任意一臺報錯則報錯。(2.1.0開始支持)通常用于通知所有提供者更新緩存或日志等本地資源信息。
總結(jié):在實際應(yīng)用中查詢語句容錯策略建議使用默認Failover Cluster,而增刪改建議使用Failfast Cluster或者使用Failover Cluster(retries=”0”)策略防止出現(xiàn)數(shù)據(jù)重復添加等等其它問題。建議在設(shè)計接口時候把查詢接口方法單獨做一個接口提供查詢。
增加提供服務(wù)版本號和消費服務(wù)版本號
這個具體來說不算是一個問題,而是一種問題的解決方案,在我們的實際工作中會面臨各種環(huán)境資源短缺的問題,也是很實際的問題,剛開始我們還可以提供一個服務(wù)進行相關(guān)的開發(fā)和測試,但是當有多個環(huán)境多個版本,多個任務(wù)的時候就不滿足我們的需求,這時候我們可以通過給提供方增加版本的方式來區(qū)分.這樣能夠剩下很多的物理資源,同時為今后更換接口定義發(fā)布在線時,可不停機發(fā)布,使用版本號.引用只會找相應(yīng)版本的服務(wù),例如:
<dubbo:serviceinterface="com.xxx.XxxService" ref="xxxService" version="1.0"/>
<dubbo:referenceid="xxxService" interface="com.xxx.XxxService" version="1.0"/>
3、dubbo reference注解問題?
@Reference只能在SpringBean實例對應(yīng)的當前類中使用,暫時無法在父類使用;如果確實要在父類聲明一個引用,可通過配置文件配置dubbo:reference,然后在需要引用的地方跟引用SpringBean一樣就可以了.
● 檢查連接的注冊中心是否正確
● 到注冊中心查看相應(yīng)的服務(wù)提供者是否存在
● 檢查服務(wù)提供者是否正常運行
首先,確認服務(wù)提供者是否連接了正確的注冊中心,不只是檢查配置中的注冊中心地址,而且要檢查實際的網(wǎng)絡(luò)連接。
其次,看服務(wù)提供者是否非常繁忙,比如壓力測試,以至于沒有CPU片段向注冊中心發(fā)送心跳,這種情況減小壓力將自動恢復。
Dubbo的客戶端和服務(wù)端有三種連接方式,分別是:廣播,直連和使用zookeeper注冊中心。
這種方式是dubbo官方入門程序所使用的連接方式,但是這種方式有很多問題。在企業(yè)開發(fā)中,不使用廣播的方式。taotao-manager服務(wù)端配置:
!-- applicationContext-service.xml 文件中 -->
<!-- 提供方應(yīng)用信息,用于計算機依賴關(guān)系 -->
<dubbo:application name="taotao-manager-service” />
<!-- 使用 multicast 廣播暴露服務(wù)地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />
<!-- 使用 dubbo 協(xié)議在 20880 協(xié)議暴露服務(wù) -->
<dubboprotocol name="dubbo" port="20880" />
<!-- 聲明需要暴露的服務(wù)接口 -->
<dubbo:service interface="com.taotao.manager.service.TestService" ref="testServiceImpl" />