关于消息队列的几点思考（2）

在系统中引入消息队列可能会出现的问题

系统的可用性降低：系统引入的外部依赖越多，越容易挂掉，最初是A系统同步调用BCD三个系统的接口，ABCD都没问题。如果加入MQ等更多的依赖，如果说MQ出现故障，整个系统都会崩溃。引入的组件越多，故障的可能性就越大。

系统的复杂性提高：加入MQ，如何保证消息没有被重复消费？如何处理消息丢失的问题？如何保证消息传递的顺序性问题？这些都是在生产环境中会遇到的问题。

一致性问题：A系统处理完成直接返回成功，客户认为你这个请求就是成功了。但是BCD三个系统中，BD两个系统写库成功，但是C系统写库失败，就会造成数据不一致的情况出现。

所以说消息队列实际上是一种非常复杂的结构，引入消息队列会有很多好处，但是也要针对他所带来的问题，做各种额外的技术方案和架构来进行规避。

如何保证消息队列的高可用性？

RabbitMQ的镜像集群模式：

看完这个模式之后感觉问题很大，和最初解决集群环境下tomcat session共享问题的session复制的无脑解决方法一样，无法实现真正的分布式，集群最大容量就是集群中单机的最小容量。虽然说实现了高可用，但是造成了较大的存储资源的浪费，不推荐！

kafka高可用架构：

kafka高可用架构的选举和Zookeepr的选举方式仿佛有相似之处，似曾相识的感觉。

如何保证消息队列的幂等性（同一条消息不被重复消费）？

保证幂等性是要根据不同的业务需求来进行处理，具体问题具体分析。

在消费者在对数据进行插入操作之前，首先判断id=1的数据是否在set集合中存在，如果存在则说明已经被消费过了。

提供几个思路：

如何保证消息的可靠性传输（如何处理消息丢失的问题）？

以kafka为例：

(1)消费端丢失数据

唯一可能导致消费端弄丢数据的情况，就是当消费到了这个消息，然后消费者自动提交了offset，此时kafka认为消费端已经消费好了此条消息，其实这时消费端刚准备处理这条消息，还没有处理，消费端就宕机了，这条消息就丢失了。

解决方案：kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动去提交offset，就可以保证数据不会丢失，但此时会出现重复消费的问题，例如当消费端刚处理完，还没有手动去提交offset，消费端就宕机了，此时消费端一定会重复消费一次，这时需要上文中的解决方案来保证幂等性。

kafka保证消息传输的可靠性图解：