What is the message middleware
Message ( the Message ) refers to the data transfer between applications. Message can be very simple, such as to contain the text string, the JSON like, of course, also be very complex, such as an embedded object.
Middleware message queue ( the Message Queue the Middleware, referred to as the MQ ) is the use of message passing efficient and reliable data exchange platform-independent, and for distributed system integration based data communication. By providing messaging and message queuing model, it can extend communication between processes in a distributed environment.
Currently there are many open source messaging middleware, there are more mainstream RabbitMQ, Kafka used to live , ActiveMQ, RocketMQ etc.
Classification messaging middleware
Push message model (the PUSH)
A message producer sends a message to the messaging service , the message delivery service and will push the message to message consumers.
Pull message model (the PULL)
Consumers request message service request message, the message from the messaging middleware producers pull this message.
Difference between the two:
model |
push |
pull |
Server |
Message storage Processing the request Push to save the track Save subscription relationship Consumers load balancing Centralized |
Message storage Processing the request distributed |
Client |
Processing the response and request |
Processing the response and request Save pull state, such as pull position offset offset Abnormalities messages under scratch |
real-time |
Better , after receiving the data can be sent immediately to the client |
Depending on the pull interval |
Consumers failure |
Consumers case of failure, the service end of the accumulation of messages, repeated push -consuming resources Save to push a lot of pressure trajectory |
Consumers failure of the server without affecting |
other |
The message has pushed for more control, to achieve diversification push mechanism, when the increase in the number of consumers of the time, push the pressure big performance ceiling, consumer differences in processing power, resulting in the accumulation of messages |
Need to implement a message on the client side filtering , waste of resources Requires coordination between different clients, do load balancing |
Messaging middleware application scenarios
l recoverability
Such as data replication across the room
l asynchronous communication
Users registered mail and SMS
l Traffic clipping
Such as big promotion spike activities
Another pressure test may also be used for performance
l order to ensure
For example, in the payment system, the processing order is important
l decoupling
For example: the electricity supplier under a single user system, the order system needs to notify the inventory system. The traditional approach is to order the system call interface inventory system; then if the order system fails, the inventory system will fail, resulting in the order failed, there has also a high degree of coupling, using messaging middleware; order entry system and inventory system can be separated individually designed, so that decoupling applications.
l log collection
Calculate PV, user behavior analysis
RocketMQ Profile
阿里的消息中间有很长的历史，从2007年的notify到2010年的Napoli，2011年升级后改为MetaQ，然后到2012年开始做RocketMQ，RocketMQ使用Java语言开发，于2016年开源。第一代的Notify主要使用了推模型，解决了事务消息；第二代的MetaQ主要使用了拉模型，解决了顺序消息和海量堆积的问题。RocketMQ基于长轮询的拉取方式，兼有两者的优点。
目前RocketMQ已经成为Apache顶级项目。在阿里内部，RocketMQ很好地服务了集团大大小小上千个应用，在每年的双11当天，有万亿级消息通过RocketMQ流转（在2017年双11当天，RocketMQ流转的线上消息达到了万亿级，峰值TPS达到5600万），在阿里大中台上也发挥了一定的作用。
RocketMQ的特点
l是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点
lProducer、Consumer、队列都可以分布式
l能够保证严格的消息顺序
l提供丰富的消息拉取模式
l高效的订阅者水平扩展能力
l实时的消息订阅机制
l亿级消息堆积能力
l较少的依赖
RocketMQ物理部署结构
如上图所示， RocketMQ的部署结构有以下特点：
lName Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
lBroker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
lProducer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
lConsumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
RocketMQ逻辑部署结构
如上图所示，RocketMQ的逻辑部署结构有Producer和Consumer两个特点。
Producer Group
用来表示一个发送消息应用，一个Producer Group下包含多个Producer实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个Producer对象。一个Producer Group可以发送多个Topic消息，Producer Group作用如下：
1. 标识一类Producer
2. 可以通过运维工具查询这个发送消息应用下有多个Producer实例
3. 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态。
Consumer Group
用来表示一个消费消息应用，一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象。一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。
常用RocketMQ集群模式
n单master模式
也就是只有一个master节点，称不上是集群，一旦这个master节点宕机，那么整个服务就不可用，适合个人学习使用。
n多Master模式
多个master节点组成集群，单个master节点宕机或者重启对应用没有影响。
【优点】所有模式中性能最高
【缺点】单个master节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
注意：使用同步刷盘可以保证消息不丢失，同时Topic相对应的queue应该分布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该topic的应用造成影响。
n多Master多slave异步复制模式
在多master模式的基础上，每个master节点都有至少一个对应的slave。master
节点可读可写，但是slave只能读不能写，类似于mysql的主备模式。
【优点】在master宕机时，消费者可以从slave读取消息，消息的实时性不会受影响，性能几乎和多master一样。
【缺点】使用异步复制的同步方式有可能会有消息丢失的问题。
n多Master多Slave同步复制双写模式
同多 master多slave异步复制模式类似，区别在于master和slave之间的数据同步方式。
【优点】同步双写的同步模式能保证数据不丢失。
【缺点】发送单个消息RT会略长，性能相比异步复制低10%左右。
【刷盘策略】同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
【同步方式】同步双写和异步复制（指的一组master和slave之间数据的同步）
注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低
集群模式总结
单Master无Slave（脆弱）
单master多Slave（单点故障就瘫痪，开源版本无主备切换功能）
多Master无Slave（无单点故障，prod环境常用）
多Master和Slave（无单点故障）