RocketMQ入门知识点

1. 优先级: 

    1. 消息可以设置优先级
    2. 每个消息都是持久化的,所以如果按照优先级排序,开销会比较大,可以通过设置两个队列,一个优先级高,一个优先级低
    3. 可以使用不同优先级对应不同topic实现,这种实现方式对业务经度有损失
2. 有序: RocketMQ可以实现严格的保证先发送的消息先被消费
3. Filter过滤: 通过topic和tag细化过滤,也可以通过topic配合filterServer实现
4. 数据丢失问题: 

    1. 通过异步复制的方式保证单点故障(硬件损坏等)情况下数据基本不丢失
    2. 通过同步双写技术可以保证消息完全不丢失,Rocket从3.0开始支持同步双写
5. 重复消息问题: RocketMQ并没有实现这样:  可以避免发送重复消息 并且 在消费阶段  不允许消费同样的消息,要求在业务上实现这样的需求, 正常情况下很少会出现重复发送、消费情况，只有网络异常，Consumer启停等异常情况下会出现消息重复。
6. 实时性较高 
7. 至少消费一次  消费成功才ack消息
8. RocketMQ 不支持消息去重,要求业务上实现    
9. Broker的buffer满了怎么办CORBA Notification规定的 Broker的buffer满了怎么办

    1. RejectNewEvents 向producer返回对应的错误吗
    2. 按照特定策略丢弃已有消息

        1. 任何消息都可能, 默认这样配置
        2. 先进先出
        3. 后进先出
        4. 按照优先级
        5. 快要过期的消息先抛弃
10. 数据持久化: 其实RocketMQ没有内存buffer的概念,都是持久化到硬盘,  将内存buffer抽象成一个无线长度的队列,但是只存储三天内的数据
11. 消息回溯: Broker在向consumer成功投递消息后,消息仍然要保留,这种重新消费一般是按照时间维度,比如 consumer发生了系统故障,恢复后,需要重新消费之前一小时的消息,Boker提供支持,保留前面的消息,可以向前回溯,也可以向后回溯
12. 消息实时性: push(唤醒监听器,调用pull),pull(轮询获取broker)
13. 消息堆积
14. RocketMQ内存buffer到底存放在内存还是外部系统,或者更精确的说是在文件中,是否可配置?
15. 分布式事务
16. 定时消息: 

    1. 消息发送后,在特定的时间点或者等待特定的时间后 被消费;
    2. RocketMQ不支持任意时间经度,支持特定的level,如定时5s,10s,15s
    3. 如果要支持特定时间精度,在Broker层面,要做消息排序,如果涉及到持久化,性能损失较大
17. 消息重试: 导致消息重试的原因可能有:

    1. 由于消息本身的原因,如: 反序列化失败等最好的重试机制不知立即重试,因为和可能会失败,而是等待一段时间,比如: 10s后
    2. 下游依赖的应用不可用这种情况即使跳过词条消息,其他消息也同样报错,建议sleep 30s
18. 消息类型: 普通消息,有序消息,延迟消息
19. RocketMQ的特点   坑

    1. 如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。