解決甩鍋的一大難題，就是留個憑證
本文轉載自微信公眾號「猿天地」，作者尹吉歡。轉載本文請聯系猿天地公眾號。
在多個團隊之間的一些業務關聯上，內部可以 Rpc 的方式進行交互。某些業務其實不需要強關聯，這個時候就會用消息隊列進行解耦操作。比如下單后加積分，發短信通知的這類操作。
在用消息隊列的時候，我們最需要關注的一個問題就是消息會不會丟失?
這里的丟失指的就是要么你程序有問題，沒有發送出去。要么發送出去了，但是在某個節點上消息丟掉了，導致消費方沒有收到你發送的消息，從而引發業務問題。
對于消息丟失，有很多的解決方案。本文不聊怎么在技術層面去防止消息丟失，聊另一個話題：消息到底發沒發送?
在多團隊之間用消息解耦的場景下更容易出現這類問題，另一個團隊的同學找你，說你們的消息是不是沒發送啊，我這邊這條數據的狀態沒流轉，肯定沒收到消息。
然后你屁顛屁顛的去消息隊列的控制臺進行消息的查詢，發現確實查不到。主要問題在于這條數據是幾個月之前的了，發送記錄沒有保存這么久，所以現在是有口難辯的這么一個狀態。
別人說你沒發，但你自己又拿不出來證據來證明自己發送過了消息。所以這個鍋你只能自己背了。這就是今天要聊的話題，凡事要留個憑證，方便日后好追溯，特別是關鍵的業務場景。
存儲發送記錄到數據庫
既然要留憑證，那么就需要將憑證存儲起來。消息隊列的消息量大，肯定不會全部永久存儲，一般都是存儲最近幾天的量，所以直接利用消息隊列去查有沒有發送只適合最近的消息，時間比較久的就無從追溯了。
在消息發送后，可以直接存儲到數據庫中，方便后面查詢發送記錄。其實就跟短信記錄一樣的，短信也經常會遇到說這個短信我沒收到，是不是沒發送啊之類的問題。
存儲需要考慮的就是量的問題，如果你們每天的消息量很大，還需要存儲永久的數據，那么就得拆分了，或者采用外置其他數據庫進行單獨存儲，比如 MongoDB 之類的 NoSql。
存儲發送記錄到日志
另一種方案就是發送后直接輸出一條日志即可，因為大部分公司都有統一的日志平臺，去收集日志進行存儲。這個方案就不用占用 DB 的存儲或者說單獨弄一套 Nosql 存儲，比較省事。
但是需要注意的是日志的存儲時間，像一些云廠商的日志服務是可以設置存儲時間的，因為日志的量越大，成本越高。
在很久之前就遇到過發消息其實是打印了日志的，但是存儲時間只有最近一個月。當別人來問你消息有沒有發送的時候，你會發現當時的日志已經沒有了，所以我們還是需要進行永久存儲。
永久存儲也就意味著成本的提高，其實我們可以將日志分類，普通的日志可以存儲時間短一點，一些有用的日志可以單獨進行輸出收集和永久存儲。這類日志的量相對少一點，成本可控。
直接用本地消息表發送
除了用開源的消息隊列，很多公司也都會用本地消息表，單獨的消息服務，基于數據庫設計的消息隊列這些形式來發送消息。這些形式的特點就是本身就基于 DB 做的持久化，所以對于查找有沒有發送過消息是天然支持的。當然也有可能量大后即使分庫分表了，后期還是要擴容或者定期歸檔，只要數據還在這個鍋就背不了。
關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。
