分布式-消息队列

Author: xbox1994

MD/分布式-消息队列.md

@@ -1,8 +1,42 @@
-## 消息队列
-消息队列目的：
-  
+来源： https://github.com/doocs/advanced-java#%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97 https://dbaplus.cn/news-73-1123-1.html
+
+## 优点
 1. 减少请求响应时间。比如注册功能需要调用第三方接口来发短信，如果等待第三方响应可能会需要很多时间
 2. 服务之间解耦。主服务只关心核心的流程，其他不重要的、耗费时间流程是否如何处理完成不需要知道，只通知即可
 3. 流量削锋。对于不需要实时处理的请求来说，当并发量特别大的时候，可以先在消息队列中作缓存，然后陆续发送给对应的服务去处理
 
-如果想要实现一个消息队列，可以参考[这里](https://zhuanlan.zhihu.com/p/21649950)  
+## 缺点
+1. 系统可用性降低。系统引入的外部依赖越多，越容易挂掉。
+2. 系统复杂度提高。保证消息没有重复消费？处理消息丢失的情况？保证消息传递的顺序性？
+
+## 消息重复消费问题
+1. 消费端处理消息的业务逻辑保持幂等性，在消费端实现
+2. 利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息。消息系统实现，也可以消费端实现
+
+## 消息丢失问题
+### 生产者弄丢了数据
+生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了。
+
+RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务。然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错。但吞吐量会下来，因为太耗性能。
+
+可以开启confirm模式，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个ack消息，告诉你说这个消息 ok 了。事务机制是同步的，但confirm机制是异步的，发送个消息之后就可以发送下一个消息，RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。所以用confirm机制
+
+### RabbitMQ 弄丢了数据
+RabbitMQ 自己挂掉导致数据丢失
+
+开启 RabbitMQ 的持久化，消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，恢复之后会自动读取之前存储的数据
+
+### 消费端弄丢了数据
+RabbitMQ 如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，RabbitMQ 认为你都消费了，这数据就丢了。
+
+关闭 RabbitMQ 的自动ack，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里ack一把。RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。
+
+## 消息顺序性
+消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照顺序依次消费才有意义。
+
+消息体通过hash分派到队列里，每个队列对应唯一一个消费者。比如下面的示例中，订单号相同的消息会被先后发送到同一个队列中：
+
+![](https://github.com/xbox1994/2018-Java-Interview/raw/master/images/消息顺序性.jpg)
+
+在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择一个队列，同一个订单号获取到的肯定是同一个队列。
+