rocketmq

架构设计 1 技术架构 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息

高可用性机制 RocketMQ分布式集群是通过Master和Slave的配合达到高可用的 Master和Slave的区别:Broker配置文件中,参数brokerId的值为0带包这个Broker是Master,大于0是Slave Master角色的Broker支持读和写,Slave角色的Broker仅支持读 消费高可用 有了主从结构之后,内部实现了自动切换,当Master不可用或繁忙的时候,会自动切换到Slave读,折旧达到了消费端的高可用 发送高可用 创建Topic时,把Topic的多个Message Queue创建在多个Broker组上,当一个Broker的Master不可用后,其他组的Master任然可用, 如果需要把Slave转换成Master,需要手动停止Slave角色的Broker,更改配置文件,用新的配置文件启动Broker 消息主从复制 如果一个Broker组有Master和Slave,消息需要从Master复制到Slave上,有同步和异步两个 复制方式 同步复制:等Master和Slave都写入成功后才反馈给客户端成功状态 异步复制:只要Master写入成功后就反馈给客户端成功的状态 配置:通过Broker配置文件中的brokerRole参数进行设置 Master有ASYNC_MASTER,SYNC_MASTER两个配置 Slave只有SLAVE 总结

zookeeper 部署 wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz tar zxf zookeeper-3.4.14.tar.gz cp -r zookeeper-3.4.14 /usr/local/zookeeper cd /usr/local/zookeeper/conf cp zoo_sample.cfg zoo.cfg vim zoo.cfg #添加如下内容 datadir=/usr/local/zookeeper/data/data dataLogDir=/usr/local/zookeeper/data/datalog mkdir -p /usr/local/zookeeper/data/data mkdir -p /usr/local/zookeeper/data/datalog cd ../bin/ ./zkServer.sh start #编辑启动文件 vim /usr/lib/systemd/system/zookeeper.service [Unit] Description=zookeeper After=network.target remote-fs.target nss-lookup.target

下载RocketMQ RocketMQ官网 根据版本，选择下载Binary的版本，我是下载的4.5.2的 部署RocketMQ 配置一下系统环境变量，和JDK的环境变量类似 变量名：ROCKETMQ_HOME 变量值：你本地下载的zip的解压路径 同时需要把新添加的变量，增加到系统变量 path 里面。配置 %ROCKETMQ_HOME%\bin; 配置到 path 里面即可。 启动name server 进入到RocketMQ的解压目录的bin目录，执行启动name server的命令： start mqnamesrv.cmd 可以把该启动命令编写一个简单的启动脚本：（该脚本放在解压出来的MQ同级目录） @echo off START %~dp0\rocketmq-all-4.5.2-bin-release\bin\mqnamesrv.cmd 启动broker 执行启动命令： start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true 或者新建可执行脚本：roketmq-mqbroker-start.bat @echo off START %~dp0\rocketmq-all-4.5.2-bin-release\bin\mqbroker.cmd -n 127.0.0.1:9876

权限控制 1.权限控制特性介绍 权限控制（ACL）主要为RocketMQ提供Topic资源级别的用户访问控制。用户在使用RocketMQ权限控制时，可以在Client客户端通过 RPCHook注入AccessKey和SecretKey签名；同时，将对应的权限控制属性（包括Topic访问权限、IP白名单和AccessKey和SecretKey签名等）设置在distribution/conf/plain_acl.yml的配置文件中。Broker端对AccessKey所拥有的权限进行校验，校验不过，抛出异常； ACL客户端可以参考： org.apache.rocketmq.example.simple 包下面的 AclClient 代码。 2. 权限控制的定义与属性值 2.1权限定义 对RocketMQ的Topic资源访问权限控制定义主要如下表所示，分为以下四种 权限 含义 DENY 拒绝 ANY PUB 或者 SUB 权限 PUB 发送权限 SUB 订阅权限 2.2 权限定义的关键属性 字段 取值 含义 globalWhiteRemoteAddresses *;192.168.*.*;192.168.0.1 全局IP白名单 accessKey 字符串 Access Key secretKey 字符串 Secret Key whiteRemoteAddress *;192.168.*.*

一、RocketMQ简介   RocketMQ作为一款纯 java 、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。 二、RocketMQ架构   如图所示为RocketMQ基本的部署结构，主要分为NameServer集群、Broker集群、Producer集群和Consumer集群四个部分。   Broker在启动的时候会去向NameServer注册并且定时发送心跳，Producer在启动的时候会到NameServer上去拉取Topic所属的Broker具体地址，然后向具体的Broker发送消息 1、NameServer   NameServer的作用是Broker的注册中心。   每个NameServer节点互相之间是独立的，没有任何信息交互，也就不存在任何的选主或者主从切换之类的问题，因此NameServer是很轻量级的。单个NameServer节点中存储了活跃的Broker列表（包括master和slave），这里活跃的定义是与NameServer保持有心跳。 2、Topic、Tag、Queue、GroupName   Topic 与 Tag 都是业务上用来归类的标识，区分在于 Topic 是一级分类，而 Tag 可以理解为是二级分类 1) Topic（话题）   Topic是生产者在发送消息和消费者在拉取消息的类别

前言 在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要对数据库进行拆分。 如：注册的用户数据，量大了后，就需要考虑分库分表 一旦数据库进行了分拆，那就出现很多头疼的问题，其中之一就是事务问题。那我们就来看看问题是怎么出现的？ 场景 先来上个图 进行数据拆分后，就类似上面的架构。 上图中我们就拿用户的数据进行举例，用户量一旦几千万时，就需要进行分库分表；上图就分了3个库，每个库都保证了高可用。 这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：用户A转账100元给用户B，这个业务比较简单，我们来分析一下里面具体的步骤： 1、用户A的账户先扣除100元 2、再把用户B的账户加100元 逻辑很简单，上伪代码 代码也是比较清晰的，感觉没有什么问题，那我们来分析一下问题在哪？ 问题 我们看到在转账业务中，有两步，一个是操作用户A扣钱，一个是操作用户B加钱 如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。 但是如果用户A的数据在集群A中，用户B在集群B中呢？因为他们不在同一个事务中；如用户A扣款成功，但用户B加钱失败了；那就坑了，数据不完整了。 类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。 那怎么解决

导语 | 近日，云+社区技术沙龙“腾讯开源技术”圆满落幕。本次沙龙邀请了多位腾讯技术专家围绕腾讯开源与各位开发者进行探讨，深度揭秘了腾讯开源项目TencentOS tiny、TubeMQ、Kona JDK、TARS以及MedicalNet。本文是对张国成老师演讲的整理。 本文要点： Message Queue 的原理和特点； TubeMQ相关实现原理及使用介绍； TubeMQ后续的发展和探讨。 一、Message Queue 简介 对于Message Queue(以下简称MQ)，Wiki百科上的定义指：不同进程之间或者相同进程不同线程之间的一种通讯方式，它是一种通讯方式。 那我们为什么要采用MQ呢？这是由MQ的特点来决定的。第一是因为它可以整合多个不同系统共同协作；第二是它可以解耦，进行数据传递和处理；第三是它可以做峰值的缓冲处理，我们平常接触到的像Kafka、RocketMQ、Pulsar等基本上也都有这样的特点。 那作为大数据场景下的MQ又有什么特点呢？从我个人的理解来说，就是 高吞吐低延时，系统尽可能地稳定，成本尽可能地低，协议也不需要特别地复杂，特别是水平扩展能力要尽可能的高。 因为像海量数据基本上都是到百亿、千亿、万亿，比方说我们自己的生产环境可能一个月、一年的时间就会翻一番，如果没有横向的扩展能力，系统就很容易出现各种问题。 二、TubeMQ实现原理及使用介绍 1

什么是消息队列？ 为什么要用消息队列？ 即，应用场景是什么，也就是用了有什么好处 解耦 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败 异步 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间 削峰／限流 避免流量过大导致应用系统挂掉的情况 使用消息队列需要注意什么？ 系统复杂性增加 如何保证消息队列是高可用，即做到集群高可用 如何保证消费的可靠性传输，即不丢消息 如何保证消息不被重复消费，即保证消费的幂等性 如何保证消息的顺序性，即保证数据的逻辑正确性 简单分析RocketMQ的原理 高可用 上架构 NameServer ： 维持心跳和提供Topic-Broker的关系数据，多个Namesrv之间相互没有通信，单台Namesrv宕机不影响其他Namesrv与集群；即使整个Namesrv集群宕机，已经正常工作的Producer，Consumer，Broker仍然能正常工作，但新起的Producer, Consumer，Broker就无法工作，nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高 Broker ： Broker与Namesrv的心跳机制：单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息 高可靠并发读写服务

Topic可以理解为对消息的分类，或者打标签。Topic与Message之间的关系是一对多的关系，即多个Message可以属于同一Topic，但是一个Message只能属于一个Topic。 Topic与Group的关系是多对多，即一个Topic可以由多个生产者发送消息，反过来一个生产者也可以发送多个Topic消息。一个Topic可以由多个消费者消费，反过来一个消费者可以消费多个Topic消息。 Message封装了消息内容本身，一个Message必须有一个Topic。一个Message可以打上标签或KV对，以进行更细的区分。实际开发中，一个系统只分配一个Topic，但是一个系统可能有多个任务，一个Topic显然粒度太大了，通过标签或KV对可以进行更细划分。 来源： https://www.cnblogs.com/stronger-brother/p/12163466.html