解决甩锅的一大难题，就是留个凭证

原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

在多个团队之间的一些业务关联上，内部能够Rpc的方式进行交互。某些业务其实不须要强关联，这个时候就会用消息队列进行解耦操做。好比下单后加积分，发短信通知的这类操做。

在用消息队列的时候，咱们最须要关注的一个问题就是消息会不会丢失？

这里的丢失指的就是要么你程序有问题，没有发送出去。要么发送出去了，可是在某个节点上消息丢掉了，致使消费方没有收到你发送的消息，从而引起业务问题。

对于消息丢失，有不少的解决方案。本文不聊怎么在技术层面去防止消息丢失，聊另外一个话题：消息到底发没发送？

在多团队之间用消息解耦的场景下更容易出现这类问题，另外一个团队的同窗找你，说大家的消息是否是没发送啊，我这边这条数据的状态没流转，确定没收到消息。

而后你屁颠屁颠的去消息队列的控制台进行消息的查询，发现确实查不到。主要问题在于这条数据是几个月以前的了，发送记录没有保存这么久，因此如今是有口难辩的这么一个状态。

别人说你没发，但你本身又拿不出来证据来证实本身发送过了消息。因此这个锅你只能本身背了。这就是今天要聊的话题，凡事要留个凭证，方便往后好追溯，特别是关键的业务场景。

存储发送记录到数据库

既然要留凭证，那么就须要将凭证存储起来。消息队列的消息量大，确定不会所有永久存储，通常都是存储最近几天的量，因此直接利用消息队列去查有没有发送只适合最近的消息，时间比较久的就无从追溯了。

在消息发送后，能够直接存储到数据库中，方便后面查询发送记录。其实就跟短信记录同样的，短信也常常会遇到说这个短信我没收到，是否是没发送啊之类的问题。

存储须要考虑的就是量的问题，若是大家天天的消息量很大，还须要存储永久的数据，那么就得拆分了，或者采用外置其余数据库进行单独存储，好比MongoDB之类的NoSql。

存储发送记录到日志

另外一种方案就是发送后直接输出一条日志便可，由于大部分公司都有统一的日志平台，去收集日志进行存储。这个方案就不用占用DB的存储或者说单独弄一套Nosql存储，比较省事。

可是须要注意的是日志的存储时间，像一些云厂商的日志服务是能够设置存储时间的，由于日志的量越大，成本越高。

在好久以前就遇到过发消息实际上是打印了日志的，可是存储时间只有最近一个月。当别人来问你消息有没有发送的时候，你会发现当时的日志已经没有了，因此咱们仍是须要进行永久存储。

永久存储也就意味着成本的提升，其实咱们能够将日志分类，普通的日志能够存储时间短一点，一些有用的日志能够单独进行输出收集和永久存储。这类日志的量相对少一点，成本可控。

直接用本地消息表发送

除了用开源的消息队列，不少公司也都会用本地消息表，单独的消息服务，基于数据库设计的消息队列这些形式来发送消息。这些形式的特色就是自己就基于DB作的持久化，因此对于查找有没有发送过消息是自然支持的。固然也有可能量大后即便分库分表了，后期仍是要扩容或者按期归档，只要数据还在这个锅就背不了。

关于做者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》做者, 公众号猿天地发起人。