美文网首页
MQ随记(1)

MQ随记(1)

作者: 喧嚣城外 | 来源:发表于2019-02-13 17:58 被阅读0次
    为什么使用 MQ?
    • 解耦

    一个系统或者模型,调用多个系统或者模块,互相调用非常复杂,维护也很麻烦,但是当不需要同步调用情况时,用MQ解耦是一个选择。
    各个业务系统在未使用MQ时,在需要相互传输数据时,耦合性就会很高,从而造成相互合作比较麻烦,使用MQ可以降低耦合性,从而只关心自己的业务。

    • 异步

    互联网用户等待时间一般要求200ms以内。
    当系统后台操作执行时间较长,系统反应时间很慢从而影响到了客户的体验。当使用MQ后,可以提升系统的响应时间,相应的复杂操作可以由后台执行无需等待。

    • 削峰

    当数据量一瞬间非常大时,如果后台涉及到使用sql,大于5000次/s可能就会造成系统宕机,所以需要使用MQ进行防止此类情况发生,高峰期过后MQ中堆积的数据也会很快被消费掉。


    使用MQ可能会存在的问题
    • 系统的可用性降低

    当MQ故障,整个系统就会崩溃。

    • 系统的复杂性变高

    引入MQ导致系统考虑的问题增多。

    • 一致性问题

    MQ的技术选型

    现在可供选择的MQ类型有ActiveMQ、RabbitMQ、RocketMQ、Kafka。
    相关区别如下表格:

    特性 ActiveMQ RabbitMQ RocketMQ Kafka
    单机吞吐量 万级 万级 10万级 10万级 一般配合大数据类的系统来进行实时数据计算,日志采集等场景
    topic数量对吞吐量的影响 topic可以达到几百,几千的级别,吞吐量会小幅度下降,这个是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic topic从几十个到几百个的时候,吞吐量会大复度下降。所以在同等机器下,kafka尽量保证topic数量不要过多。
    时效性 ms 微妙 ms ms
    可用性 高,基于主从架构实现高可用性 高,基于主从架构实现高可用 非常高,分布式架构 非常高
    消息可靠性 有较低的概率丢失数据 经过参数优化可以做到0丢失 经过参数优化可以做到0丢失
    功能支持 MQ领域的功能极其完备 基于erlang开发,所以并发行非常好,性能好,延迟低 MQ功能较为完善,还是分布式的,扩展性好 功能比较简单,主要支持简单的MQ功能,在大数据领域是事实上的标准
    优劣势总结 优点:非常成熟,功能强大,在业内曾大量公司以及项目中使用。缺点:社区内以及国内应用越来越少,维护频率很低,几个月一次。主要用于解耦和异步,较少用于大规模吞吐的场景。 优点:erlang语言开发,性能好,延迟低。吞吐量过万,开源提供的管理界面非常棒,社区比较活跃,每个月都会发布几个版本。 缺点:erlang开发,国内鲜有几个公司可以对erlang源码级别研究和定制。 优点:阿里出品java系的,可以阅读源码并定制,社区活跃度一般,文档相对简单。缺点:万一这个技术被抛弃,社区放弃更新,需要自身具备当出现bug时候可以主动修复的实力。

    不推荐使用activeMQ,因为没有经过大规模吞吐量场景的验证,社区也不是很活跃。
    越来越多公司在使用RocketMQ,确实不错,但是需要考虑万一社区抛弃的风险,使用RabbitMQ,社区活跃人员为散户,不会黄掉.


    如何实现高可用性
    RabbitMQ

    普通集群模式:

    • 可能会在rabbitMQ集群内部产生大量的数据传输。
    • 可用性几乎没有保障。

    镜像集群模式:
    每个节点都会存储全部queue信息。可以保证高可用性。
    当一个节点宕机,可以在其他节点消费或生产到消息。

    如何配置镜像集群模式:
    rabbitMQ有控制台,在控制台增加一个策略,镜像集群模式策略,指定的时候可以要求数据同步到所有节点,也可以要求同步到某些节点。

    Kafka

    多个broker组成,每个broker是一个节点;创建一个topic,这个topic可以划分为多个partition,每个partition可以存在于不同的broker上,每个partition就放一部分数据。
    这就是天然的分布式消息队列,就是一个topic的数据,分散放在多个机器上,每个机器就放一部分数据。
    实际上rabbitmq之类的,并不是分布式消息队列,他就是传统的消息队列,只不过提供了一些集群,HA的机制而已,无论怎么玩,rabbitmq一个queue的数据都是放在一个节点内,镜像集群下,也是每个节点都放在这个queue的完整数据。
    kafka0.8后提供了HA机制,就是replica副本机制,每个partition的数据都会同步到其他机器,形成自己多个replica副本。然后所有replica会选举一个leader出来,然后生产和消费和这个leader打交道,然后其他副本就是follower。读的时候就直接读leader数据即可。
    如果一个broker宕机了,没事,那么broker上面的partition在其他机器上都有副本的,如果这上面有某个partition的leader,那么此时会重新选举一个新的leader出来。继续读写这个leader就可以了。这个就是高可用性。

    相关文章

      网友评论

          本文标题:MQ随记(1)

          本文链接:https://www.haomeiwen.com/subject/jpbdeqtx.html