程序员经典面试题，消息队列怎么用，才能保证万无一失

据不完全统计，工业级别的代码，几乎有三分之二都是在处理异常情况。跟很多面试官聊过，在面试中如何考察一个应试者的思维是否周全，比较好的方法就是考察他是否能够思考周全，想到所有异常情况的处理方案。相信大家都使用过消息MQ，他可以很好地进行系统解耦，减低变成的复杂度，又可以进行削峰，增加系统在高并发的稳定性，那么使用MQ有哪些注意事项呢?是不是MQ就是万无一失呢?一条MQ消息从产生到消费，有没有可能失败?在哪些环节可能失败，如何处理?

消息生产失败

一般来说，从生产者到MQ中间件是通过网络调用的，是网络调用就有可能存在失败。下面这些原因，都有可能造成MQ生产失败，例如网络波动，尽管生产者到MQ服务器之间是内网调用，并不意味着网络调用的成功率就是百分之百，内网调用也会遇到网络波动，造成调用超时或者失败。又如调用的MQ机器瞬间Crash掉，这也是有可能造成调用失败的。面对生产者调用MQ的失败，我们是容易比较容易处理的，我们只要简单地进行重试即可，如果重试2-3次失败，那么非常有可能是出现大问题，这个时候再重试意义不大，需要进行告警，让开发运维介入，进行处理。

MQ处理存储失败

消息到达消息中间件之后，通常是会被存储起来的，只有被写入到磁盘中，消息才是真正地被存储，不会丢失。但是，大部分MQ中间件并不是收到消息就立马写入磁盘的，只是由于磁盘的写入速度相对于内存，现得慢得多得多，所以，像Kafka这样的消息系统，是会把消息写到缓冲区中，异步写入磁盘，如果机器在中途突然断电，是有可能会丢失消息的。为了解决这个问题，大部分的MQ都是采用分布式部署，消息会在多台机器上写入缓存中成功才会返回给业务方成功，由于多台机器同时断电的可能性较低，我们可以认为这是比较低成本又可靠的方案。