浙江高速建设公司网站项目网上备案查询系统

不要将长流和短突发流(或者大象流和老鼠流)混部在一起，我建议用切片或虚通道将它们在全链路范围彻底隔离，而不仅仅在交换机上配合着大肆宣讲的高端包分类算法配置一些排队调度。

也不必扯泊松到达，帕累托分布，这些概念在论文建模时再见，单单理解为什么要按突发长度分流(即 burst 率)以及不分流有哪些坏处，初中几何知识就直观了。

设 n 条突发长度分别为 a1，a2，…，an 的流 f1，f2，…，fn 共享链路，每条流原子突发，不可从中切断，且 a1 + a2 + … + an = K，即这些流的突发长度均值为常数，问新流 fx 进入链路需要等待多久才能获得传输服务。

解释一下突发长度的原子性，纯为了处理方便而取了极端，另一个极端是所有流都以固定 pacing rate 时分复用链路，而现实处于两个极端之间。

先图示一下新流和 a1 … an 冲突的概率以及对应的平均等待时间：

整个问题如下图描述：

所以你看，让共享链路的流突发长度趋于相等，等待时间就能趋于最小，反过来如果它们之间差异很大，等待时间就趋于更长。

以上这个图解是我从经典教材习题变化而来的，原始问题表述之一是 “假设公共汽车平均 10 分钟到达一个特定公交车站，到达之间的时间呈 ‘指数分布’，若一个人在一随机时间到达公交车站，那么他等车时间的期望值是多少？”

本文对这问题不解释。

要深入分析流隔离时才需要建模，用指数分布还是帕累托分布只是一个选择，结论不会变。但现实数据用帕累托分布拟合得更好，因为网络流量存在自相似性，特别是数据中心内部的流量，往往存在长程依赖。

用排队论建模分析时，使不使帕累托分布不重要，但不建议用指数分布，因为流量之间存在依赖关联并非完全独立，所以基于独立事件的指数分布导出的结论往往有悖直觉，又得 battle。

在实践中，存在一种 sita(size-interval-task-assignment) 任务分配策略，背后就是我这里描述的按照突发长度分流，实践表明，它的平均排队时间(或队列长度)指标在绝大多数情况下优于 round-robin，大多数情况下优于 jsq(join-the- shortest-queue)。

p99 时延高往往是抖动而不是绝对时延高，所以你会发现 p50 并不高，甚至 p90 都不高。如果绝对时延高，p50 都能直接起飞，非常容易发现。绝对时延高往往是 bufferbloat 引发，也容易解决。困扰经理的是去抖动，而去抖动的方法就是分流，听我的没错。

隔离了长短流，肉眼可见的是抖动下降，但绝对排队时间的下降往往要用工具度量，它都不抖了，经理就觉得正常了，不会没事找事去关注队列长度，只有亲自度量才会发现时延绝对值也变低了，都是好事。

再说下隔离长度流后对长流的好处，长流可用非常简单(very simple)的拥塞控制算法对共享链路分时复用，而交换机简单 round-robin 甚至 random 即可，我此前的 inflight 守恒算法正当用武之地。

老问题，咋区分流的突发长短？别问我，业务自己知道，写代码时多写个 getlength 就不用天天跟系统 oncall 掰扯了，业务总得自己做点什么。网络侧要做的，要统计流突发长度分布，分布，单流 buffer 占用率分布，依照这些分布选取截止值。

引申一下，不光流突发长度由于长程依赖近似帕累托分布，流长度本身也应该近似帕累托分布，依这个推论，主机侧内存管理也可以分区池化来预防抖动。

大概也就这两个东西可圈可点，长短分流和 inflight 守恒算法。

浙江温州皮鞋湿，下雨进水不会胖。