作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
流控机制是用来避免消息发送速率过快而导致服务器难以支撑的情况。内存(memory)和磁盘(Disk space)达到阀值发出的警告相当于全局的流控,一旦触发会阻塞集群或者单机的所有连接(Connection),这一块我上一篇博文已经讲解过了,而本节的流控是针对单个连接(Connection)的。
单个连接流控(Per-connection flow control)描述的是当发布服务(或发布服务组)向队列发送消息的速度快于队列处理速度时发生的情况,即:queue队列到达了性能瓶颈。
一个连接触发流控时会处于flow的状态,也就意味着这个Connection的状态每秒在blocked和unblocked之间来回切换数次,这样可以将消息发送的速率控制在服务器能够支撑的范围之内。
处于flow状态的Connection和处于running状态的Connection并没有什么不同,这个状态只是告诉系统管理员相应的发送速率受限了;而对于客户端而言,它看到的只是服务器的带宽要比正常情况下小一些。
流控制不只是作用于Connection,同样作用域Channel和queue,从Connection到Channel,再到queue,最后是消息持久化存储形成一个完整的流控链,对于处于流控链中的任意进程,只要该进程阻塞,上游的进程必定全部阻塞。也就是说,如果某个进程达到性能瓶颈,必然导致上游所有的进程被阻塞;
流量控制组件
Connection、Channel、queue都有可能出现触发flow control state的情况,消息的流程如下:
NetWork -->Connection process -->Chnnel process --> Queue process -->Message store
信用证
RabbitMQ的流控制机制是基于信用证(Credit)的拥塞控制机制实现的;