消息队列的优缺点，使用场景
优点：
1、解耦，降低系统之间的依赖
2、异步处理，不需要同步等待
3、削峰填谷，将流量从高峰期引到低谷期进行处理
缺点：
1、增加了系统的复杂度，幂等、重复消费、消息丢失等问题的带入
2、系统可用性降低，mq的故障会影响系统可用
3、一致性，消费端可能失败
场景：日志采集、发布订阅等
如何保证消息不被重复消费
幂等：一个数据或者一个请求，重复来多次，确保对应的数据是不会改变的，不能出错。
思路：
- 如果是写 redis，就没问题，反正每次都是 set ，天然幂等性
- 生产者发送消息的时候带上一个全局唯一的id,消费者拿到消息后，先根据这个id去 redis里查一
下，之前有没消费过，没有消费过就处理，并且写入这个 id 到 redis，如果消费过了，则不处理。
- 基于数据库的唯一键
Kafka、ActiveMQ、RabbitMQ、RocketMQ 对比
ActiveMQ：JMS规范，支持事务、支持XA协议，没有生产大规模支撑场景、官方维护越来越少
RabbitMQ：erlang语言开发、性能好、高并发，支持多种语言，社区、文档方面有优势，erlang语言
不利于java程序员二次开发，依赖开源社区的维护和升级，需要学习AMQP协议、学习成本相对较高
以上吞吐量单机都在万级
kafka：高性能，高可用，生产环境有大规模使用场景，单机容量有限（超过64个分区响应明显变
长）、社区更新慢
吞吐量单机百万
rocketmq：java实现，方便二次开发、设计参考了kafka，高可用、高可靠，社区活跃度一般、支持语
言较少
吞吐量单机十万
