最近的工作我在做一個有關(guān)于消息發(fā)送和接受封裝工作。大概流程是這樣的，消息中間件是采用rabbitmq，為了保證消息的絕對無丟失，我們需要在發(fā)送和接受前對消息進(jìn)行DB落地。在發(fā)送前我會先進(jìn)行DB的插入，單表插入，所以在性能上也是能接受的，單表插入做了壓測基本上是一到兩毫秒的時間，加上消息的發(fā)送（有ACK）再加上集群是兩個節(jié)點的高可用（一個磁盤持久化節(jié)點），單臺TPS基本上是在2000-3000左右。這對于我們的業(yè)務(wù)場景來說是夠用了。一旦當(dāng)消息丟失或者由于網(wǎng)絡(luò)問題、集群問題業(yè)務(wù)不會中斷，消息就算發(fā)不出去也沒關(guān)系，我們會進(jìn)行消息的補(bǔ)償或者同步api調(diào)用補(bǔ)償。這是架構(gòu)設(shè)計的必須要考慮的A計劃、B計劃、C計劃，這是敬畏或者危機(jī)意識。

你可能又要說兩個節(jié)點或者三個節(jié)點的集群怎么會有問題，那你就錯了，大錯特錯。只能說明你并不了解什么叫分布式系統(tǒng)及分布式系統(tǒng)的特性。你也許不會知道網(wǎng)絡(luò)抖動、網(wǎng)絡(luò)閃斷導(dǎo)致socket斷開如何進(jìn)行心跳重試已保持有效的Rabbitmq Connection。當(dāng)你的網(wǎng)絡(luò)極不穩(wěn)定，你的linux keepalived VIP 來回漂移，導(dǎo)致你的ARP根本無法成效，可能就連廣播都傳不出去，而客戶端則在一直使用一個無用的IP地址。當(dāng)你的集群節(jié)點之間無法連接成一個整體的時候各種奇葩的問題又來了。這些都是可能導(dǎo)致你的集群出問題的原因，所以不要大意。

（后面我會整理一篇專門講解“rabbitmq高可用、故障轉(zhuǎn)移集群架構(gòu)“文章，所以這里我們就不繼續(xù)介紹了）

這是一個鋪墊，本文的重點是介紹下我在嘗試使用可視化webapi的輸出模式，這比原本json的輸出模式看起來會方便許多。如果你的api提供兩種輸出模式，人性化絕對很好?，F(xiàn)在很多后端api都是沒有界面的都是只提供了一個json輸出。然而，我們其實很需要一個可讀性很強(qiáng)的輸出模式。

我在開發(fā)消息補(bǔ)償程序的時候，我借鑒了這一思想進(jìn)行了嘗試。先來看下整體架構(gòu)藍(lán)圖：

1

本篇文章要介紹的是有關(guān)于這個補(bǔ)償程序的api的可視化輸出內(nèi)容。不涉及到消息相關(guān)太多的東西，只是為了讓這個可視化輸出看起來容易理解點。這個補(bǔ)償程序需要對發(fā)送的消息和接受的消息進(jìn)行查詢和比較然后輸出，用來確定消息的發(fā)送是失敗了還是成功的。簡單邏輯就是比較某個時間段內(nèi)的消息發(fā)送表和接受表，然后進(jìn)行消息id的匹配。

我在想這個數(shù)據(jù)反饋到api上是個什么樣子的，按照常規(guī)設(shè)計就是兩個字段：