支持业务流量控制场景的讨论帖

[Yundi339]

诉求：
1、限速：防盗链的特殊场景，需要对连接做限速；或者是部署在用户的设备上，不希望请求把机器的带宽占用满，需要对请求做限速。

在nginx中，支持limit_rate、limit_rate_after。
limit_rate表示限速的速率；
limit_rate_after表示发送N个字节后再做限速；
补充：因为在nginx中一下子把速度降得太低，是有可能导致传输冻结，所以不用设计得非常严格，主要目的是限速，而不是精准限速。

2、通信过程的指标：设计限速的话，我认为需要获取请求、响应的大小、时延，也可以顺便补充通信过程的指标。

在nginx中，也是需要修改底层源码，才能拿到一些HTTP中更具体的数据信息，比如：请求/响应头大小、body大小、总大小，首包建连时延、首包时延、总时延、总传输大小、总传输时间、DNS解析时延等。

在连接结束阶段（包括请求断流、异常），获取这些指标变量，打印到访问日志中；在日志汇总后，与对端设备的日志做比较，可以确认日志是否有丢失，流量是否正确。

3、是否考虑引入redis做共享缓存
引入redis后，开辟多个数据区，分为全局共享缓存区，会话缓存区，独立模块的共享缓存区。
全局共享缓存区：存放全局变量变量。
会话缓存区：每个请求，都新建一个会话缓存区，在过程中把一些数据放入，比如日志，等待到请求完成，在日志阶段把数据取出，再释放缓存区。
独立模块的共享缓存区：与全局共享缓存区功能是一样的，目的是给开发者做业务拓展，又不希望占用全局缓存区的内存。比如异步的更新策略，redis也可以设置策略的过期时间。

[Barenboim]

Hello。感谢提需求，我们研究一下这几个问题。

如果已经使用上了，能否先star一下？

[Barenboim]

先回答一下第三个问题。

用Redis是不可能用的，如果需要保存整个服务session期间的数据，最标准的方法就是放在series context里面。当然，如果用户想自行保存一些数据到redis当然可以，直接用我们的redis task。如果你有兴趣倒是可以做一个外围的扩展。

有一些网络框架有session级别的内存池或buffer，但这些框架的特点是一个session都运行在同一个线程或进程，那么这个session级的buffer访问时可以无需加锁，以提升性能。

我们框架并不保证一个server的处理流程或者一个series的任务都运行在同一个线程上，不存在在同一个线程上分配释放内存的无锁优化。需要内存就直接malloc，内存池在我们的模式下并没有特别大的作用。我们测试过jemalloc或tcmalloc，结论也是和用标准库的malloc没有区别甚至更慢。

[Barenboim]

问题一，目前最简单的限流方式（http协议）只能用SSE，Server Sent Event了，wfrest项目里进行了封装，可以看一下：https://github.com/wfrest/wfrest 。自己需要写一些代码，控制数据的推送频率。

我们最核心层是可以控制读写速度的，但Communicator层基本上就只考虑高性能了。poller模块可以很方便的在写入部分数据的时候停止写操作，在必要的时刻重新放回去。但这些都是底层代码，workflow并没有把这些能力暴露给上层用户。

如果你想限流，看起来还是用SSE最简单。