概要：我们使用消息队列，就需要知道为什么要用消息队列，什么场景需要用消息队列，使用消息队列能带来哪些好处和消息队列会带来哪些问题？如何去避免这些问题。
一、MQ的好处
解耦：在某些场景下，A服务订单达到某个状态之后，需要发生一份消息到好几个服务，但是对于A服务来说，它并不关心其他服务如何什么时候、如何处理这个消息。那么就可以利用MQ解耦。A服务只管将消息发出去，其他服务想要用这个数据，就可以开启消费者组，这样就可以保证每个服务能消费到所有的数据了。
异步：使用异步可以提高接口响应速度，如果要跟其他系统交互的话，时间大概是几百ms，而投递到MQ时间在几ms，而且在不同场景下调节参数可以提高消息投递的速度。（ack的值)
削峰：在流量比较高的时候，为了较少对MySQL的压力，使用缓存主要是解决查询的压力，而对于写入则可以用MQ来削峰，在高峰期时候流量进入MQ，会造成暂时的积压，等流量降低之后，积压的数据很快就会被消费完。
MQ的好处这么多，但是也无可避免地会带来一些问题。主要是以下两个方面1. 系统的可用性降低，引入了中间件，如果中间件挂了，那么数据有丢失风险2. 复杂度上升，正常的系统间交互，我们通常不需要考虑重复消费问题，只要从HTTP请求来解决幂等性就可以。还有就是消息积压的解决，对于MQ的监控等问题，都要加以考虑。接下来我们就逐一看看对于常见的MQ问题。
二、消息丢失问题
Kafka消息丢失可以分为三种情况：生产者发送过程丢失，Kafka丢失和消费端丢失。
- 生产者丢失：Producer端的ack表示什么情况下Kafka才认为数据成功成功发送。ack=0表示生产者不需要等待broker的同步确认，就可以处理下一批数据了，那么如果由于网络原因或者leader挂了，消息丢失了，也很难发现。ack=1表示生产者需要确认leader成功写入就可以成功返回给生产者客户端，这种配置下如果leader挂了，那么消息也会丢失。另一种比较可靠的配置是ack=-1，表示消息成功写入leader和ISR副本之后就可以返回了，如果leader挂了，Kafka还可以从ISR中选举出新的leader，如果这时候ISR为空，那么根据其他参数看是否选举其他副本，这其实就是在高可用和消息不丢失之间的权衡了。另外retires重试次数设置大一些可以保证在生产过程消息不会丢失。
- Kafka丢失消息：这里需要关注的主要就是Kafka的删除策略，如果文件过大，或者是超过一段时间，会被Kafka删除。还有Kafka的持久化 方式，Kafka其实是充分利用了磁盘的页缓存的，那么如果写入页缓存，没写入磁盘的时候ack是否会返回？（这块需要再查一下相关书籍）。
- 消费者丢失消息：这个其实也比较常见，如果设置Kafka自动提交偏移量，那么可能消息偏移量提交之后，消费者挂了，消息还没处理完，那么这部分数据就丢失了。在消费者端解决的方式就是由消费端决定何时提交偏移量，设置enable.auto.commit为false
三、重复消费问题
这个方案有Kafka的内置幂等性保证和事务，但是对性能有损，虽好还是结合业务情况来保证幂等性。
比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。
比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。
四、消息积压问题
消息积压主要有以下原因：
消费者速度跟不上生产者的速度：这个时候，可以先看批次拉取的大小是否合理，以及消费者的消费逻辑是否已经使用多线程消费了。如果还是跟不上消费速度，那么可以考虑同时增加partition和消费者大小。
消费者挂了：先把消费者恢复。
瞬时流量过大：如果是这个原因的话，如果积压的不是特别多的话，等流量低的时候消费者自然会把积压的数据消费完。
五、高可用问题
Kafka架构可以保证高可用
六、顺序性问题
对于Kafka来说，以topic为逻辑单位存储，物理存储结构单位是partition，而topic切分成partition无法保证有序，但是partition是顺序写的，可以保证有序。如果我们需要按照某个维度保持有序的话，可以设置消息的key
