超時處理模式

       在服務化或者微服務架構裏，應用拆分紅爲多個職責單一的微服務，服務之間經過某種網絡通訊協議互相通訊和交互。然而，因爲網絡通訊不穩定，咱們在設計系統時必須考慮對網絡通訊的容錯，特被是調用超時的處理。

      微服務的交互模式

服務與服務之間的交互模式可分爲3類：

1.同步調用模式

2.接口異步調用模式

3.消息隊列異步處理模式。

交互模式下超時問題的解決方案

1.同步調用模式下，對外的接口會提供服務契約。契約定義了服務的處理結果會經過返回值返回給使用方，對返回的狀態定義爲如下兩種。

  兩種狀態的接口：成功和失敗

  三種狀態的接口：成功，失敗，處理中

2.異步調用模式下的解決方案

       在異步調用的模式下，對外的接口也會提供服務契約，契約定義了服務的受理結果會經過返回值返回給使用方，返回的狀態一般爲兩個：受理和未受理。在三狀態同步調用接口不一樣的是，異步調用模式還有異步處理返回結果的通知，狀態包括處理成功和處理模式。

3.消息隊列異步處理模式的解決方案

       消息隊列異步處理模式用於鬆耦合的項目，這些項目一般是在主流程中沒法處理耗時的任務。剛好耗時的任務又不是核心流程的一部分。如電商的物流，配送。

       消息隊列的生產者超時

       消息到可靠發送：可認爲是盡最大努力發送消息通知，有如下方式：

      1.在發送消息以前就將消息持久化到數據庫，狀態標記未待發送。而後發送消息，若是成功，則改成發送成功。定時任務定時從數據庫撈取在必定時間內未發送到消息進行發送。

     2.與1相似，不一樣到是持久消息到數據是獨立到，並不耦合在業務系統中。發送消息前，發送一個預消息給第三方到消息管理器，消息管理器將其持久化到數據庫，並標記爲待發送，在發送成功後，標記消息爲發送成功。定時任務處理未發送的消息。能夠把消息帶可靠發送實如今中間件裏，經過spring帶注入，子啊消息發送時自動持久消息記錄，若是消息發送失敗，則定時補償。

       消息隊列的消費者超時

        般消息隊列會提供以下兩種方式來消費消息。

      1.自動增加消費的偏移量：在一個消費者從消息服務隊列中取走消息，消息隊列的消息便宜量自動增長。即消息一旦被消息隊列中取走。則再也不存在於服務器中，假如消息處理失敗，則消息丟失。

      2.手工提交消費的偏移量（ack）：在一個消費者從消息服務器中取走消息後，處理機先把消息持久到本地數據庫中，而後告訴消息服務器已經消費消息，消息服務器纔會移除消息。

      超時補償原則

      服務1調用服務2，若是服務2響應服務1而且告訴服務服務1消息已經接受，那麼服務1帶任務就結束了。若是服務2處理失敗，服務2處理重試或者補償。這種狀況下，服務2接收消息後先持久化在告訴服務1接受成功。

       服務1調用服務2，若是服務2沒有給出明確的接收響應，例如網絡超時，那麼服務1應該持續進行重試。直到服務2明確表示接受到消息。這種狀況下容易出現重複帶消息，所以服務2一般保持過濾重或者冥等性。