小王和小明分別維護分布式系統中a、b兩個服務，有乙個場景是 a服務會向b服務通過mq傳送事件並且推送使用者資訊，然後b服務儲存使用者資訊。
有一天，小王和小明因為一件事討論得熱火朝天、互不相讓，事情由來如下：
這時候，在一旁掃地的清潔工老梁過來調解，並幫忙排查分析，導致這個問題的主要原因如下：
偽**如下：
清潔工老梁跟小王和小明進行一番詳談後，了解到他們主要需求有兩個：
經過上面的分析，老梁的解題思路主要分為兩個方向：
一般來說，常見的微服務架構實現最終一致性有三種模式：可靠事件模式、業務補償模式、tcc模式。這裡ab服務是通過業務補償模式實現最終一致性，但這裡又跟我們一般的分布式架構的事務問題不同，這裡我們只需要保證b服務能最終把正常訊息事件消費成功即可。
實現思路：
針對於b服務，對於收到的mq資訊沒有進行有效的記錄，而且mq資訊處理之後，存在修改錯誤，沒法進行對應資訊補充修復的功能，增加通用訊息處理層，進行訊息體的記錄和回溯。 在獲取訊息之後進行一次記錄，進行冪等操作和對應的狀態更新， 訊息狀態在業務相關操作完成後，標記為處理完成，認為對應訊息狀態結束。
這裡hash_value是對請求體進行hash計算得出來的乙個值，例如：md5、sha-2，保證每個不同請求的hash碼不一樣，相同的請求hash碼相同，可以用於冪等控制。表大致操作流程:
異常訊息有4個狀態
失敗事件佇列在這裡是採用資料庫表代替
因為並非所有的異常都能重跑就能解決問題，我們只能針對可以修復的異常進行重試，這裡把異常分為兩大類：
不可修復異常：不可修復異常指不能通過重跑就能解決的異常。如：上游系統傳輸格式有問題、訊息事件內容本身有誤等引起的異常，這些即使重跑也解決不了問題，應該要從上游系統或者根源去解決。
最後小明負責的b服務按照老梁的思路，重新調整了**，異常處理流程如下：
網際網路 手機圈那些事
記得自己的第一部智慧型手機是小公尺1s,2012年的時候，國內做手機當時最出色和價效比最高的應該算是小公尺了。當然當時和它相提並論的還有魅族。當時的魅族可以說也是 做精品手機最好的了。後來其他的手機廠商開始模仿小公尺的網際網路思維和網際網路營銷模式，包括華為，酷派，一加，聯想，後來者的樂視，360，...
網際網路DBA需要做那些事
很早前就想寫篇文章介紹一下網際網路dba需要幹的一些事情，但苦於沒有時間，忙於平台建設，最近，各個模組都初具規模，故有時間靜下心來，介紹一下。眾所周知，網際網路dba與傳統行業dba有很大的不同，那就是管理的機器多，新技術更新快，面對的開發多 網路環境複雜 要求7 24待機 這樣就 導致網際網路db...
網際網路二三事
前幾天閒聊起我們的產品，有一句話突然觸痛了我，我們做這一切究竟是為了什麼？然後腦子中又浮現出既定的戰略路線 先聚人氣，然後在怎樣，最後在如何，最終在露出我們的獠牙，在此之前不可讓使用者知道我們是做 dian 啥 shang 的.然然。似乎也對，似乎也不對。又一日，我們又提到乙個粗暴的 同行 交易量也...