初始消息中间件

Posted 2020-11-25 gmt-hao

    现在大型互联网公司中，都会用到的消息中间件，其实任何一个程序员也多多少少都会知道有这么一个东西的存在，那么他到底是用来干什么的呢？

    答案很明显，是用来做消息的传输与接受(消息的中间媒介嘛)，他主要用在分布式系统中作为其中的一个子系统，关注数据的发送与接收，利用其高效的异步消息传递机制对分布式系统中的其余各个子系统进行集成(是的，这段是抄的，显得专业嘛)。并且他有几大优点：

    高效（对于消息的处理速度快），可靠（主要依赖其持久化机制），异步（这个应该都懂，就是左手干活右手不用闲着）

    知道了消息中间件是什么，那么第二个问题来了，我们为啥要用它呢？

    大家都知道分布式系统是为了解决高用户量下出现的高并发带来的资源不能及时满足，因此通过系统的各个业务模块的拆解，缓解资源的压力，其实这些一般也可以用rpc进行解决，但是当业务越来越复杂，一笔订单之后还需要做一系列调用接口的操作，我们为了不影响用户的使用感受，就必须使用消息中间件了。看到这里应该是还有很多疑惑的，消息中间件为啥就可以做rpc所不能做的事情呢，难道他比rpc还要厉害？

    消息中间件有很多优点，比如他是低耦合的（生产者只需要发消息，消费者只需要拿消息），异步（刚才说到了），缓冲能力（消息发过去不需要立刻处理，消费者可以慢慢去消费，当然这个结合实际业务），伸缩性（当消息队列满足不了的时候，再加几个构建集群），扩展性（我们新加一个业务不需要改动之前的代码，毕竟我只是接收发送消息嘛）。rpc是同步的，它也可以构建集群，但是他是同步的，他不能像消息中间件那样，先给用户反馈，然后再处理一些不需要及时反馈的业务逻辑丶他的代码调用是耦合的，其最大的缺点就是当一端挂了，会导致其它的服务也不能用。

    看完我们发现，其实rpc好像很low嘛，为啥我们不用消息中间件来代替rpc呢？

    原因只有一个，rpc很快，由于是同步的，所以他很快，由于是消息中间件不需要立刻处理消息，所以消息中间件只能处理实时性没那么高的业务。看到这里大家应该都明白了，各司其职而已，没有什么好坏。

    对比完这俩大牛的产物，我想到刚入行的时候，刚开始想自学一门语言，所有推荐都是c，后来接触了一些行内人，发现做c的反而没有java多，又学了java，那时候学的都是皮毛，只知道java是c写的，脑子里面一直在思考一个问题，为啥有c还要开发java这门语言，是c不够强大吗，如果java比较厉害，为啥还有很多公司在做c呢，后来在工作中逐渐明白，c性能强大，但是确实不适合大型网站开发，渐渐的对c的崇拜减退，认识到没有垃圾的语言，只有垃圾的程序员，一个好的程序员必然能选择合适的技术，合适的语言去满足业务的需求。

    言归正传，说了这么多还是不知道适合做啥呢：异步处理，应用解耦，流量削峰，日志处理，消息通讯，大体就这么多吧。异步处理，应用解耦很简单，流量削峰主要是在类似秒杀抢购活动这种请求在同一时间疯狂怼过来的场景，由于流量暴增，应用很可能直接挂掉，如果这时候，先将请求怼到消息队列，假装我都给处理了，然后我后台去把限量的请求处理完，其它全部失败，日志处理的话现在很多公司都用kafka来做，确实牛逼，我们公司也是，消息通讯比如聊天室之类的。

    

常见的消息中间件比较

 

 

如果一般的业务系统要引入 MQ，怎么选型：

用户访问量在 ActiveMQ 的可承受范围内，而且确实主要是基于解耦和异步来用的，可以考虑 ActiveMQ，也比较贴近 Java 工程师的使用习惯，但是
ActiveMQ 现在停止维护了，同时 ActiveMQ 并发不高，所以业务量一定的情况下可以考虑使用。

 

 参考：https://ke.qq.com/course/287404