1.是否有了解主流消息队列
你用过消息队列,引入队列有啥优缺点,对比其他消息中间产品,选择这款的原因是啥?
- 优点:解耦系统、异步化、削峰
- 缺点: 系统可用性降低、复杂度增高、维护成本增高
- 主流消息队列Apache ActiveMQ、Kafka、RabbitMQ、RocketMQ
- ActiveMQ:http://activemq.apache.org/
- Apache出品,历史悠久,支持多种语言的客户端和协议,支持多种语言Java, .NET, C++ 等,基于JMS Provider的实现
缺点:吞吐量不高,多队列的时候性能下降,存在消息丢失的情况,比较少大规模使用
- Kafka:http://kafka.apache.org/
- 是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理大规模的网站中的所有动作流数据(网页浏览,搜索和其他用户的行动),副本集机制,实现数据冗余,保障数据尽量不丢失;支持多个生产者和消费者
缺点:不支持批量和广播消息,运维难度大,文档比较少, 需要掌握Scala
- RabbitMQ:http://www.rabbitmq.com/
- 是一个开源的AMQP实现,服务器端用Erlang语言编写,支持多种客户端,如:Python、Ruby、.NET、Java、JMS、C、用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不错
缺点:使用Erlang开发,阅读和修改源码难度大
- RocketMQ:http://rocketmq.apache.org/
- 阿里开源的一款的消息中间件, 纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点, 性能强劲(零拷贝技术),支持海量堆积, 支持指定次数和时间间隔的失败消息重发,支持consumer端tag过滤、延迟消息等,在阿里内部进行大规模使用,适合在电商,互联网金融等领域使用
- 缺点:成熟的资料相对不多,社区处于新生状态但是热度高
2.是否知道oneway、延迟消息等类型消息的应用
消息队列的发送方式有哪几种,使用场景分别是怎样的?
发送方式汇总对比
发送方式 | 发送 TPS | 发送结果反馈 | 可靠性 |
---|---|---|---|
同步发送 | 快 | 有 | 不丢失 |
异步发送 | 快 | 有 | 不丢失 |
单向发送 | 最快 | 无 | 可能丢失 |
有没用过延迟消息,使用场景是怎样的?
3.如何保证消息队列的消息生成和消费的顺序性
你用的队列是否支持顺序消息,是怎么实现顺序消息的?
补充知识
4.考查怎么样可以避免重复消费
你的业务系统有没做消息的重复消费处理,是怎么做的
- 幂等性:一个请求,不管重复来多少次,结果是不会改变的。
- RabbitMQ、RocketMQ、Kafka等任何队列不保证消息不重复,如果业务需要消息不重复消费,则需要消费端处理业务消息要保持幂等性
- 方式一:Redis的setNX() , 做消息id去重 java版本目前不支持设置过期时间
//Redis中操作,判断是否已经操作过 TODO boolean flag = jedis.setNX(key); if(flag){ //消费 }else{ //忽略,重复消费 }
- 方式二:redis的 Incr 原子操作:key自增,大于0 返回值大于0则说明消费过,(key可以是消息的md5取值, 或者如果消息id设计合理直接用id做key)
int num = jedis.incr(key); if(num == 1){ //消费 }else{ //忽略,重复消费 }
- 方式三:数据库去重表
- 设计一个去重表,某个字段使用Message的key做唯一索引,因为存在唯一索引,所以重复消费会失败
- CREATE TABLE
message_record
(id
int(11) unsigned NOT NULL AUTO_INCREMENT,key
varchar(128) DEFAULT NULL,create_time
datetime DEFAULT NULL, PRIMARY KEY (id
), UNIQUE KEYkey
(key
) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
5.如何保证消费的可靠性传输
你用了消息队列,你知道这个消息队列如何保证消息的可靠性传输吗
小图辅助理解
5.是否有研究消息队列不可用后的应急方案,是否有架构思维
消息堆积了10小时,有几千万条消息待处理,现在怎么办?
修复consumer, 然后慢慢消费?也需要几小时才可以消费完成,新的消息怎么办?
辅助理解图
本文作者为DBC,转载请注明。