消息组件的一些问题

消息的重复消费 （可怕的不是重复消费，确保消费后的幂等性）{

1、全局id 业务判断 是否insert or update
2 、redis set 天然的幂等性
3、数据库索引等
}
消息的丢失{
1、生产者的丢失 a/开启rabbitMQ(同步不推荐) b 开启confirm模式（异步，推荐）
2、MO消息丢失 开启MQ持久化
3、消费者消息丢失 关闭rabbitMq 自动 ACK
}
消息的顺序性
RabbitMQ 方案：
拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，
确实是麻烦点；或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

Kafka 方案：
写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。

消息堆积：

解决思路：临时扩容
1 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
2 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
3 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
4 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
5 等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。

或者 解除订阅 丢弃数据 手动补回
消息快满了：写临时程序 快速消费 ，丢弃数据 ，然后补数据吧。