问题
RocketMQ
特点
- topic-queue-broker(master+slave)
- broker的mater和slave都是物理概念，同一个broker name时，master的broker id等于0，slave大于0；所以broker一般都是集群
- 不需要选举，这也是可以去zk的原因；剩下的topic/queue的路由，是由NameServer集群来做的
- master挂掉后，将会写到别的master，slave不会切换为master
架构组成
- Namesrv
- 存储所有broker信息，broker/topic/queue的对应关系
- NameSrv之间不通信
- 新增NameSrv怎么办：重启broker；在ngnix上面维护，让broker去那里取就可以了
- Broker
- 启动后跟所有的NameSrv保持长连接，定时发送心跳，并注册topic信息
- 所有topic数据写入一个文件，满1G后，新开文件；写完文件后，消息才算可用
- 提供pagecache（内核空间）加速读速率
- Slave只提供消费服务，不提供写服务
- 30秒与NameSrv心跳，超2分钟无心跳，会被NameSrv认为失效并调整对应关系；但NameSrv不会广播通知
- Producer
- 启动时跟一台NameSrv建立长连接，获取broker列表，然后发送消息
- 多个生产者实例可共用一个ID，组成该topic的生产者集群
- 30秒向broker发送心跳，超2分钟无心跳，会被broker断开
- broker宕机时，最迟需要30秒才能感知，期间发送失败后，会再重试2次；仍然失败就换下一个broker
- Consumer
- 启动时跟一台NameSrv建立长连接，获取broker列表，然后直连broker消费消息（pull模型）
- 多个消费者实例可共用一个ID，组成该topic的消费者集群
- 30秒向broker发送心跳，超2分钟无心跳，会被broker断开，并广播该组消费者实例，触发负载均衡
复制策略
- 异步复制，数据到达master即返回成功
- 同步复制，数据复制给所有slave后，才返回成功
刷盘策略
- 同步刷盘，需要将消息写入commitlog中，才返回成功
- 异步刷盘，消息进入内存即返回成功
kafka
特点
- topic-partition-broker（mater+slave）
- broker是物理概念，几个broker就是几个物理节点
- mater和slave是逻辑概念，一个broker可能既是topicA的master，也是topicB的slave
- 先由zk选出KafkaController；再由KafkaController决定每个partition的mater和slave
- 当master挂掉后，会有一个slave切换成master
MetaQ
Notify
发送事务消息
发送事务消息是一个二阶段过程，类似于数据库的二阶段提交。其中，包括两个过程：
应用发送Half消息到Notify Server。Notify Server收到Half消息后，不会投递到订阅者。
应用根据自身的事务执行情况，对Half消息进行Commit、Rollback、NOACTION（当前无法判决事务状态）。
Commit成功后，Notify Server会把消息投递到订阅者；Rollback则会把该消息删除，不会投递订阅者；
NOACTION，当前Half消息不处理，NotifyServer会定期（时间间隔不确定）发送Check到发送方应用上
检查对应的事务状态（默认检查7天，直到Commit或者Rollback，超过7天就当作Rollback处理）
注意：notify事务消息目前是异步提交，有可能出现提交成功并且投递到下游消费端以后，再次进行发送Check到发送方。
ActiveMQ
Apache ActiveMQ ™ is the most popular and powerful open source messaging and Integration Patterns server.
Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise
Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4.
