RocketMQ-低调大师

RocketMQ

2018-06-12 602

一、背景

随着移动互联网的迅猛发展，各大互联网公司的体量、业务呈现指数式增长，在业务的反哺与逼迫下，分布式技术架构随之遍地开花，其中以SOA服务技术架构，微服务技术架构等为主的分布式架构如火如荼地发展。在这种大趋势之下，互联网企业也开始面临着数据采集，数据异构，系统整合等诸多问题，而CORBA、DCOM、RMI等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点，消息队列以异步处理，非阻塞调用的技术模型悄然登场，并迅速成为分布式架构的宠儿。

二、主流消息队列比较

以下表格摘取自apache rocketmq官方文档

阿里云消息队列上有另外一份对比：https://help.aliyun.com/document_detail/52577.html?spm=a2c4g.11186623.6.540.WVgch7

为何选择RocketMQ

消息不丢失【重点】
强大的技术团队，健壮的社区力量
采用Java编写实现，技术体系上更符合团队抉择
架构主轻量，组件无状态，可独立部署
高可用性，高吞吐量，性能好
经历多年阿里巴巴双十一挑战，不管是从业务复杂度，还是高流量并发都扛下来了，故而实践上毋庸置疑

三、简而言之RocketMQ架构

RocketMQ架构分为四个模块

1、生产者
2、消费者
3、namesrv
4、broker

3.1、namesrv

namesrv 是由阿里云RocketMQ中间件开发团队开发的基于服务注册发现功能的无状态组件，支持独立部署。namesrv在整个RocketMQ架构体系中，属于重中之重的组件，乃灵魂级组件，统筹全局，可谓之'一家之主'。上可撩得生产者靓妹，下可驾驭消费者御姐，亦可跟broker徐娘亲近。

那么它又是如何工作的呢？

1、生产者从namesrv中获取可用的broker地址，将消息发送至broker。
2、消费者从namesrv中获取可用的broker地址，从broker中拉去消息。
3、broker定时向naemsrv发送心跳信息，维护可用broker地址。

3.2、broker

broker是由阿里云RocketMQ中间件开发团队开发的基于高性能和低延迟的文件存储的无状态组件，支持独立部署。broker在整个RocketMQ架构体系中，同样是不可或缺的组件，乃核心级组件，可谓之‘持家之女’。负责存储所有的消息相关文件（包括消息文件，日志文件等等）。

3.3、生产者，消费者

生产者，消费者是我们再实际编码过程中直接接触到的，也是RocketMQ直接暴露给编码人员的API接口。生产者是勤勤恳恳的小码农，消费者是奢侈的败家女。

四、集群

4.1、namesrv 集群部署

RocketMQ如何做集群部署来提供系统的吞吐量，以及高可用性？从整体的架构上便可一眼看出，服务注册与发现组件namesrv可以独立部署，且namesrv与namesrv之间并无直接或间接的关联，双方不存在心跳检测，所以namesrv的之间不存在主备切换过程，如果其中一台namesrv宕机后，生产者消费者会直接从另一台namesrv中请求数据。但也正因为namesrv之间不存在心跳检测，主备切换，所以无法支持动态扩容，当机器宕机需要重新部署基于新的ip地址的namesrv需要更新生产者/消费者直连的namesrv地址。

4.2、broker 集群部署

broker支持主从架构

broker支持主从架构模式，但是并非是非常完善的主从架构，据说会在后续版本中优化。

主从架构模式为何会说不是完善的主从架构呢？说到主从架构模式，大家最熟悉，最耳熟能详的必然是MySQL的主从读写分离模式。主库支持writer，比如insert/update/delete等对数据产生修改的操作，而从库则只支持read操作，这种架构设计是基于目前互联网读多写少的业务模式。

那么RocketMQ又是提供了何种主从读写分离的模式呢？

1、目前它支持master写操作，只有当master读压力高于某个点（master消息拉取出现堆积时），才会将读压力转给salver。
2、无法做到主从切换，master宕机，salver只能提供消息消费，salver不会被选举为master来继续工作。如果master宕机，消息队列整个环境近乎瘫痪。

主从复制

决定rocketmq是否为master还是slaver，是从配置文件中读取设定的，如下：

public enum BrokerRole {
    ASYNC_MASTER,
    SYNC_MASTER,
    SLAVE;
}

ASYNC_MASTER：异步master，也就是新的消息存储时不需要等slave同步好；
SYNC_MASTER：同步master，新消息存现时需要等slave同步好(也就是返回的 Ack Offset >= 当前消息的CommitLog Offset;)
Slave:指该brokder为slaver；

当master启动是，是不会主动向slaver同步数据的。当slaver启动时，会上报当前的commitlog offset偏移值。一般会有两种情况，一种是slaver是全新的机器，commitlog是空的，传递maxPhyOffset=0。一种是master在使用过程中宕机了，经运维人员修复后重启成功，继续工作，master会根据slaver上报的maxPhyOffset的值继续同步。

多master多salver场景

如果用户体量稍微大一些，单master单slaver扛不住，可以采用多master/多slaver部署架构。

broker同步/异步刷盘

前文中我们提到，RocketMQ是基于高性能低延迟的文件储存，为了让用户在使用过程中可以按照自己对消息的丢失容忍程度与性能之间做一个选择，RocketMQ提供了两种方式刷盘方式，即同步刷盘/异步刷盘。顾名思义，同步刷盘指消息投放到broker之后，会在写入文件之后才返回成功，而异步刷盘则指消息投放broker成功后即可返回，同时启动另外的线程来存储消息。

同步刷盘的有点非常明显，可以保证消息可靠性，但是性能上无疑要略逊一筹。
异步刷盘反其道而行之，性能上肯定有了显著提高，但是消息可靠性却无所保证，因为在文件写入过程失败，无法通知生产者重试。

集群与容灾

从RocketMQ的架构设计中可以看到起优雅之处，组件均设计为无状态，所以它强大到可以任何扩展某个一个点。

比如当发现broker压力较大时，可独立扩展broker，只需要将broker地址注册到namesrv中即可。namesrv检测到来自broker的心跳检测后，会将broker信息保存在可用broker列表中。不管是消费者还是生产者，都会按照某个负载均衡算法去选择broker地址。当其中一台broker机器宕机后，namesrv不会顷刻间摘除心跳检测（多次无心跳检测才会摘除），而生产者/消费者亦会有轮询的方式，在数次请求无果后，会从可用列表中将该broker剔除掉，并将请求转发到另外的机器上。

优点：
1、任何组件节点支持集群部署扩展
2、同步刷盘保证数据不丢失，异步主从架构备份（数据可能会缺失）

弊端：
1、不支持master/salver选举，单master部署的情况下，master的宕机几乎是一件毁灭性的打击。
2、主从读写分离的缺陷

参考资料

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/
http://rocketmq.apache.org/docs/motivation/
https://help.aliyun.com/document_detail/52577.html?spm=a2c4g.11186623.6.540.WVgch7

微信关注我们

原文链接：https://yq.aliyun.com/articles/602084

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

如何才能真正的提高自己，成为一名出色的架构师？

一、广度：广度指的是架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要很深入的了解，但必须知道每种技术的“3W”： 1，Why：每种技术的由来，为什么会出现这种技术，这个技术是用来解决什么问题的？ 2，What：每种技术是什么？技术的基本组成部分是什么？ 3，Which：解决同一问题的相同技术各自的优缺点是什么，更适合哪种场景？比如，ORM框架（Hibernate与IBatis），MVC框架（Struts与SpringMVC），大数据技术（Hadoop与Spark）它们各自的优缺点是什么，只有清晰认识同一类型技术的优缺点，才能在技术选型时能够使用更加合理的技术。广度的学习方法：对各主流技术一一通过搜索引擎了解其3W的内容。二、高度：高度指的是架构师应具备对客观事物的“拔高”能力，能够从纷繁杂乱的信息中建立秩序，也就是我们一般所说的抽象能力。抽象能力包括： 1，业务抽象：能够软件和产品的复杂的需求中抽象核心业务实体，并给各业务实体建立合理的关系； 2，技术抽象：能够对复杂的技术架构进行分层抽象、服务抽象（微服务抽象）、组件抽象，并为各层和各服务之间的调用建立...

2018-06-13

621

Eureka简介和作用 Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装。主要负责完成微服务架构中的服务治理功能。服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和发现。 Eureka服务端 Eureka服务端，即服务注册中心。它同其他服务注册中心一样，支持高可用配置。依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。Eureka服务端支持集群模式部署，当集群中有分片发生故障的时候，Eureka会自动转入自我保护模式。它允许在分片发生故障的时候继续提供服务的发现和注册，当故障分配恢复时，集群中的其他分片会把他们的状态再次同步回来。集群中的的不同服务注册中心通过异步模式互相复制各自的状态，这也意味着在给定的时间点每个实例关于所有服务的状态可能存在不一致的现象。服务注册中心在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务...

2018-06-13

547

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。