HTTP协议HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP 简介HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web）服务器传输超文本到本地浏览器的传送协议。。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP 工作原理HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。
Web服务器根据接收到的请求后，向客户端发送响应信息。
HTTP默认端口号为80，但是你也可以改为8080或者其他端口。
HTTP三点注意事项：
HTTP是无连接： ...
Spring在 2017 年下半年迎来了Webflux，Webflux的出现填补了Spring在响应式编程上的空白，Webflux的响应式编程不仅仅是编程风格的改变，而且对于一系列的著名框架，都提供了响应式访问的开发包，比如Netty、Redis等等。 SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。
SpringCloud Zuul 的 IO 模型SpringCloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet IO处理模型。 大家知道，Servlet由Servlet Container进行生命周期管理。 Container启动时构造Servlet对象并调用Servlet init()进行初始化； Container关闭时调用Servlet Destory()销毁Servlet；Container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。 弊端：Servlet是一个简单的网络 IO 模型，当请求进入Serv ...
起源Reactive Streams，翻译为反应式流，从名字上完全无法理解它的意义，像是两个硬凑在一起的词汇。 事实上，它并不是一个全新的事物，异步编程大家都有了解，Java里典型的多线程处理就是异步编程。而异步编程时，存在很多难题，比如典型的回调地狱(Callback Hell)，一层套一层的回调函数简直是个灾难，这里列出几个异步编程常见的问题：
超时、异常处理困难
难以重构
多个异步任务协同处理
为了解决异步编程过程中出现的种种难题，人们提出了各种各样方法来规避这些问题，这些方法称为反应式编程(Reactive Programming)，就像面向对象编程，函数式编程一样，反应式编程也是另一种编程范式。 反应式编程，本质上是对数据流或某种变化所作出的反应，但是这个变化什么时候发生是未知的，所以他是一种基于异步、回调的方式在处理问题。
Reactive Programming = Streams + Operations Streams 代表被处理的数据节点，Operations 代表那些异步处理
当越来越多的开发人员使用这种编程思想时，自然而然需要一套统一的规范。由此，201 ...
消息轨迹
1. 消息轨迹数据关键属性Producer端
Consumer端
Broker端
生产实例信息
消费实例信息
消息的Topic
发送消息时间
投递时间,投递轮次
消息存储位置
消息是否发送成功
消息是否消费成功
消息的Key值
发送耗时
消费耗时
消息的Tag值
2. 支持消息轨迹集群部署2.1 Broker端配置文件这里贴出Broker端开启消息轨迹特性的properties配置文件内容：
123456789101112131415brokerClusterName=DefaultClusterbrokerName=broker-abrokerId=0deleteWhen=04fileReservedTime=48brokerRole=ASYNC_MASTERflushDiskType=ASYNC_FLUSHstorePathRootDir=/data/rocketmq/rootdir-a-mstorePathCommitLog=/data/rocketmq/commitlog-a-mautoCreateSubscriptionGroup=true## if msg tra ...
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 权限定义的关键属性
字段
取值
含义
globalWhiteRemoteAddresse ...
技术架构
RocketMQ架构上主要分为四部分，如上图所示:
Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。
NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：
Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的 ...
1 集群搭建1.1 单Master模式这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。
1）启动 NameServer123456### 首先启动Name Server$ nohup sh mqnamesrv &### 验证Name Server 是否启动成功$ tail -f ~/logs/rocketmqlogs/namesrv.logThe Name Server boot success...
2）启动 Broker123456### 启动Broker$ nohup sh bin/mqbroker -n localhost:9876 &### 验证Name Server 是否启动成功，例如Broker的IP为：192.168.1.2，且名称为broker-a$ tail -f ~/logs/rocketmqlogs/broker.log The broker[broker-a, 192.169.1.2:10911] boot success...
1.2 多Master模式一个集群无Slave，全 ...
Dledger快速搭建前言该文档主要介绍如何快速构建和部署基于 DLedger 的可以自动容灾切换的 RocketMQ 集群。
详细的新集群部署和旧集群升级指南请参考 部署指南。
1. 源码构建构建分为两个部分，需要先构建 DLedger，然后 构建 RocketMQ
1.1 构建 DLedger12345git clone https://github.com/openmessaging/openmessaging-storage-dledger.gitcd openmessaging-storage-dledgermvn clean install -DskipTests
1.2 构建 RocketMQ1234567git clone https://github.com/apache/rocketmq.gitcd rocketmqgit checkout -b store_with_dledger origin/store_with_dledgermvn -Prelease-all -DskipTests clean install -U
2. 快速部署在构建成功后
123c ...
1. 订阅与发布消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。
2. 消息顺序消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。
顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。
全局顺序对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景
分区顺序对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。适用场景： ...
1. 消息模型（Message Model）RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。
2. 消息生产者（Producer）负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
3. 消息消费者（Consumer）负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从 ...