肝了很久的字节跳动消息队列面经
|
低 系统引入的外部依赖越多，越容易挂掉?如何保证消息队列的高可用? 系统复杂度提高 怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性? 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了;但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整?你这数据就不一致了。 以下主要讨论的RabbitMQ和Kafka两种消息队列。 如何保证消息队列的高可用? RabbitMQ的高可用 RabbitMQ的高可用是基于主从(非分布式)做高可用性。RabbitMQ 有三种模式：单机模式(Demo级别)、普通集群模式(无高可用性)、镜像集群模式(高可用性)。
普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据(元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例)。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。 而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。 （编辑：宁德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
