RocketMQ
RocketMQ是一款分布式、队列模型的消息中间件，具有以下特点：能够保证严格的消息顺序
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
专业术语
1.Producer：消息生产者，负责产生消息，一般有业务系统负责产生消息
2.Consumer:消息消费者，负责消费消息，一般是后台系统负责异步消费
3.PushConsumer：Consumer的一种，应用通常向Consumer注册一个Listener监听器，Consumer收到消息立刻回调Listener监听器
4.PullConsumer：Consumer的一种，应用通常主动调用Consumer的拉取消息方法从Broker拉消息，主动权由应用控制
5.Producer Group：一类Producer集合的名称，这类Producer通常发送一类消息，且发送逻辑一致
6.Consumer Group：一类Consumer集合的名称，这类Consumer通常消费一类消息，且消费逻辑一致
7.Broker：消息中转角色，负责储存消息，转发消息，一般也称为Server。在JMS规范中称为Provider
8.广播消费：一条消息被多个Consumer消费，即使这些Consumer属于同一个ConsumerGroup，消息也会被Consumer Group中的每个ConSumer都消费一次，广播消费中的Consumer Group概念可以认为在消息划分方面无意义。在CORBA Notification 规范中，消费方式都属于广播消费
9.集群消费：一个Consumer Group中的Consumer实例平均分摊消费消息。例如某个Topic有9条消息，其中一个Consumer Group有3个实例（可能是3个进程或者3台服务器），那么每个消息实例只消费其中的3条消息
10.顺序消息：消费消息的顺序要与发送消息的顺序一致，在RocketMQ中，主要指的是局部顺序，即一类消息为满足顺序性，必须Producer单线程顺序发送，且发送到同一队列，这样Consumer就可以按照Producer发送顺序去消费消息
11.普通顺序消息：顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Broker重启，由于队列总数发生变化，哈希取模后定位的队列会变化，产生短暂的消息不一致。如果业务能容忍在集群异常情况（如某个Broker重启或者宕机）下，消息短暂的乱序，使用普通顺序消息比较合适
12.严格顺序消息：顺序消息的一种，无论正常还是异常情况下都能保证顺序，但是牺牲了分布式Failover特性，即Broker集群中只要有一台机器不可用，则整个集群不可用，服务可用性大大降低。如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用
13.Message Queue：在RocketMQ中，所有消息队列都是持久化，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset来访问，Offset为Java Long类型，64位，理论上在100年内不会溢出，所有认为是无限长，另外队列中只保存最近几天的数据，之前的数据会按照过期时间来删除。也可以认为Message Queue是一个长度无限的数组，offset是下标
14.长轮询：客户端向服务器发送请求，服务端接到请求后Hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息之后，再次向服务器发送请求
优点：在无消息的情况下不会频繁的请求，耗费资源小
缺点：服务器Hold住连接会消耗资源，返回数据顺序无保证，难于维护管理
实例：WebQQ、Facebook IM
15.长连接：在页面嵌入一个隐藏的Iframe，将这个隐藏Iframe的src属性设置为对一个长连接的请求或是采用xhr请求，服务器端就源源不断的向客户端输入数据
优点：消息及时到达，不发无用请求，管理起来相对方便
缺点：服务器维护一个长连接会增加开销