rocketmq

1. PushConsumer 　　推，Broker主动向Consumer推消息，它Consumer的一种，应用通常向对象注册一个Listener接口，一旦接收到消息，Consumer对象立刻回调Linstener接口方法。Push方式里,consumer把轮询过程封装了,并注册MessageListener监听器,取到消息后,唤醒MessageListener的consumeMessage()来消费,对用户而言,感觉消息是被推送过来的。 　　缺点： 　　慢消费无疑是Push模式最大的致命伤,如果消费者的速度比发送者的速度慢很多,势必造成消息在broker的堆积。假设这些消息都是有用的无法丢弃的,消息就要一直在broker端保存。当然这还不是最致命的,最致命的是broker给consumer推送一堆consumer无法处理的消息,consumer不是reject就是error,然后来回踢皮球。所以push适合于没有慢消费情况的场景下 　　前面使用的所有示例中的Consuemr都是采用的push方式，所以这里就不在具体写示例代码了。 2. PullConsumer 　　拉，Consumer主动的从Broker拉取消息，主动权由应用控制，可以实现批量的消费消息。Pull方式里,取消息的过程需要用户自己写,首先通过打算消费的Topic拿到MessageQueue的集合

producer producer 1.启动流程 Producer如何感知要发送消息的broker即brokerAddrTable中的值是怎么获得的， 1. 发送消息的时候指定会指定topic，如果producer集合中没有会根据指定topic到namesrv获取topic发布信息TopicPublishInfo，并放入本地集合 2. 定时从namesrv更新topic路由信息， Producer与broker间的心跳 Producer定时发送心跳将producer信息（其实就是procduer的group）定时发送到， brokerAddrTable集合中列出的broker上去 Producer发送消息只发送到master的broker机器，在通过broker的主从复制机制拷贝到broker的slave上去 producer 2.如何发送消息 Producer轮询某topic下的所有队列的方式来实现发送方的负载均衡 1） Topic下的所有队列如何理解： 比如broker1, broker2, borker3三台broker机器都配置了Topic_A Broker1 的队列为queue0 , queue1 Broker2 的队列为queue0, queue2, queue3, Broker3 的队列为queue0 当然一般情况下的broker的配置都是一样的

RocketMQ初步应用架构理论 写给RocketMQ架构应用入门，内容涉及它的设计机理以及推到出来的应用注意事项，入门人员请看。 稍微涉及技术细节，留以我设计中间件时参考，将来整理深度文档时会抽取走，入门人员可以无视。 以下RocketMQ简称为RQ，理论部分采用版本为3.2.4，测试部分采用版本为3.2.6。 MQ的需求 我们对MQ的需求，相比JMS标准有几点要求更高： 1. 必须优美灵活地支持集群消费。 2. 尽量支持消息堆积。 3. 服务高可用性和消息可靠性。 4. 有起码的运维工具做集群管理和服务调整。 其他 提供顺序消息、事务、回溯等面向特别场景的功能更好，目前暂不需要。 RQ架构 RQ的基本组成包括nameserver、broker、producer、consumer四种节点，前两种构成服务端，后两种在客户端上。 还有其他辅助的进程，不提。 NameServer的基本概念 在没有NameServer的中间件中，服务端集群就由干活的broker组成 ，其中的实例分主从两种角色。那么客户端就要知道，需要连接到哪个地址的broker上去做事情，于是客户端就需要配置服务端机器的IP地址，如果服务端部署结构复杂，客户端的配置结构也挺复杂，更讨厌的是甚至可能需要客户端也得更新地址配置。由于有了两种思路的方案： 一是引入NameServer，负责提供地址

1、RocketMQ 简介： RocketMQ前身是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。 2、RocketMQ基本架构： 如图所示RocketMQ架构上主要分为四部分： Producer： 充当消息发布的角色，支持分布式集群方式部署。producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递。投递的过程支持快速失败并且低延迟。 Consumer: 充当消息消费者的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播形式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServer： NameServer是一个功能齐全的服务器，其角色类似dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能： Broker管理。NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活。 路由信息管理。每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息

假如有一个文章审核，通过后加积分的需求，审核是这个方法的主体，而加积分并不需要实时同步，这时，我们就可以将加积分的功能变为异步执行。 Spring实现异步的方法 1.AsyncRestTemplate https://blog.csdn.net/jiangchao858/article/details/86709750 2.@Async注解 https://spring.io/guides/gs/async-method/ 3.WebClient(Spring 5.0引入) https://docs.spring.io/spring/docs/5.1.8.RELEASE/spring-framework-reference/web-reactive.html#webflux-client 4.MQ 引入MQ后，生产者生产消息，然后将消息发送给MQ，消费者监听这个消息所属的topic，一旦接收到消息，就进行相关的处理。 MQ的适用场景 1.异步处理：不解释 2.流量削峰填谷：例如秒杀活动，可以用MQ控制参加人数，人数一旦达到阈值，就丢弃请求或跳转到错误页。防止应用被流量洪峰打死。 3.解耦微服务：假如A调用B，B挂了，虽然有sentinel可以保护A不被B拖死，但是依然无法正常返回，用MQ以后，A把消息发给MQ，就算B挂了也没事，后面B恢复正常会从MQ中拿消息处理，AB也解耦了。

概述 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷： 主要解决瞬时写压力大于应用服务能力导致消息丢失、系统崩溃等问题 系统解耦： 解决不同重要程度、不同能力级别系统之间依赖导致一死全死 提升性能： 当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统 蓄流压测： 线上有些链路不好压测，可以通过堆积一定量消息再放开来压测 RocketMQ Apache Alibaba RocketMQ 是一个消息中间件。消息中间件中有两个角色：消息生产者和消息消费者。RocketMQ 里同样有这两个概念，消息生产者负责创建消息并发送到 RocketMQ 服务器，RocketMQ 服务器会将消息持久化到磁盘，消息消费者从 RocketMQ 服务器拉取消息并提交给应用消费。 RocketMQ 特点 RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点： 支持严格的消息顺序 支持 Topic 与 Queue 两种模式 亿级消息堆积能力 比较友好的分布式特性 同时支持 Push 与 Pull 方式消费消息 历经多次天猫双十一海量消息考验 RocketMQ 优势 目前主流的 MQ 主要是 RocketMQ、kafka、RabbitMQ，其主要优势有： 支持事务型消息（消息发送和 DB 操作保持两方的最终一致性

前两天为了玩touchBar养宠物的小游戏，更新了系统，升级到了MacOs Catalina系统，升级之前mq启动正常，升级之后开始出现各种小问题，mq启动问题是其中之一 MQ启动必须要先运行一下source ~/.bash_profile才可以 重启终端，运行服务器的时候会显示“ERROR: Please set the JAVA_HOME variable in your environment, We need java(x64)!!!” 开始以为JDK坏了，查看JDK发现版本号没问题，也能用。 然后查了好多资料，很多人说在在～/.zshrc文件里加一句 source ~/.bash_profile就行， 但在~目录下没有找到这个文件，全局搜索了一下，在/private/etc下面找到的。 在文件的底部加上了两句话： # Enable my profile source ~/.bash_profile source /etc/profile .zshrc文件就是一个配置环境变量的文件 日志文件不存在 Cannot open file /dev/shm/mq_gc_pid1127.log 这个问题不是升级系统之后出现的，而且也没有什么影响，就是缺少文件夹，手动创建一个文件夹即可。 来源： CSDN 作者： 程心 链接： https://blog.csdn.net/qq

安装 安装maven： 1、wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.repo 获取yum源 2、sed -i s/\$releasever/6/g /etc/yum.repos.d/epel-apache-maven.repo 修改yum源文件，$releasever替换成6 3、yum install -y apache-maven 安装jdk1.8 （yum install java-1.8.0-openjdk*） 安装RocketMQ：(4G内存+1.5G虚存)512M虚存不够 安装时间25-30min左右 1、wget https://archive.apache.org/dist/rocketmq/4.6.0/rocketmq-all-4.6.0-source-release.zip 2、unzip rocketmq-all-4.6.0-source-release.zip 3、cd rocketmq-all-4.6.0-source-release 4、mvn -Prelease-all -DskipTests clean install -U 启动 环境变量 1、vim

1.报错信息如下 ： 失败原因，应该进入到编译后的bin目录上一层执行命令 nohup sh bin/namesrv & 我本地编译后的目录为： /software_data/rocketmq-all-4.5.2-source-release/distribution/target/rocketmq-4.5.2/rocketmq-4.5.2 而不是/software_data/rocketmq-all-4.5.2-source-release/distribution 来源： CSDN 作者： lvxiucai 链接： https://blog.csdn.net/lvxiucai/article/details/104186576

转载自：http://www.coin163.com/good/blog/mq.html 几种MQ产品说明： ZeroMQ : 扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码 RabbitMQ :结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护 ActiveMQ : 历史悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多）.，支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列. Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展 RocketMQ : 阿里巴巴的MQ中间件，在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费