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