奈学教育rocketmq学习笔记1

序

   本文属于奈学教育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的架构，有个整体印象更容易串起来。