分布式之消息队列复习精讲

为什么写这篇文章?博主有两位朋友分别是小A和小B:小A工作于传统软件行业(某社保局的软件外包公司)每天工作内容就是和产品聊聊需求改改业务逻辑。再不然就是和运营聊聊天写几个SQL生成下报表。又或者接到客服的通知某某功能故障了改改数据然后下班部署上线。每天过的都是这种生活技术零成长。小B工作于某国企虽然能接触到一些中间件技术。然而他只会订阅/发布消息。通俗点说就是调调API。对为什么使用这些中间件啊如何保证高可用啊没有充分的认识。庆幸的是两位朋友都很有上进心于是博主写这篇文章帮助他们复习一下关于消息队列中间件这块的要点复习要点本文大概围绕如下几点进行阐述:为什么使用消息队列使用消息队列有什么缺点?消息队列如何选型?如何保证消息队列是高可用的如何保证消息不被重复消费?如何保证消费的可靠性传输?如何保证消息的顺序性我们围绕以上七点进行阐述。需要说明一下本文不是《消息队列从入门到精通》这种课程因此只是提供一个复习思路而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人去找点消息队列的博客看看再看本文收获更大正文1、为什么要使用消息队列?分析:一个用消息队列的人不知道为啥用这就有点尴尬。没有复习这点很容易被问蒙然后就开始胡扯了。回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的但是只答三个主要的),即以下六个字:解耦、异步、削峰(1)解耦传统模式:传统模式的缺点系统间耦合性太强如上图所示系统A在代码中直接调用系统B和系统C的代码如果将来D系统接入系统A还需要修改代码过于麻烦中间件模式:中间件模式的的优点将消息写入消息队列需要消息的系统自己从消息队列中订阅从而系统A不需要做任何修改。(2)异步传统模式:传统模式的缺点一些非必要的业务逻辑以同步的方式运行太耗费时间。中间件模式:中间件模式的的优点将消息写入消息队列非必要的业务逻辑以异步的方式运行加快响应速度(3)削峰传统模式传统模式的缺点并发量大的时候所有的请求直接怼到数据库造成数据库连接异常中间件模式:中间件模式的的优点系统A慢慢的按照数据库能处理的并发量从消息队列中慢慢拉取消息。在生产中这个短暂的高峰期积压是允许的。2、使用了消息队列会有什么缺点?分析:一个使用了MQ的项目如果连这个问题都没有考虑过就把MQ引进去了那就给自己的项目带来了风险。我们引入一个技术要对这个技术的弊端有充分的认识才能做好预防。要记住不要给公司挖坑回答:回答也很容易从以下两个个角度来答系统可用性降低:你想啊本来其他系统只要运行好好的那你的系统就是正常的。现在你非要加个消息队列进去那消息队列挂了你的系统不是呵呵了。因此系统可用性降低系统复杂性增加:要多考虑很多方面的问题比如一致性问题、如何保证消息不被重复消费如何保证保证消息可靠传输。因此需要考虑的东西更多系统复杂性增大。但是我们该用还是要用的。3、消息队列如何选型?先说一下博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka对什么ZeroMQ等其他MQ没啥理解因此只能基于这四种MQ给出回答。分析:既然在项目中用了MQ肯定事先要对业界流行的MQ进行调研如果连每种MQ的优缺点都没了解清楚就拍脑袋依据喜好用了某种MQ还是给项目挖坑。如果面试官问:你为什么用这种MQ。你直接回答领导决定的。这种回答就很LOW了。还是那句话不要给公司挖坑。回答:首先咱先上ActiveMQ的社区看看该MQ的更新频率:span stylecolor:#333333span stylebackground-color:#ffffffcode classlanguage-mipsasmApache ActiveMQ span stylecolor:#8800005/span.span stylecolor:#88000015/span.span stylecolor:#8800003/span Release Christopher L. span stylecolor:#0000ffShannon /spanposted on Feb span stylecolor:#88000012/span, span stylecolor:#8800002018/span Apache ActiveMQ span stylecolor:#8800005/span.span stylecolor:#88000015/span.span stylecolor:#8800002/span Released Christopher L. span stylecolor:#0000ffShannon /spanposted on Oct span stylecolor:#88000023/span, span stylecolor:#8800002017/span Apache ActiveMQ span stylecolor:#8800005/span.span stylecolor:#88000015/span.span stylecolor:#8800000/span Released Christopher L. span stylecolor:#0000ffShannon /spanposted on span stylecolor:#0000ffJul /spanspan stylecolor:#88000006/span, span stylecolor:#8800002017/span 省略以下记录 ... /code/span/span我们可以看出ActiveMq几个月才发一次版本据说研究重心在他们的下一代产品Apollo。接下来我们再去RabbitMQ的社区去看一下,RabbitMQ的更新频率span stylecolor:#333333span stylebackground-color:#ffffffcode classlanguage-yamlspan stylecolor:#a31515RabbitMQ/span span stylecolor:#8800003.7/spanspan stylecolor:#880000.3/span span stylecolor:#a31515release/span span stylecolor:#88000030/span span stylecolor:#a31515January/span span stylecolor:#8800002018/span span stylecolor:#a31515RabbitMQ/span span stylecolor:#8800003.6/spanspan stylecolor:#880000.15/span span stylecolor:#a31515release/span span stylecolor:#88000017/span span stylecolor:#a31515January/span span stylecolor:#8800002018/span span stylecolor:#a31515RabbitMQ/span span stylecolor:#8800003.7/spanspan stylecolor:#880000.2/span span stylecolor:#a31515release23/span span stylecolor:#a31515December/span span stylecolor:#8800002017/span span stylecolor:#a31515RabbitMQ/span span stylecolor:#8800003.7/spanspan stylecolor:#880000.1/span span stylecolor:#a31515release21/span span stylecolor:#a31515December/span span stylecolor:#8800002017/span span stylecolor:#a31515省略以下记录/span span stylecolor:#a31515.../span /code/span/span我们可以看出RabbitMQ版本发布比ActiveMq频繁很多。至于RocketMQ和kafka就不带大家看了总之也比ActiveMQ活跃的多。详情可自行查阅。再来一个性能对比表特性ActiveMQRabbitMQRocketMQkafka开发语言javaerlangjavascala单机吞吐量万级万级10万级10万级时效性ms级us级ms级ms级以内可用性高(主从架构)高(主从架构)非常高(分布式架构)非常高(分布式架构)功能特性成熟的产品在很多公司得到应用有较多的文档各种协议支持较好基于erlang开发所以并发能力很强性能极其好延时很低;管理界面较丰富MQ功能比较完备扩展性佳只支持主要的MQ功能像一些消息查询消息回溯等功能没有提供毕竟是为大数据准备的在大数据领域应用广。综合上面的材料得出以下两点:(1)中小型软件公司建议选RabbitMQ.一方面erlang语言天生具备高并发的特性而且他的管理界面用起来十分方便。正所谓成也萧何败也萧何他的弊端也在这里虽然RabbitMQ是开源的然而国内有几个能定制化开发erlang的程序员呢所幸RabbitMQ的社区十分活跃可以解决开发过程中遇到的bug这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是一方面中小型软件公司不如互联网公司数据量没那么大选消息中间件应首选功能比较完备的所以kafka排除。不考虑rocketmq的原因是rocketmq是阿里出品如果阿里放弃维护rocketmq中小型公司一般抽不出人来进行rocketmq的定制化开发因此不推荐。(2)大型软件公司根据具体使用在rocketMq和kafka之间二选一。一方面大型软件公司具备足够的资金搭建分布式环境也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发毕竟国内有能力改JAVA源码的人还是相当多的。至于kafka根据业务场景选择如果有日志采集功能肯定是首选kafka了。具体该选哪个看使用场景。4、如何保证消息队列是高可用的分析:在第二点说过了引入消息队列后系统的可用性下降。在生产中没人使用单机模式的消息队列。因此作为一个合格的程序员应该对消息队列的高可用有很深刻的了解。如果面试的时候面试官问你们的消息中间件如何保证高可用的你的回答只是表明自己只会订阅和发布消息面试官就会怀疑你是不是只是自己搭着玩压根没在生产用过。请做一个爱思考会思考懂思考的程序员。回答:这问题其实要对消息队列的集群模式要有深刻了解才好回答。以rcoketMQ为例他的集群就有多master 模式、多master多slave异步复制模式、多 master多slave同步双写模式。多master多slave模式部署架构图(网上找的,偷个懒懒得画):其实博主第一眼看到这个图就觉得和kafka好像只是NameServer集群在kafka中是用zookeeper代替都是用来保存和发现master和slave用的。通信过程如下:Producer 与 NameServer集群中的其中一个节点随机选择建立长连接定期从 NameServer 获取 Topic 路由信息并向提供 Topic 服务的 Broker Master 建立长连接且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker master但是 Consumer 则不一样它同时和提供 Topic 服务的 Master 和 Slave建立长连接既可以从 Broker Master 订阅消息也可以从 Broker Slave 订阅消息。那么kafka呢,为了对比说明直接上kafka的拓补架构图(也是找的懒得画)如上图所示一个典型的Kafka集群中包含若干Producer可以是web前端产生的Page View或者是服务器日志系统CPU、Memory等若干brokerKafka支持水平扩展一般broker数量越多集群吞吐率越高