【学海无涯】rocketMQ 学习笔记

rocketMq 借鉴了Kafka的思想
1.一个topic下的一个queue中的一个消息只能被一个消费者组中的一个消费者消息。一个消费者组可以消费多个queue（分区），一个分区不能被多个消费者组消费。
2. 一个broker就是一个mq实例，一个topic会在多个broker上有分片。分片的下一级是queue
3. msgId:生产者生成的id，offsetMsgId: broker生成, key：用户生成的业务id ,queueOffset 在queue中的第几个。
4. 生产者都是以生产者组的形式存在，可以给多个topic生产消息。
5. 消费者以消费者组的形式出现，一个消费者组只能对应一个topic。
6. 消费者组方便了负载均衡，这个负载均衡是指在queque级别上，将queque均匀的分配给消费者。
7. 消费者组也方便了容错，指一个消费者消费失败了，这个消息还可以被其它消费者消费。
8. 一个消费者组中的consume个数不能多余queue数量，如果超出，则超出的consumer不能工作，也就是说一个queque最多只能被一个消费者消费。
9. nameserver 是borker和topic的注册中心，支持borker的动态注册和发现。rocketMq 的前身 meteQ 没用nameserver 而是用的zookeeper。
10. nameserver 是无状态的，集群部署的，各个节点之间不进行通讯。borker 会轮询每个nameserver注册自己的信息。这样的优点是nameserver扩容简单，缺点是nameserver增加节点时必须在broker中重新配置nameserver的地址。
11. 路由剔除，nameserver 没10秒遍历下borker列表，发现上一次心跳消息超过了120秒，则剔除。
12. topic 路由信息变化时，nameserver 不会推给客户端，而是客户端默认每30秒从nameserver拉一次。这叫pull 模型。
13. push 模型需要维护长连接，pull模型实时性不好。
14. 长轮询：long polling 轮询并保持连接一段时间。
15. 客户端选择要连接的nameserver 时，先随机选一个，如果连接失败，就轮询逐个尝试。
16. broker分broker master 和 broker slave
17. 设置主从的方式是设置相同的broker name，设置不同的borderId，borderId为0的
18. 启动时， broker 和所有 nameserver 建立长连接 ，每30秒发心跳。生产者和一台nameserver保持长连接，获取一次broker地址和topic的queue的对应关系，在queue 级别通过负载均衡选中一个queue后，查到这个queue的路由信息，即ip+port ,然后发送消息。以后每30秒更新一次。
19. consumer是需要像nameserver发送心跳的，product 不用。
20. topic 的集群创建模式下，每个borker上的queue数量相同；borker 创建模式下，不一定相同。 
21. 发消息时自动创建的topic , 默认采用broker模式，默认每个broker4的queue。
22. 读写队列，读写队列在物理上是相同的，就是可以控