网站开发过程有几个阶段,眉山建设银行官方网站,云建设平台,重庆孝爱之家网站建设消息队列 问题1 如何进行消息队列的技术选型优点解耦 #xff08;pub/sub模型#xff09;异步#xff08;异步接口性能优化#xff09;削峰 使用消息队列的缺点几种消息队列的特性 问题2 引入消息队列之后该如何保证其高可用性RabbitMQ的高可用kafka高可用 问题3 在消息队列… 消息队列 问题1 如何进行消息队列的技术选型优点解耦 pub/sub模型异步异步接口性能优化削峰 使用消息队列的缺点几种消息队列的特性 问题2 引入消息队列之后该如何保证其高可用性RabbitMQ的高可用kafka高可用 问题3 在消息队列里消费到了重复的数据怎么办问题4 如何保证消息的可靠性RabbiteMQ可能存在消息丢失的问题kafka可能消息丢失的问题 问题5 怎么保证从消息队列里拿到的数据按顺序执行RabbiteMQ保证消息顺序性kafka保证消息顺序性 问题6 几百万消息在消息队列里积压怎么办问题7 让你来开发一个消息队列中间件你会怎么设计架构 问题1 如何进行消息队列的技术选型
为什么使用消息队列消息队列的优点和缺点kafkaactiveMQrabbitMQ、rocketMQ的优点和缺点都有什么区别以及适用那些场景
消息队列应用场景有很多但是主要目的是的解耦异步削峰
优点
解耦 pub/sub模型 异步异步接口性能优化 削峰 使用消息队列的缺点
可用性降低系统复杂性提高比如消息重复消息丢失消息顺序一致性问题
几种消息队列的特性
特性activeMQRabbiteMQRocketMQkafka单机吞吐量万级万级10万级可以支撑高吞吐量10万级别高吞吐量。适合日志采集实时计算等场景topic数量对吞吐量的影响––topic可以达到几百几千个的级别吞吐量会有较小幅度的下降这是RocketMQ的一大优势在同等机器下可以支撑大量的topic topic从几十个到几百个的时候吞吐量会「大幅度下降」所以在同等机器下kafka尽量保证topic数量不要过多。如果要支撑大规模topic需要增加更多的机器资源topic从几十个到几百个的时候吞吐量会「大幅度下降」所以在同等机器下kafka尽量保证topic数量不要过多。如果要支撑大规模topic需要增加更多的机器资源时效性ms级微秒级这是rabbitmq的一大特点延迟是最低的ms级ms级可用性高基于主从架构实现高可用性高基于主从架构实现高可用性 非常高分布式架构非常高分布式架构非常高分布式架构消息可靠性有比较低的丢消息可能–经过参数优化配置可以做到0丢失经过参数优化配置可以做到0丢失总结非常成熟比较早 偶尔丢消息社区活跃度低基于erlang开发所以并发能力很强性能极其好延时很低MQ功能较为完善还是分布式的扩展性好功能较为简单主要支持简单的MQ功能在大数据领域的实时计算以及日志采集被大规模使用是事实上的标准
其实activeMQ、RabbiteMQ更类似单机应用一个queue的数据不会被拆分成多分分散到多个机器上RocketMQ、kafka是分布式的一个topic数据可以被拆分成多个partition进而分散到多个机器上摆脱单机容量限制
问题2 引入消息队列之后该如何保证其高可用性
高可用主要是避免单机故障有副本以及数据不丢磁盘
RabbitMQ的高可用
有三种部署模式
单机模式 简单demo普通集群模式 不能保证高可用机器挂了数据就访问不了但是整个集群的容量是可以超过单个机器的大小镜像集群模式所有机器完全相同但是不能超过单机容量限制 kafka高可用 一个topic可以有多个partition这样就可以把一个topic数据分散到多个机器上摆脱单机限制每个partition有leader和follower这样如果leader挂了follower可以升级成leader
问题3 在消息队列里消费到了重复的数据怎么办
问题怎么保证消息不被重复消费或者说怎么保证消息消费时的幂等性 消息队列只保证消息不丢并不保证消息不会重发所以需要应用保证幂等 问题 如何保证系统幂等性
问题4 如何保证消息的可靠性
怎么保障消息不丢
RabbiteMQ可能存在消息丢失的问题 kafka可能消息丢失的问题
整体上一样的kafka是自动提交offset当消费者处理完再提交offset
问题5 怎么保证从消息队列里拿到的数据按顺序执行
RabbiteMQ保证消息顺序性 kafka保证消息顺序性
kafka只能保证partition内部数据的顺序性不会处理多个partition所以如果是业务的一些操作的话可以指定partition或者通过key计算hash保证一个业务的数据会到一个partition
问题6 几百万消息在消息队列里积压怎么办
面试如何处理消息队列延时及过期失效的问题消息队列满了怎么处理有几百万消息积压几个小时应该怎么办 分析可能是消费端出现问题不消费了或者是消费变慢了以及可能消息队列中数据快把磁盘堆满了都没人消费并且在RabbiteMQ中有TTL设置过期的数据可能就丢失了常见的例子比如消费端需要把数据写入到数据库结果mysql挂了消费就hang住了
问题7 让你来开发一个消息队列中间件你会怎么设计架构
主要考察对于消息队列有没有研究能不能整体上把握住给出一些关键点
(1)首先这个 mq得支持可伸缩性吧就是需要的时候快速扩容就可以增加香吐量和容量那怎么搞?设计个分布式的系统呗参照一下 kafka 的设计理念broker - topic-partition每个 partition 放一个机器就存一部分数据。如果现在资源不够了简单啊给topic 增加 partition然后做数据迁移增加机器不就可以存放更多数据提供更高的吞吐量了? (2)其次你得考虑一下这个 mg 的数据要不要落地磁盘吧?那肯定要了落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊?顺序写这样就没有磁盘随机读写的寻址开销磁盘顺序读写的性能是很高的这就是 kafka 的思路。 (3)其次你考虑一下你的 mq的可用性啊?这个事儿具体参考我们之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -leader follower -broker 挂了重新选举 leader即可对外服务。
