细说RocketMQ(一)

1,消息队列企业级应用场景分析

什么是消息队列?

消息队列是在消息传输过程中保存消息的容器,生产者和消费者不直接通讯,依靠队列保障消息的可靠性,避免了系统间的呼吸影响。

消费队列注意角色

服务端、客户端:生产者,消费者

业务解耦

将模块间的RPC调用改为通过消息队列中转,接触系统间的耦合。

MQ解耦合的有点:

1,提升系统稳定性:ServiceB挂了不会影响到ServiceB

2,通过广播消息避免多次调用:假如ServiceA除了需要调用ServiceB,还需要调用其他的服务,则其他服务都来订阅topic即可。

3,提高编码效率:如果是直接同步调用各个服务,还需要知道各个服务的接口信息,参数传递等,也就是说有一些对接的工作不可避免。MQ的话,消息直接丢到MQ即可。

异步调用

无需关注调用结果的的场景,可以通过消息队列异步处理。

比如一个电商的下单业务:1,风控验证;2,下单处理;3,扣减库存;4,通知卖家;5,记录数据

如果此5步都是同步调用的,处理过程RT必然会很长。第4,5步无需关注返回结果的,通过投递到MQ,进行异步处理。从而可以缩短主流程的RT。

流量削峰

系统的吞吐量往往取决于底层存储服务的处理能力,应用可以调整消费速度缓解存储服务压力,避免短暂的高峰将系统压垮。

应用层可以横行扩展增加吞吐量,但是底层DB扩展没这么简单,处理能力有限,可以通过MQ来消除流量高峰,应用层匀速进行处理。

MQ对系统架构的影响

使用消息队列可以带来很大的收益,但是也会对系统架构造成一些负面影响,而且MQ不能完全替代RPC,需要合理设计业务调用。

架构复杂度:MQ毕竟是引入了一个组件,架构的复杂度肯定是提高的。

系统的可用性:新引入的组件链路变长了,毕竟是多了一个环节,可用性必然是会有所降低的。站在架构角度来讲,多一个环节对系统的影响必须是要统一来评估的。

排查问题路径:链路边长了,排查问题的路径自然也就会更长,更复杂。

2,主流消息队列比对分析

目前主流的MQ主要是RocketMQ,kafka,RabbitMQ,选型应当从如下几个维度来看:

  • 系统定位
  • 支持功能
  • 可用性
  • 可靠性
  • 运维

基础比对

可靠性/可用性比对

功能比对

结论

各个MQ最初的设计定位不一样,所以才造成了各MQ之间差异较大。

Kafka:系统间数据流的通道

RocketMQ:高性能可靠消息传输

RabbitMQ:可靠消息传输

所以RocketMQ和RabbitMQ更偏向于业务应用。 Kafka各个偏向于做数据流通道,日志收集等。

3,RocketMQ高可用及高扩展解决方案剖析

且听下回分解。

稀土掘金
我还没有学会写个人说明!
上一篇

中国科学家“改造”T细胞增强抗肿瘤能力

下一篇

聊两句XSS(跨站脚本攻击)

你也可能喜欢

评论已经被关闭。

插入图片