本文主要是介绍数据中心传输(5)：分流同质流量消除不确定性，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
数据中心传输(1)：云数据中心传输的出路
数据中心传输(2)：再谈数据中心网络传输
数据中心传输(3)：数据中心网络不是互联网
数据中心传输(4)：提升网络传输性能的误区
本文接着上面这些继续，希望这是倒数第二篇。
统计复用网络要用统计的方式去规划使用，将所有流量扔进一个只携带 buffer，没有任何 arq，不支持任何 qos 的网络就足以保证可用性，剩下还要做啥，无非是想让传输效率更高罢了。
吞吐是资源决定的，但抖动可以优化。抖动的根源是不同尺度的统计特征相互影响所致，隔离不同的统计尺度就行了。
统计的本质是概率，而概率是精确度的度量，概率是精确度量的反面。统计复用网络本质上在处理突发，而突发无论从频度还是长度而言都是概率，如果拥有这些概率的分布特征，自然就获得了更高精确度，处理突发就会高效。
如果通过数据采集分析获知数据中心有 20% 流量持续时间 1～5us，有 30% 流量持续时间 100～120us，有 30% 流量持续时间 2000us 以上，我们就有理由将这 3 类流量视为该数据中心特征流量，为其分别创建通道，并将符合这些特征的流量导入各自通道，最小化了方差。
我一再强调的按突发长度分流，分流，分流，记住这不是一个算法，不用纠结它怎么实现，它很简单后面会说，这个分流只是一个前置动作，把统计方差缩小，用同质交换弹性。
提高统计复用效率的本质在于消除不确定性，因材施教。
因材施教的反面是有教无类，哪个好？把学霸和学渣放在一个班级，试图因材施教，要怎么做？即使把资源倾向学霸，学渣还是会扰乱秩序而影响学霸，把资源分给学渣，也不会被有效利用。按照统计复用原则，他们就应该在一个班，但显然这极其低效，因为学霸和学渣之间没有共识，还是得按成绩分班才高效。
分流类似分班，目标是让同一通道流量对拥塞和丢包原因有共识，剩下的拥塞控制该怎么玩还怎么玩。既然要优化了，为啥还非要死守着把所有流量丢进一个网络这基本信条，试图通过一个万能的算法自适应对待它们呢。想因材施教，首先应把相似长度的流量丢进一个网络通道。
分流的核心主要是要把短突发流量和 capacity–searching 流量隔离，一旦隔离，短突发通道配置小带宽，大 buffer，capacity–searching 通道配置大带宽，小 buffer 就能解决大部分问题。若不隔离，不管配置多大带宽，多大 buffer 都还是乱糟糟，主要还是两类流量对 buffer 用法没有共识，短突发流量用 buffer 做暂存，而 capacity–searching 流量则借 buffer 做 probe(无论 aimd 还是 bbr)，二者的干扰后果可想而知，短突发流量瞬间占满 buffer 又瞬间腾出，capacity–searching 流量会因此抖动(无论主动退避还是丢包重传，或者仅仅被挤压)，而 capacity-searching 流量在统计意义上会持续稳定占据一定量 buffer(甚至 buffer 倾向于将满未满)，这将降低 buffer 吸收突发的能力而造成短突发丢包。
现有的 queuing policy，qos 倾向于包分类 enqueue，然后在 queue 间执行调度，而分类标准或主观或无法表示流量特征，多数仅仅根据业务重要性区分了优先级，太复杂等于无。
我们讨论操作系统调度时，作为统计复用系统，将所有进程，中断无差别扔到所有 cpu 上就能保证可用性，但我们也曾亲眼目睹小包中断是如何拖慢计算进程的，本质上也还是长任务和短任务对时间片没有共识，放在一起调度当然就有问题，任何调度策略都帮不了，那么显然就是设置优先级，绑核对不对，但为什么绑核效果并没那么好。优先级，绑核无异于网络中的优先级队列，资源预留，这破坏了统计复用基础，比较时兴的做法反而是 cgroup，想想为什么。
网络也需要一个 cgroup 的机制，至于流量如何往里面扔，那是另一个问题。
前提一定是获得数据中心的流量分布特征。业务在 send 的时候自己肯定知道长度，按 getlength 的结果打签即，或者干脆事先硬编码，getlength 在 1～5mtu 之间的 send 进入通道 1 用 homa，getlength 在 6～10mtu 的进入通道 2 用硬 pacing，而 1000～5000mtu 的则使用 cubic，bbr。总之还是要在传输频度和长度两个维度量化从 “紧急重要” 到 “不紧急不重要” 的流量类型。
短突发流量往往没有足够的时间来感知和响应拥塞而适应带宽，用足够大的 buffer 缓存它们就是最简单的方法，而大象流存活时间足够久，以至于有足够时间探测适应带宽并公平收敛，因此用较小的 buffer 就能满足。甚至只让 buffer 大小与通道流量长度负相关，根本不需要配置任何调度规则都能预期有好的效果。
别做弹性。流量不可预期的话根本做不到弹性自适应。觉得短突发通道大 buffer 在很长时间闲置浪费而为其它通道提供弹性，又拐回到了老路，引入的复杂性将直接抵消弹性的收益甚至会代偿。能固化资源的就别指望弹性自适应，随机环境中任何算法都斗不过概率，要弄巧成拙的，当然，有 kpi 压力的另说。
只有一个原则，网络是报文要尽快离开的地方，源目之间，专线最短，任何花哨的算法策略都是添堵，多想想怎么模拟专线。如果实在怕被开除，非得卷点啥，那就试试开大会，写论文，写写公众号吧。
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于数据中心传输(5)：分流同质流量消除不确定性的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
