共计 1311 个字符，预计需要花费 4 分钟才能阅读完成。
原创：猿天地（微信公众号 ID：cxytiandi），欢送分享，转载请保留出处。
在多个团队之间的一些业务关联上，外部能够 Rpc 的形式进行交互。某些业务其实不须要强关联，这个时候就会用音讯队列进行解耦操作。比方下单后加积分，发短信告诉的这类操作。
在用音讯队列的时候，咱们最须要关注的一个问题就是 音讯会不会失落？
这里的失落指的就是要么你程序有问题，没有发送进来。要么发送进来了，然而在某个节点上音讯丢掉了，导致生产方没有收到你发送的音讯，从而引发业务问题。
对于音讯失落，有很多的解决方案。本文不聊怎么在技术层面去避免音讯失落，聊另一个话题：音讯到底发没发送？
在多团队之间用音讯解耦的场景下更容易呈现这类问题，另一个团队的同学找你，说你们的音讯是不是没发送啊，我这边这条数据的状态没流转，必定没收到音讯。
而后你屁颠屁颠的去音讯队列的控制台进行音讯的查问，发现的确查不到。次要问题在于这条数据是几个月之前的了，发送记录没有保留这么久，所以当初是有口难辩的这么一个状态。
他人说你没发，但你本人又拿不进去证据来证实本人发送过了音讯。所以这个锅你只能本人背了。这就是明天要聊的话题，凡事要留个凭证，不便日后好追溯，特地是要害的业务场景。
存储发送记录到数据库
既然要留凭证，那么就须要将凭证存储起来。音讯队列的音讯量大，必定不会全副永恒存储，个别都是存储最近几天的量，所以间接利用音讯队列去查有没有发送只适宜最近的音讯，工夫比拟久的就无从追溯了。
在音讯发送后，能够间接存储到数据库中，不便前面查问发送记录。其实就跟短信记录一样的，短信也常常会遇到说这个短信我没收到，是不是没发送啊之类的问题。
存储须要思考的就是量的问题，如果你们每天的音讯量很大，还须要存储永恒的数据，那么就得拆分了，或者采纳外置其余数据库进行独自存储，比方 MongoDB 之类的 NoSql。
存储发送记录到日志
另一种计划就是发送后间接输入一条日志即可，因为大部分公司都有对立的日志平台，去收集日志进行存储。这个计划就不必占用 DB 的存储或者说独自弄一套 Nosql 存储，比拟省事。
然而须要留神的是日志的存储工夫，像一些云厂商的日志服务是能够设置存储工夫的，因为日志的量越大，老本越高。
在很久之前就遇到过发消息其实是打印了日志的，然而存储工夫只有最近一个月。当他人来问你音讯有没有发送的时候，你会发现过后的日志曾经没有了，所以咱们还是须要进行永恒存储。
永恒存储也就意味着老本的进步，其实咱们能够将日志分类，一般的日志能够存储工夫短一点，一些有用的日志能够 独自进行输入收集和永恒存储。这类日志的量绝对少一点，老本可控。
间接用本地音讯表发送
除了用开源的音讯队列，很多公司也都会用本地音讯表，独自的音讯服务，基于数据库设计的音讯队列这些模式来发送音讯。这些模式的特点就是自身就基于 DB 做的长久化，所以对于查找有没有发送过音讯是人造反对的。当然也有可能量大后即便分库分表了，前期还是要扩容或者定期归档，只有数据还在这个锅就背不了。
对于作者 ：尹吉欢，简略的技术爱好者，《Spring Cloud 微服务 - 全栈技术与案例解析》,《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号 猿天地 发起人。
