一、rocketmq 简介
rocketmq的是高性能、高可靠、高实时、分布式的。
结构：
name server集群：用来路由的，节点之间无任何信息同步。
broker集群：提供topic和queue服务的，可以有主从结构，节点间进行数据同步。Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server（消费者通过name server直到topic应该连哪一个brock），name server也定时向 Broker 发送心跳（为了保证name server始终直到哪些borker节点是存活的，然后通知消费者和生产者）。
Broker Master1 和 Broker Slave1 是主从结构，它们之间会进行数据同步，消费者同步写的时候，可以等待主从节点同步了消息之后才返回，保证数据不丢失，即使一个节点挂了，数据也不会丢失。
produce集群：生产者，Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。（一旦发现这个broker挂了，则连接另一个broker）
Producer 只能将消息发送到 Broker master（但是可以等待master同步消息到slaver，保证消息的高可用）
produce的集群目的是：标识一类Producer，可以通过运维工具查询这个发送消息应用下有多个Producer实例，发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态。
consumer集群：消费者，Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息（加大consumer的消费能力），订阅规则由Broker配置决定。
image.png
二、集群部署模式
有多种集群部署方式，根据业务量，选择。
如果消息很多，可以使用多个master，就好像分片一样，每个master数据不一样，如果保证消息高可用，可以每个master配一个slaver，master和slaver会数据同步，master挂了，slaver还可以使用，而且master和slaver都会被consumer消费，加快消费速度。
消息异步复制，消息发过去就不管了，所以，可能存在消息丢失，
消息同步复制，消息等到master复制到slaver后才往下走，保证消息的高可用。
三、rocketmq的特性
3.1 消息优先级。
由于RocketMQ所有消息都是持久化的，所以如果按照优先级来排序，开销会非常大，因此RocketMQ没有特意支持消息优先级，但是可以通过变通的方式实现类似功能，即单独配置一个优先级高的队列，和一个普通优先级的队列， 将不同优先级发送到不同队列即可。
3.2 消息顺序
RocketMQ可以严格的保证消息有序。
3.3 消息过滤
RocketMQ支持按照简单的Message Tag过滤，也支持按照Message Header、body进行过滤。
3.4 消息持久化
生产者通过同步发送消息的机制，master同步消息到slaver，同时，RocketMQ的队列都是持久化磁盘，数据定期清除。
3.5 消息高可用
不管是broker异常、正常关闭，操作系统挂了，机器坏了，由于持久化到磁盘，同步写机制和主从模式，可以保证完全的消息高可用。
对于，机器停了，但是没坏的情况，依赖磁盘持久化机制。
对于机器坏了，依赖同步写和主从模式。
异步读写可保证99%的消息不丢
3.6 消息延迟
RocketMQ使用长轮询Pull方式，可保证消息非常实时，消息实时性不低于Push。
3.7 应答机制
和其他mq一样，有应答机制
3.8 重复消息
mq要做到消息只发一次，需要巨大的开销，很难，所以，只能应用层控制。RocketMQ虽然不能严格保证不重复，但是正常情况下很少会出现重复发送、消费情况，只有网络异常，Consumer启停等异常情况下会出现消息重复。
3.9消息过期和存储
RocketMQ的队列都是持久化磁盘，数据定期清除。例如Broker只保存3天的消息，那么这个Buffer虽然长度无限，但是3天前的数据会被从队尾删除。
Broker在向Consumer投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。
RocketMQ支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。
3.10 定时消息
如果要支持任意的时间精度，在Broker层面，必须要做消息排序，如果再涉及到持久化，那么消息排序要不可避免的产生巨大性能开销。
RocketMQ支持定时消息，但是不支持任意时间精度，支持特定的level，例如定时5s，10s，1m等
3.11 消息重试。
顺序消息的重试,消息队列 RocketMQ 会自动不断进行消息重试（每次间隔时间为 1 秒）
四、总结
rocketmq定位是分布式的，大吞吐量的，所以，如果业务有这种需求，可以考虑这个mq，毕竟功能强大，性能也很好，经历过淘宝的大流量冲击，比较稳定，社区也还算活跃，又是java开发的，可以深入到源码。
但是毕竟是分布式的定位，维护成本，技术成本，相对要高一些，所以如果没有这么大的业务需求，还是可以选择用rabbitmq的，毕竟动泽10万级的吞吐量还是比较少的。
网友评论