debug

debug参照github, 不赘述

目录结构

启动情况的结构:

├── actionlog
├── checkpoint
└── messagelog

只生产的情况下的结构:

├── actionlog
├── checkpoint
│   └── message-checkpoint.00000000000000000228
├── consumerlog
│   └── order.changed
│       └── 00000000000000000000
└── messagelog
    └── 00000000000000000000

有消费的情况下: 目录结构

├── actionlog
│   └── 00000000000000000000
├── checkpoint
│   ├── action-checkpoint.00000000000000000747
│   └── message-checkpoint.00000000000000000684
├── consumerlog
│   └── order.changed
│       └── 00000000000000000000
├── messagelog
│   └── 00000000000000000000
└── pulllog
    └── snow4young-2.local@@9eb6e93294de88e6e8fa84468e4ebaf7
        └── [email protected]
            └── 00000000000000000000

messageLog: 所有消息的统一的存储文件 consumerLog: 每个消息队列的索引文件, 消息内容在messageLog中, consumerLog 只是索引记录 pullLog: 记录consumer已经ack的位置
actionLog: 所有的ack消息写入统一的文件 checkpoint: 记录日志行为, 作为快照, 机器crash之后进行恢复. 启动的时候, 会进行fix. action-checkpoint: actionLog的快照, 会定时清理 message-checkpoint: message的快照, 会定时清理

快照

SnapshotStore: action/message的快照存储层实现 CheckpointManager: action/message 快照的逻辑实现 通过实现了crash之后的恢复

延迟消息

基于时间轮实现的延时消息、定时消息.

扩容

扩容场景，1. consumer提高并行度 2. 机器负载高, 需要扩容broker

  • qmq中, consumer的并行度是和物理queue绑定的, 为了提高并行度, 只需要扩容物理queue的数量, 但是为了保证扩容的有序性, qmq提出了逻辑queue的概念, qmq中, 逻辑queue通过range方式映射到物理queue的, 为了保证后期的可扩容台特性, 逻辑queue建议大一些, 然后在mysql配置range映射到实际的物理queue
  • broker扩容, 创建好broker之后, 只需要在mysql中迁移queue和broker的关系就可以.
  • 无论是consumer提高并行度, 还是broker扩容, qmq都保证了有序性，通过版本号+命令消息 提供了保障.

高可用-机器挂了

Master-Slave模式, 手动切换 参照官方文章