互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（1）【石杉的架构笔记】

时间 2019-11-06

标签互联网面试必杀如何保证消息中间件链路数据 100% 丢失石杉的架构笔记栏目快乐工作繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）面试

周一至周五早8点半！精品技术文章准时送上！算法

一、背景引入

这篇文章，咱们来聊聊在线上生产环境使用消息中间件技术的时候，从前到后的全链路到底如何保证数据不能丢失。缓存

这个问题，在互联网公司面试的时候高频出现，并且也是很是现实的生产环境问题。性能优化

若是你的简历中写了本身熟悉MQ技术（RabbitMQ、RocketMQ、Kafka），并且在项目里有使用的经验，那么很是实际的一个生产环境问题就是：投递消息到MQ，而后从MQ消费消息来处理的这个过程，数据到底会不会丢失。网络

面试官此时会问：若是数据会丢失的话，大家项目生产部署的时候，是经过什么手段保证基于MQ传输的数据100%不会丢失的？麻烦结合大家线上使用的消息中间件来具体说说大家的技术方案。架构

这个其实就是很是区分面试候选人技术水平的一个问题。并发

实际上至关大比例的普通工程师，哪怕是在一些中小型互联网公司里工做过的，也就是基于公司部署的MQ集群简单的使用一下罢了，可能代码层面就是基本的发送消息和消费消息，基本没考虑太多的技术方案。分布式

可是实际上，对于MQ、缓存、分库分表、NoSQL等各式各种的技术以及中间件在使用的时候，都会有对应技术相关的一堆生产环境问题。微服务

那么针对这些问题，就必需要有相对应的一整套技术方案来保证系统的健壮性、稳定性以及高可用性。高并发

因此其实中大型互联网公司的面试官在面试候选人的时候，若是考察对MQ相关技术的经验和掌握程度，十有八九都会抛出这个使用MQ时必定会涉及的数据丢失问题。由于这个问题，可以很是好的区分候选人的技术水平。

因此这篇文章，咱们就来具体聊聊基于RabbitMQ这种消息中间件的背景下，从投递消息到MQ，到从MQ消费消息出来，这个过程当中有哪些数据丢失的风险和可能。

而后咱们再一块儿来看看，应该如何结合MQ自身提供的一些技术特性来保证数据不丢失？

二、前情回顾

首先给大伙一点提醒，有些新同窗可能还对MQ相关技术不太了解，建议看一下以前的MQ系列文章，看看MQ的基本使用和原理：

「Java进阶面试系列之一」大家系统架构中为什么要引入消息中间件？

「Java进阶面试系列之二」系统架构引入消息中间件有什么缺点

「Java进阶面试系列之三」消息中间件在大家项目里是如何落地的？

另外，其实以前咱们有过2篇文章是讨论消息中间件的数据不丢失问题的。

咱们分别从消费者忽然宕机可能致使数据丢失，以及集群忽然崩溃可能致使的数据丢失两个角度讨论了一下数据如何不丢失。

只不过仅仅那两个方案还没法保证全链路数据不丢失，可是你们若是没看过的建议也先回过头看看：

扎心！线上服务宕机时，如何保证数据100%不丢失？

消息中间件集群崩溃，如何保证百万生产数据不丢失？

总之，但愿对MQ不太熟悉的同窗，先把前面那些系列文章熟悉一下，而后再来一块儿系统性的研究一下MQ数据如何作到100%不丢失。

三、目前已有的技术方案

通过以前几篇文章的讨论，目前咱们已经初步知道，第一个会致使数据丢失的地方，就是消费者获取到消息以后，没有来得及处理完毕，本身直接宕机了。

此时RabbitMQ的自动ack机制会通知MQ集群这条消息已经处理好了，MQ集群就会删除这条消息。

那么这条消息不就丢失了么？不会有任何一个消费者处理到这条消息了。

因此以前咱们详细讨论过，经过在消费者服务中调整为手动ack机制，来确保消息必定是已经成功处理完了，才会发送ack通知给MQ集群。

不然没发送ack以前消费者服务宕机，此时MQ集群会自动感知到，而后重发消息给其余的消费者服务实例。

扎心！线上服务宕机时，如何保证数据100%不丢失？

这篇文章，详细讨论了这个问题，手动ack机制之下的架构图以下所示：

当时除了这个数据丢失问题以外，还有另一个问题，就是MQ集群自身若是忽然宕机，是否是会致使数据丢失？

默认状况下是确定会的，由于queue和message都没采用持久化的方式来投递，因此MQ集群重启会致使部分数据丢失。

消息中间件集群崩溃，如何保证百万生产数据不丢失？

这篇文章，咱们分析了如何采用持久化的方式来建立queue，同时采用持久化的方式来投递消息到MQ集群，这样MQ集群会将消息持久化到磁盘上去。

此时若是消息还没来得及投递给消费者服务，而后MQ集群忽然宕机了，数据是不会丢失的，由于MQ集群重启以后会自动从磁盘文件里加载出来没投递出去的消息，而后继续投递给消费者服务。

一样，该方案沉淀下来的系统架构图，以下所示：

四、数据100%不丢失了吗？

你们想想，到目前为止，我们的架构必定能够保证数据不丢失了吗？

其实，如今的架构，仍是有一个数据可能会丢失的问题。

那就是上面做为生产者的订单服务把消息投递到MQ集群以后，暂时还驻留在MQ的内存里，还没来得及持久化到磁盘上，同时也还没来得及投递到做为消费者的仓储服务。

此时要是MQ集群自身忽然宕机，咋办呢？

尴尬了吧，驻留在内存里的数据是必定会丢失的，咱们来看看下面的图示。

五、按需制定技术方案

如今，咱们须要考虑的技术方案是：订单服务如何保证消息必定已经持久化到磁盘？

实际上，做为生产者的订单服务把消息投递到MQ集群的过程是很容易丢数据的。

好比说网络出了点什么故障，数据压根儿没传输过去，或者就是上面说的消息刚刚被MQ接收可是还驻留在内存里，没落地到磁盘上，此时MQ集群宕机就会丢数据。

因此首先，咱们得考虑一下做为生产者的订单服务要如何利用RabbitMQ提供的相关功能来实现一个技术方案。

这个技术方案须要保证：只要订单服务发送出去的消息确认成功了，此时MQ集群就必定已经将消息持久化到磁盘了。

咱们必须实现这样的一个效果，才能保证投递到MQ集群的数据是不会丢失的。

六、须要研究的技术细节

这里咱们须要研究的技术细节是：仓储服务手动ack保证数据不丢失的实现原理。

以前，笔者就收到不少同窗提问：

仓储服务那块究竟是如何基于手动ack就能够实现数据不丢失的？ RabbitMQ底层实现的细节和原理究竟是什么？为何仓储服务没发送ack就宕机了，RabbitMQ能够自动感知到他宕机了，而后自动重发消息给其余的仓储服务实例呢？

这些东西背后的实现原理和底层细节，究竟是什么？

大伙儿稍安勿躁，接下来，我们会经过一系列文章，仔细探究一下这背后的原理。

End

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授