我们所说的流量控制，大家比较了解的一般分成两种算法，一种是漏桶算法，一种是令牌桶算法，我们这里并不去深究这两种算法的区别，这个可以在网上很容易找到两种算法的定义和算法描述，这两种液体流量定量控制系统策略都是来源于路由器的IP层流量控制的算法，我们从另外一个角度来看看液体流量定量控制系统，我们只借用这些算法的思想，从需求开始，自己一步一步设计一个液体流量定量控制系统系统。

首先，拿到一个流量控制的需求，需求是入口流量是5MB/s，但是峰值流量是100MB/s，出口的流量要控制在50MB/s以内，数据还不能丢弃，如何来实现这个系统。

第一感觉应该就是下图这个样子，中间有一个内存的FIFO队列，写入方不停的往这个队列里面写入数据，而另一端不停的读取这个FIFO，然后把流量分发到后端上去，这样就完成了数据不能丢弃这个需求，很像前面的那个消息队列，但是慢着，要是前端的写入流量一直保持在峰值的话，那么这内存也爆了，所以除了内存的FIFO以外，还需要一个文件的FIFO来保证在一直是峰值的情况下保证数据的不丢失，你要是问要是硬盘满了怎么办，那我只能呵呵了，当然，也不是没有解决办法，把服务设计成多机模式嘛，这不在本文的讨论范围内。
总之，按照上图的设计方法，基本可以满足数据不丢的情况了，对于FIFO的实现方式，可以有很多种，一种是自己开链表，两个指针一头一尾，一边写一边读，如果两边都是多线程的话，锁的设计需要特别注意，尽量减少锁的消耗。还有如果是使用想golang这样的带channel的语言，那么直接丢到channel里面也行，不过这样就是内存不太可控，如果某一个时间段上的数据包都特别大的话，容易造成整体内存的飙升，看具体场景和硬件资源吧，这里就不在赘述了，那么，接下来就考虑液体流量定量控制系统了。

既然需要流量控制，那么就是发送端在发送数据的时候得知道我现在这个数据能不能发，能发的话可以全发出去还是只能发一部分，最简单的办法就是有个整体的流量控制器，每次发送端发送数据的时候都去询问一下这里流量控制器，现在有多少配额，我能用多少，结构图如下图所示，发送端去询问流量控制器，然后拿到一个发送的配额，按照这个配额进行发送。