据不完全统计，几乎三分之二的工业级代码都在处理异常情况。我和很多面试官谈过，面试中如何考察一个应聘者的思维是否全面，比较好的方法是看他是否能很好地思考，是否能想到所有异常情况的解决方案。相信大家都用过消息MQ。可以很好的解耦系统，降低成为的复杂度，还可以进行削峰，增加系统在高并发时的稳定性。那么使用MQ有哪些注意事项呢？是的如果不是MQ就万无一失了吗？MQ消息从生成到消费有没有可能失败？它可能在哪些环节失败？调用可能会失败。以下原因可能会导致MQ生产失败，比如网络波动。虽然生产者和MQ服务器是内网调用，但不代表网络调用的成功率是100%，内网调用也会遇到网络波动，导致调用超时或失败。再比如被调用的MQ机器瞬间崩溃，可能会导致调用失败。面对生产者调用MQ失败的情况，我们很容易，也比较容易处理。我们只需要简单地重试。如果重试2-3次都失败，很有可能是出了大问题。此时再试意义不大，需要发出告警，让开发运维介入处理。MQ处理和存储失败消息到达消息中间件后，通常会进行存储。只有写入磁盘时，消息才真正存储起来，不会丢失。但是大部分MQ中间件并不会立即将消息写入磁盘，而是因为磁盘的写入速度比内存慢很多，所以像Kafka这样的消息系统会将消息写入磁盘。消息写入缓冲区并异步写入磁盘。如果机器在中途突然断电，就有可能丢失消息。为了解决这个问题，大部分MQ都是分布式部署的。消息会被成功写入多台机器上的缓存，然后返回给业务方。由于多台机器同时断电的可能性很小，我们可以认为这是一种成本相对较低且可靠的方案。如果消费者处理失败，一般MQ都有MQ重试机制。如果进程失败，它会反复尝试消费MQ。这样带来的问题是MQ可能消费成功了，但是通知MQ中间件的时候失败了。这时候的结果就是重复消费消息。同样，生产者重试时，也会遇到消息重复消费的问题。这时候就要求我们把接口设计的尽量幂等。这时候，即使是重复消费，也不用担心出现什么问题。基本上这三点做好了，就可以大大提高我们系统的易用性！如果有兴趣，欢迎大家关注我，一起学习，一起进步。您的支持是我继续聊天的动力。
