「轻阅读」RocketMQ 在联想大数据中的应用简析

编写代码边撸猫 2019-06-21 17:38:10 ⋅ 301 阅读

http://casaveneziausa.com/lenovo-logo/


众所周知,RocketMQ 作为一款分布式、队列模型的消息中间件,具有以下特点:


  • 严格保证的消息顺序

  • 丰富的消息拉取模式

  • 高效的订阅者水平扩展能力

  • 实时的消息订阅机制

  • 亿级消息堆积能力

 

在复杂的应用场景中,将 RocketMQ 作为技术解耦的消息中间件,可以简化服务部署,以下是RocketMQ 在联想大数据的实践分享。



场景分析



在联想大数据中,应用 RocketMQ 的使用场景中经常会出现:异步请求,应用解耦和日志处理等场景情况。

 

  • 异步请求的业务处理:


经常遇到如下两种情况,一种为串行方式的业务流程(如图1),另一种为并行方式的业务流程(如图2)。

 

串行方式:在联想大数据解决方案中,针对顺序化、流程化的业务场景经常使用串行方式,实现RocketMQ 的技术解耦。如在某卷烟厂的解决方案中,针对制烟流程,将各个车间的处理流程做为独立的业务体创建一个Topic,对业务体中的各个处理阶段创建对应的Tag,并按照制烟流程顺序进行数据推送、清洗、业务处理及监控等,如下图1。



图1

 

并行方式:因业务的独立性,处理流程可分开进行处理,相互之间没有业务交叉。这种情况下,我们可以考虑使用并行方式对业务流程进行技术解耦。在联想大数据的相关解决方案中,针对某汽车的数据监控及相关画像的流程中,一部分是基础业务处理流程,另一部分是通过Bin Log 数据进行数据监控与消息提醒等附加处理业务流程。针对这种场景,我们在给客户进行程序部署时,便采用了并行方式,如图2。


图2


  • 错峰削谷


虽然联想商城的并发请求数不像淘宝、天猫、京东商城等互联网公司的并发请求数高,但在技术要求上经过多年的业务总结和摸索过程中,总结出适合联想的技术架构体系,以解决高并发数据带来的业务处理压力,并实现技术架构的高可用。


在应对高并发,处理高可用,保证不丢数据的前提下,我们使用RocketMQ做为应对特殊的业务处理流程的技术手段,需要在数据生产端承接瞬时高数据流量,在数据消费端平稳地将数据推送到下游业务线。

 

基本处理方法采用业界普遍的“漏斗”模式,如图3:


图3


  • 应用解耦


对于解耦架构来说,在联想物联网(IOT)的应用非常普遍。我们结合 StreamSets 进行二次开发,使用 StreamSets 通过界面上拖拽的方式制定数据流程,并在客户的解决方案中,说明RocketMQ区别于其他 MQ 组件的技术特点,针对客户的使用场景进行优化,使用 RocketMQ 进行解耦数据。

 

  • 日志处理


RocketMQ 的设计模式借鉴于 Kafka,且后者经常用于日志管理系统充当数据缓冲的角色。但

Kafka 过度依赖ZooKeeper,而 RockerMQ 则可实现无 ZooKeeper 部署,简化安装部署工作,所以,在联想大数据业务线和解决方案中,将 RocketMQ 应用于日志处理业务,逐渐增加RocketMQ的使用率。



应用实例



在联想大数据解决方案中,目前使用 RocketMQ 的实例也有不少,下面就举个实例说明一下,我们是如何使用的。

 

目前,在联想大数据部门,我主要负责数据流组件研发,并基于 StreamSets 开源组件进行定制化开发。在给客户的解决方案或现场实施中,我们可以通过在界面上的操作,设定好相关参数,便可设计出符合客户需求的数据流。如图4所示:



在每一个功能模块上,我们只需要设置若干必要的参数配置,也可以通过在文本框中编写更多的参数配置,在启动数据流时,即可加载这些配置,并实现数据流中各个功能模块的初始化、启动等等功能。

 

在这个实例中,我通过开发一个RocketMQ的功能模块,并设定一些基本参数,如 NameServers组、消费组名和 Topic,便可从 RocketMQ 服务端获取数据。

 

通过使用这个工具进行设计,大大降低了使用人员的学习门槛,而且也简化了开发流程。在对外的解决方案或项目交付过程中,极大地赢得了产品和交付工程师的认可,在各个 POI 项目中也PK 掉不少大厂公司。



优势



在此仅对比 Kafka,在实际应用中所具备的优势:


  • 架构差异,简化部署

 

在集群部署上,Kafka 的部署,必须依赖 ZooKeeper,并实现WaterMark的监控和Leader 的选举。而 RocketMQ 可实现不依赖 ZooKeeper的部署,大大降低使用门槛和学习成本。

 

Kafka 架构设计:



RocketMQ 架构设计,参考官网架构设计:



  • 性能优势

 

1、RocketMQ 可支持上万 Topic 的创建和使用,并且不会影响实例的整体性能及处理能力。


反观 Kafka,我们在使用 6000 左右的 Topic 时,整个集群性能突然下降,并有部分节点出现卡顿现象。

 

2、写入效率虽略低,但磁盘IO 不是瓶颈。


在实际测试过程中,同时写入Kafka 和RocketMQ 进行测试:


Kafka 的吞吐量高达15~17w/s,体现出较高的吞吐量。这主要取决于它的队列模式保证了写磁盘的过程是线性 IO,但此时 broker 磁盘 IO 已达瓶颈,写入响应已经出现略大的延时,有小部分数据出现重试写入。

 

RocketMQ 的吞吐量基本保证在11~12w/s,磁盘 IO 率虽已接近100%,但消息写入内存后即返回ack,由单独的线程专门做刷盘的操作,所有的消息均是顺序写文件。



在“坑”中摸爬滚打



在近些年的使用中,联想大数据逐渐在提高 RocketMQ 的使用率,不仅仅因为其具有区别于其他 MQ 消息中间件的优势,并且学习成本略低于 Kafka,更重要的是 RocketMQ 是阿里开源的消息组件,经过大量的生产实践,且在公司内部经历多年的版本更新,达到一个相当稳定的版本,而且各种学习资料也是相当丰富。

 

因此,在联想内部开始尝试 RocketMQ 作为各个业务线和解决方案中推荐使用的消息中间件。尽管在应用一种新的技术过程中会遇到各种各样的“坑”,但是在摸爬滚打的过程中我们痛苦并快乐着。

 

下面总结一下,我们遇到的一些比较有特点的“坑”及相应的解决方法:


坑一:🕳️

因consume offset不能与commitlog同时刷盘,导致offset不能对应数据。


因为consume offset 最终要索引到commit log,假如commit log 没有对应的数据,那么

consume queue 保存的这个offset也没有意义,所以最终就算有了这个offset,还是要根据commit log 来修复一遍,因为他们不是一起刷盘的。

 

所以,我们对源码进行了一定优化,将 consume offset 和commit log 通过一个事务进行刷盘,保证每一个 consume offset 与 commit log 一一对应。

 

坑二:🕳️

RocketMQ 的common包MixAll类中,默认指定WS使用8080端口,不能动态设置。


因为8080端口一般为Web应用使用端口,但当启动 RocketMQ 后,发现此端口被占用,导致某个Web应用程序不能正常启动。针对这个问题,我们在社区Jira中看到类似的Issue,并提供了相应的Bugfix方法。所以,我们在使用过程中,基于源码进行了二次开发,并在 RocketMQ 的配置文件中增加了对此端口的动态配置项。

 

在使用和学习过程中,还有很多的问题,我们仍处于学习和提高的阶段。



总结



通过对 RocketMQ 的学习和使用,联想大数据在对外项目和解决方案中,不仅仅可以使用 Kafka 作为消息中间件进行数据解耦,还能够借助 RocketMQ,进一步丰富应对不同使用场景的消息解决方案。

 

对于 RocketMQ,联想大数据还处于认识学习的过程中,目前我们更多地是在使用它,并没有完全研究透彻。希望以后积极参与到社区的讨论和研究中,贡献自己的一份力量。


本文不涉及公司专利,仅为本人工作之余对 RocketMQ 在业务上的技术梳理和总结。


 本文作者:

雷明,现就职于联想大数据团队。

---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦




全部评论: 0

    我有话说:

    阅读」如何构建可伸缩Web应用

    可伸缩性已经成为Web应用程序DNA!

    阅读」亿级用户分布式数据存储解决方案

    分布式数据库和分布式存储是分布式系统难度最、挑战最,也是最容易出问题地方。互联网公司只有解决分布式数据存储问题,才能支撑更多次亿级用户涌入。

    阅读」推荐系统信息增强小技巧

    实用推荐系统构建经验,如何进行信息增强。

    阅读」为什么做微服务设计时候需要DDD?

    设计蓝图里为什么没有看到DDD影子呢?

    阅读】为什么越来越多系统做服务化?

    脱离业务实际情况架构都是耍流氓,所以不是所有系统都必须服务化,也不要为了服务化而服务化。

    阅读」4服务注册发现技术对比

    架构设计 CAP 和 BASE 理论

    阅读」图文并茂带你了解分布式架构演进

    初始阶段架构初始阶段 小型系统 应用程序、数据库、文件等所有资源都一台服务器上通俗称LAMP

    阅读」“做完”和“做好”区别

    工作,“做完”和“做好”虽然仅一字之差,但前者只是完成了某项工作,而后者则不仅是完成了工作还有一个好

    阅读」轻松理解 Kubernetes 核心概念

    Kubernetes 迅速成为云环境软件部署和管理新标准。

    【实战解析】基于HBase数据存储京东应用场景

    作者就职于京东商城京麦平台组,从事京东商家开放平台相关开发工作。热爱技术,熟悉各种常用开源框架,有丰富大型分布式系统、高并发系统开发经验。热衷于对数据研究,对Hadoop、HBase以及

    阅读」移动端事件穿透原理与解决方案

    本文将带你了解事件穿透及如何实际项目选择合适方案解决事件穿透问题。

    阅读」大众点评是如何分表分库

    原大众点评订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想

    阅读」阿里云-开放平台高级技术家教你搭建微服务架构金刚利器

    孔凡勇,花名云狄,阿里云-开放平台高级技术家,对高并发、高性能、高可用、可伸缩分布式系统架构设计有丰富经验,Cloud Native坚定拥护者,坚守开发一线打磨匠艺架构师。

    阅读」Mysql调优你不得不知细节

    多数时候数据库会成为整个系统瓶颈

    阅读」美团开源QPS压测结果近5w/s分布式ID生成器leaf调试实战

    大型互联网项目ID要保证全局唯一,一般不数据库自带id自增了,一般都会用分布式id生成器。

    阅读」分布式事务四种解决方案,成长需要尝试

    分布式事务指事务操作位于不同节点上,需要保证事务 AICD 特性。

    阅读」如何设计移动端屏适配方案

    众多移动设备,前端开发人员如何不同屏幕大小,不同程度高清屏下去百分百还原设计稿,从来都不