为什么使用消息队列解耦

譬如签到送积分, 签到和送积分是两个操作. 签到产生了很重要的数据, 它可以把该消息发送到MQ. 然后积分系统需要该数据, 从MQ中直接获取即可. 这样签到系统就做到了和积分系统解耦. 不必担心积分系统挂了怎么办, 是不是需要重试等. 这些都可以在积分系统内部自己实现. 再者, 如果以后另外一套系统也需要该签到数据, 直接从MQ中获取即可, 实际上与签到系统已无关系.

异步

当做到解耦后, 实际异步就是自然而然的事情. 如果签到只需要1ms, 而送积分, 或者其他操作需要500ms, 那不可能等所有操作完成之后再去返回数据给用户. 这样就做到了异步.

削峰

削峰是指当并发访问高峰期, 通过MQ达到限流的目的, 从而减少对数据库MySQL的压力.

消息队列有什么优点和缺点

优点就是第一点所提到的解耦, 异步, 削峰

缺点:

系统可用性降低(当然有办法保证高可用), 相对而言系统复杂度提高(这是引入新技术之后的必然结果), 因为随之而来的问题就是该技术本身的问题: 如何保证消息没有重复消费, 如何保证消息不丢失, 如何保证消息的顺序性等等数据一致性问题(也可以归为系统复杂度提高的问题), 可以解决如何保证消息的高可用消息传递路径更长, 延时会增加上游无法知道下游的执行结果(很致命)MQ适合使用的场景数据驱动的任务依赖. 如晚上执行的定时任务, task1, task2, task3, task2依赖task1, task3依赖task2上游不关心执行结果. 如签到送积分, 修改/添加/删除数据要添加审计日志上游关注执行结果,但执行时间很长. 如通过支付宝转账, 第三方把转账结果通过网关放入MQ, MQ再来通知用户MQ不适合使用场景

上游需要依赖下游的执行结果, 如登录, 不能把登录成功的消息放入MQ

各种MQ如何选择社区活跃度,: RabbitMQ和kafka > rocketMQ(阿里) > ActiveMQ性能: kafka, rocketMQ > RabbitMQ > ActiveMQ功能完善性: rocketMQ, rabbitMQ, activeMQ > kafka

所以中小公司, 没有自主研发能力的选择RabbitMQ,

如果大数据公司做实时计算, 日志采集建议用kafka

大公司可以使用rocketMQ, 因为用Java开发, 有问题自己可修改

如何保证消息不被重复消费(消费的幂等性)

重复消费的场景:

同一个消费者重复消费

指定时间内未消费完, 没有提交offset, 下次消费时重复消费

不同的消费者重复消费

consumer消费完之后, 没有提交offset或者未提交成功offset, consumer挂了, 该消息被分配给了其他consumer, 导致重复消费

问题解决:

设置超时时间关闭自动提交, 改为手动提交, 提交之前检测数据库中是否有该消费过的数据如何保证消息的可靠性传输(消息丢失问题)

消息丢失场景:

生产者丢失数据MQ丢失数据消费者丢失数据

问题解决:

生产者要等MQ返回ack之后才认为该消息发送成功, 否则重试.(异步发送ack或nack信号, 不用等待)RabbitMQ是通过持久化和confirm机制(即生产者要等MQ返回ack); kafaka通过设置参数:replication.factor 参数: 这个值必须大于 1，要求每个 partition 必须有至少 2 个副本min.insync.replicas 参数: 这个值必须大于 1，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 followeracks=all: 这个是要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了retries=MAX（很大很大很大的一个值，无限次重试的意思): 这个是要求一旦写入失败，就无限重试rabbitMQ和kafka关闭自动ack, 改为手动ack, 如果该消费者未提交ack, 那么MQ会分配其他消费者消费该消息;如何保证消息的顺序性

场景: 如现在需要做一个mysql binlog的同步系统, 如果原始顺序是create, update, delete, 如果是无序的就有可能变成delete, create, update, 这样就出错了.

RabbitMQ场景: 生产者放入顺序是data1, data2, data3, 因为有多个消费者, 所以有可能顺序会乱

kafka场景: 生产者放入data1, data2, data3,生产者指定key,可以让这3条数据放入一个partition,一个partition是由一个消费者来消费的, 但是消费者端肯定会起多个线程来消费消息, 多个线程并发, 顺序就可能乱掉了.

解决:

实际上所有的顺序一致性都是: 生产者 ---> MQ server ---> 消费者, 只要消息在生产者, MQ server和消费者中间是顺序一致的, 就能保证消息的顺序一致. 保证生产者消息放入MQ server中的时候, 相同key的数据只放入一个queue(或partition), 然后消费的时候由一个消费者来消费, 就能保证消息的顺序一致. 譬如下单, 扣款, 发货, 这三个消息, 只要保证同一个订单内部的一致性就可以. 不同订单没有因果关系, 所以可以不用保证不同订单之间的顺序一致.

如何保证MQ的高可用rabbitMQ 通过镜像集群模式. 即创建的queue, 无论是元数据还是queue里的消息, 都会存在于多个实例上. 就是说每个rabbitMQ节点都有这个queue的一个完整镜像.包含queue的全部数据, 每次写消息到queue的时候, 都会自动把消息同步到多个queue上.kafka天然的分布式消息队列, kafka集群由多个broker组成, 一个topic可以有多个partition, 每个partition存在于不同的broker上. 每个broker上只存partition的一部分数据. 每个partition都会有副本存在于其他broker上, 这样即使有broker宕机, 也可以重新选举出一个partition作为leader, 继续支持读写.如何处理消息的延时以及过期失效问题

因为MQ,如rabbitMQ有ttl, 如果数据积压, 超过TTL时间不处理, 会直接丢掉.

这时候, 只能把这些数据进行批量重导, 重新灌入mq里面

消息队列满了怎么处理

临时写个程序, 不做耗时操作, 操作一条废弃一条. 到系统并发量小的时候,譬如晚上12点的时候, 再做批量重导.

有百万条消息积压几小时,怎么处理

场景: MQ里积压了上千万条数据

解决:

查清楚是什么原因导致消息积压: consumer程序bug; consumer的消费速度落后于producer的生产速度;如果仅是consumer的的消费速度落后于生产速度的话, 考虑扩容即可若是consumer故障, 修复consumer, 并将其停掉重新创建一个容量大的topic, 比如partition是原来的10倍编写一个新的consumer, 消费原来积压的队列, 该consumer不做任何耗时的操作,将消息均匀的写入新创建的队列里将修复好的consumer部署到原来10倍机器上消费队列消息积压解决后, 恢复原有架构如何自己设计一个消息队列

首先要理解kafka的原理

broker --> topic --> partition, 如果资源不够用了, 就给topic增加partition, 提高吞吐量mq要顺序落盘高可用partition 副本, leader, broker解决数据0丢失