关于限流的技术方案和工程方案

今天在讨论一个限流的方案时，有一些想法记录下来：

需求：为了保护后端服务能力，需要在网关层做限流保护。这里的后端服务你可以理解为java容器，网关层你可以理解为前置的apache,nginx等服务。

一个技术方案是，增加一台中心存储的服务器，集群中所有nginx接受的请求都向这个中心存储汇报统计，并获取当前总请求数来判断本次请求是否要限制。这个是每个人都可以想到的方案。

但是考虑到稳定性问题，首先这个中心存储不能当机，如果是单机实现根本保证不了，如果是多机集群，那么作为中心存储的集群中所有机器的存储要同步，极大地影响实时性。同时每台nginx和中心存储服务的通讯要可靠，因为每一台nginx的上报都影响限流总数的计算。

所以这里的可靠性保证很难实现，我们修改了折衷的方案。把限流总量平均分配到每台nginx，如果限流10000，集群中有50台nginx服务器，那就每台限流200，这样做确实对精度影响，但实际上这个精度并没有到业务效果，10000目标实际限到9987还是10013,对后端的java容器性能影响并不明显。所有计算在nginx本地，实时性有了极大的保证。同时至少不会因为通讯问题产生统计不准。

对于集群的扩容和缩容，要动态重新计算每台nginx的限流量，否则扩容后总限流量就会增加了，但这种情况毕竟频率较低，属于一个静态的设置。相比集中存储的实时统计要可靠得多。

所以一些技术方案的决定要根据实施的可行性来选择，理论上的技术方案在实现时会有很多的折衷。