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

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

消息生产失败

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

MQ处理存储失败

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

消费者处理失败

一般的MQ都有MQ重试机制，b2b信息网如果处理失败，就会尝试重复消费这个MQ。这个带来的问题就是，MQ可能已经成功消费了，但是在通知MQ中间件的时候失败了，这个时候带来的结果就是消息重复消费。同理，在生产者重试的时候，也会遇到消息重复消费的问题。这个时候，就要求我们尽量把接口设计得有幂等性，这个时候即便是重复消费，也不用担心什么问题了。基本上做好这三点，我们就能够大大地提高我们地系统地可用性了!如果你有兴趣，欢迎大家关注我，共同学习，共同进步。大家的支持是我继续唠嗑的动力。

最新评论