rocketmq

Nameserver启动 nameserver指定输出日志位置，未指定则目志在当前目录下： 1nohup sh mqnamesrv > ~/logs/rocketmqlogs/namesrv.log 2>&1 & //ubuntu 下加 sudo 反而报错。最简单的命令：nohup sh mqnamesrv & 内存不足处理：nameserver 内存不足时修改 runserver.sh，测试管用JAVA_OPT="${JAVA_iOPT} -server -Xms512m -Xmx512m -Xmn256m -XX:PermSize=128m -XX:MaxPermSize=256m" 验证启动成功 jobs 或 jps //查看启动情况NamesrvStartup //nameserver 启动BrokerStartup //broker 启动nohup.out //未指定日志文件输出位置，则生成到执行 nohup 的当前目录下

NameServer 名字服务 实际作就是就一个注册中心 NameServer 作用在系统中肯定是做命名服务，服务治理方面的工作，功能应该是和zookeeper差不多早期的版本中，使用的是 Zookeeper 做为配置中心，改名 RocketMQ 后使用了自己开发的 NameServer。是一个几乎无状态的节点，可集群部署，节点之间无任何信息同步 两个主要做用 NameServer维护BrokerNameServer 维护了一份 Broker 的地址列表和 Broker 在启动的时候会去 NameServer 进行注册，会维护 Broker 的存活状态。 NameServer 维护TopicNameServer 维护了一份 Topic 和 Topic 对应队列的地址列表，Broker 每次发送的心跳过来的时候会把 Topic 信息带上。 producer、consumer 发送消息会去 NameServer 去拉取路由信息 NameServer 维护 Broker1.维护 Broker 信息broker 启动后，会连接到 NameServer，定期上报自身信息，NameSer ...

Broker作用：消息中转角色。负责存储消息，转发消息。一般也称为Server。在JMS规范中称为: Provider。 组成模式：两两一组，四个，两主两从。Master 干活，Slave 作为备节点，据说新版本会增加主备切换。 Broker 几个关键点： 负载均衡 可用性 1.负载均衡 一个topic分布在多个broker上，一个broker可以配置多个topic，它们是多对多的关系。 如果某个topic消息量很大，应该给它多配置几个队列，并且尽量多分布在不同broker上，减轻某个broker的压力。 topic消息量都比较均匀的情况下，如果某个broker上的队列越多，则该broker压力越大。 2.可用性由于消息分布在各个broker上，一旦某个broker宕机，则该broker上的消息读写都会受到影响。所以rocketmq提供了master/slave的结构，salve定时从master同步数据，如果master宕机，则slave提供消费服务，但是不能写入消息，此过程对应用透明，由rocketmq内部解决。

安装装的多了，都是零碎的片段，需要重新整理一个这一块东西。 包推荐使用 git 直接拉下来。没装 git 就 wget 去拉。需要 maven 来编译 rocketmq，实际上只要装好 maven 即可，其他不用操作 maven。 步骤 安装 JDK，配置 JAVA_HOME，yum 方式安装的JDK也要配轩JAVA_HOME。 安装 maven。因为编译需要 maven，先配置MAVEN_HOME，否则执行 sh install.sh 不起作用 默认最少4G内存，需要最少2G SWAP 内存，内存不够则修改默认内存小于本机内存，不然一直报错 内存不够的话，直接看下面的修改内存 测试安装环境 centOS 6.5 1G 内存 RocketMQ 3.4.6 编译和安装1sh install.sh //在 mq 的根目录 下 说明：安装完成后，因为 install.sh 脚本中创建 devenv 符号链接写错了目录，需要在RocketMQ目录下执行如下命令： 1rm -rf devenv 删除错误的 devenv 目录ln -s target/alibaba-rocketmq-b ...

架构设计分为：1.技术架构，2.部署架构 整体架构 技术架构 部署架构 技术架构学习一个技术，从最开始建立概念开始，先看架构图怎么理解这个图？这个图画出4个重要解色 和 消息的发送、保存、消费的大流程。 整个消息流转的过程中，有4个重要的角色负责： Producer NameServer BrokerServer Consumer Producer消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServerNameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后 ...

消息存储是RocketMQ中最为复杂和最为重要的一部分 消息存储整体架构消息存储是RocketMQ中最为复杂和最为重要的一部分，将分别从RocketMQ的消息存储整体架构、PageCache与Mmap内存映射以及RocketMQ中两种不同的刷盘方式三方面来分别展开叙述。 先看这个图，这个图看着复杂，但是多理解几遍历，不要着急跳过去 从这个图理梳理出几个关键词 CommitLog ConsumeQueue CommitLogOffset IndexFile producer send CommitLog和producer发送消息有关，ConsumeQueue和consumer消费端有关。 消息存储相关的文件消息都是存储在 Broker服务器上的以文件形式存储分：Producer端和Consumer端，消息查询也是通过Broker节点查询。 CommitLog 发送端消息主体---Producer端 CommitLog：消息真正的存储文件，所有消息都存储在 CommitLog 文件中。 CommitLog 文件是存放消息数据的地方，所有的消息都将存入到 CommitLog 文 ...