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
模型，当请求进入Ser ...
起源
Reactive Streams，翻译为反应式流，从名字上完全无法理解它的意义，像是两个硬凑在一起的词汇。
事实上，它并不是一个全新的事物，异步编程大家都有了解，Java里典型的多线程处理就是异步编程。而异步编程时，存在很多难题，比如典型的回调地狱(Callback Hell)，一层套一层的回调函数简直是个灾难，这里列出几个异步编程常见的问题：
超时、异常处理困难
难以重构
多个异步任务协同处理
为了解决异步编程过程中出现的种种难题，人们提出了各种各样方法来规避这些问题，这些方法称为反应式编程(Reactive Programming)，就像面向对象编程，函数式编程一样，反应式编程也是另一种编程范式。
反应式编程，本质上是对数据流或某种变化所作出的反应，但是这个变化什么时候发生是未知的，所以他是一种基于异步、回调的方式在处理问题。
Reactive Programming = Streams + Operations Streams
代表被处理的数据节点，Operations 代表那些异步处理
当越来越多的开发人员使用这种编程思想时，自然而然需要一套统一的规范。由此，20 ...
消息轨迹
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## ...
1 生产者
1.1 发送消息注意事项
1 Tags的使用
一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags(“TagA”)。
2 Keys的使用
每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突。
123// 订单Id String orderId = "20034568923546"; message.setKeys(orderId);
3 日志的打印
消息发送成功或者失败要打印消息日志，务必要打印SendResult和key字段。send消息方法只要不抛异常，就代表发送成功。发送成功会有多个状态，在sendResult里定义。以下对每个状态进行说明：
SEND ...
1 消息存储
消息存储是 RocketMQ 中最为复杂和最为重要的一部分，本节将分别从
RocketMQ 的消息存储整体架构、PageCache 与 Mmap 内存映射以及 RocketMQ
中两种不同的刷盘方式三方面来分别展开叙述。
1.1 消息存储整体架构
消息存储架构图中主要有下面三个跟消息存储相关的文件构成。 (1)
CommitLog：消息主体以及元数据的存储主体，存储 Producer
端写入的消息主体内容,消息内容不是定长的。单个文件大小默认 1G
，文件名长度为 20 位，左边补零，剩余为起始偏移量，比如
00000000000000000000 代表了第一个文件，起始偏移量为 0，文件大小为
1G=1073741824；当第一个文件写满了，第二个文件为
00000000001073741824，起始偏移量为
1073741824，以此类推。消息主要是顺序写入日志文件，当文件满了，写入下一个文件；
(2) ConsumeQueue：消息消费队列，引入的目的主要是提高消息消费的性能，由于
RocketMQ 是基于主题 topic
的订阅模式，消息消费是针对主题进行的，如果 ...
1 基本样例
在基本样例中我们提供如下的功能场景：
使用RocketMQ发送三种类型的消息：同步消息、异步消息和单向消息。其中前两种消息是可靠的，因为会有发送是否成功的应答。
使用RocketMQ来消费接收到的消息。
1.1 加入依赖：
maven:
12345<dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.3.0</version></dependency>
gradle
1compile 'org.apache.rocketmq:rocketmq-client:4.3.0'
1.2 消息发送
1、Producer端发送同步消息
这种可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知。
1234567891011121314151617181920212223public ...
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 权限定义的关键属性
字段
取值
含义
globalWhiteRemoteAddres ...
技术架构
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）启动 NameServer
123456### 首先启动Name Server$ nohup sh mqnamesrv &### 验证Name Server 是否启动成功$ tail -f ~/logs/rocketmqlogs/namesrv.logThe Name Server boot success...
2）启动 Broker
123456### 启动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模式
一个集群无S ...