序
本文属于奈学教育rocketmq学习笔记。主讲老师陈东。
推荐在线观看，效果更好。因为不但讲理论，更从实践触发，踩过哪些坑。
1.目录
应用场景分析：
使用topic管理。概念理解。
例子：运营活动灵活，修改频繁。硬编码频繁修改不适用业务场景。
改进：使用mq统一订阅，抽取出专门的businesslogic 专门调用核心业务。提升系统的稳定性。
当然，老师额外讲了一个优化点：从这个点来看，的确是干货。
怎么实现一个连续5天登录送奖励的优化。
如果默认：每次登录都记录。那么记录很多，而且判断复杂。
优化1：想办法每天记录为一条。
优化2： 使用bimmap:每天1位，累计使用：位运算《1+1. 推荐16进制。
使用mq:解耦。各个业务订阅自己业务关注的topic。进而处理
三大场景： 业务解耦、异步调用、流量削峰
提升稳定性，但不是替代rpc,因为mq有全局性问题。
对于下单业务场景：
对于必须同步的场景：风控拦截、扣减库存是必须的rpc. 后面的非必要的同步，可以走异步mq。
秒杀的业务场景：
综合考虑：
该同步同步，该异步就异步，不能完全替代RPC。
影响点： 系统复杂度、可用性。排查问题难度：（根据mq能追踪到消费者）推荐调用链
这块是评估问题的点，就是权衡的维度。对于扩展思路很有用。
所谓成熟就是大厂发展了几年，坑都踩过了，渠去 哪里查资料。
老师额外提了下：顺序性如何实现，就是放到一个队列。单线程消费。是个取巧的实现。
上面的图：有主从master\slave, 有分布式：master1,master2 ,体现了灾备；
注册信息在nameserver。
这个图的nameserver独立的，所以没法选主。
刷盘指flush操作，真正落盘。
同步刷盘+同步双写。 最可靠。
topic-->broker->matser
commitlog 顺序追加写
怎么消费呢？有 dispatch线程读取后按照topic放到 consumerQueue，
队列里面存储的不是消息的内容，而是commitlog的offset,跟大小，这样就能找到对应的内容。
maxoffset用于写入新的。
consomeoffset 指消费的位置。
顺序写，随机读，如何保证消费性能？
kafka 顺序写，顺序读，所以性能很高。
切分，就是缩小随机读的范围。mmap 使用虚拟内存。ssd提升硬件性能。
生产方式：
同步、异步、单向
根据也无需求提供多种方式去选择。
push:实时性高，但是可能积压。
pull:实时性不好，可能有大量无效请求。
group内竞争，group间广播
前提：每个队列自能一个消费者，不能多个消费者都消费同一个队列。
这个图体现了上次分配结果对比，红色是没有的去掉，绿色是已经有的，白色是新分配的，最后生成新的队列。
新的问题：新加入的consumer如何实现？
老师的讲解还是不错的，快速入门，从总体上熟悉mq的架构，有个整体印象更容易串起来。