由消息队列想到的

由消息队列想到的

在即将深入了解kafka与JMQ之前,不妨问自己几个问题,为什么要使用消息中间件?京东为什么要不使用广受好评的成型开源产品,而是自己研发JMQ呢?

微信图片_2017120716352716

这篇文章主要是一些入门的思考,我会增加一个菜单专门用来管理中间件方面的知识,首先是后面一个问题的思考,京东为什么要自己研发JMQ?这个问题在我入职第一天就有思考,昨天志良哥跟我说了很多,但是由于自己的技术高度有限,对这一方面也不是很了解,听的似懂非懂,总之就是大概两个方面:1.kafka有些东西对于用户不是很透明,需要使用者了解一些相应的规则,也就是侵入式的吧,2.kafka不能满足高并发电商的实时性,具体里面的细节目前还不知道,后面我遇到会在后面的文章中追加,去了这两个方面,我想还有一个就是大厂逼格吧,既然阿里开源了RocketMQ,那么咱也不能落后啊,总之就是没有最好的,只有最适合自己的

为什么使用消息中间件呢?直接进行调用不香?

  • 解耦
    其实很容易想到的一点就是解耦,我们在学习软件工程的时候就一遍遍的了解到,系统设计要满足高内聚、低耦合的特点,这都不用多想,就想系统设计的宪法一样,其实现在发现,互联网的很多都是可以通过加一个中间件的方式解决的,这几乎是一种设计思想了,目前能想起来的,内存访问数据库加一个redis,CPU访问内存加一个缓存,生产者消费者之间加消息队列,后面随着认知的扩展可能还会遇到很多

  • 异步

    来看这个图:

    系统ABCD之间是相互调用的关系,共同来完成一个业务流程,当处理一个请求时,一共需要的时间是:20ms+200ms+2000ms=2220ms,一共花费了2s多,我们平时以为2s没什么的,但是对于实时性要求比较高的系统,根本是不允许的,我们可以看到这次时间消耗主要都集中在C调用D这个过程,前面还是非常快的,只有220ms,那我们能否将C调用D分离出去,进行异步处理呢?还是要看业务场景,但是我觉得大多数都是允许的,这样整个系统的响应时间就足足快了10倍!!!

    拿我们生活中的例子来理解,使用美团外卖订餐的时候,是不是下单速度非常快,快到几乎无法感知,而下单一会之后才显示骑手已接单?我不了解美团具体是怎么做的,但是应该是差不多的道理,下单之后,需要进行几个步骤,大概是扣除金额,订单生成,商家接单并做菜,匹配骑手,其中匹配骑手是非常消耗时间的,需要相关算法的复杂计算,这对应着上面的C调用D,而将这个耗时的步骤做成异步处理,就可以极大的提高用户体验,不然的话我们在付款的时候一直等两分钟找到骑手,订单才提交成功?

    加入消息中间件之后,就是这样一个流程:

  • 削峰

当然还是建立在业务场景允许的场景下,如果一个集群里面的机器在正常运行,但是突然遇到流量极具增加的情况,例如618大促,这时候如果没有MQ是根本顶不住的,这时可以在高峰期积压一些请求在MQ中,集群再慢慢消费,这样不仅可以提高并发量,还可以节省一定的硬件成本

从上面来看消息队列虽然这么香,但是也是存在一定的问题的,虽然我还没亲身遇到过,但是还是可以提前想到的:MQ满了消息丢失怎么办?MQ里面百万级别的请求积压怎么办?如何保证生产者或者消费者到达MQ的过程数据不丢失?死信队列?

路漫漫,后面还有很多的要思考......