版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/axman/article/details/88575116
今天在讨论一个限流的方案时，有一些想法记录下来：
需求：为了保护后端服务能力，需要在网关层做限流保护。这里的后端服务你可以理解为java容器，网关层你可以理解为前置的apache,nginx等服务。
一个技术方案是，增加一台中心存储的服务器，集群中所有nginx接受的请求都向这个中心存储汇报统计，并获取当前总请求数来判断本次请求是否要限制。这个是每个人都可以想到的方案。
但是考虑到稳定性问题，首先这个中心存储不能当机，如果是单机实现根本保证不了，如果是多机集群，那么作为中心存储的集群中所有机器的存储要同步，极大地影响实时性。同时每台nginx和中心存储服务的通讯要可靠，因为每一台nginx的上报都影响限流总数的计算。
所以这里的可靠性保证很难实现，我们修改了折衷的方案。把限流总量平均分配到每台nginx，如果限流10000，集群中有50台nginx服务器，那就每台限流200，这样做确实对精度影响，但实际上这个精度并没有到业务效果，10000目标实际限到9987还是10013,对后端的java容器性能影响并不明显。所有计算在nginx本地，实时性有了极大的保证。同时至少不会因为通讯问题产生统计不准。
对于集群的扩容和缩容，要动态重新计算每台nginx的限流量，否则扩容后总限流量就会增加了，但这种情况毕竟频率较低，属于一个静态的设置。相比集中存储的实时统计要可靠得多。
所以一些技术方案的决定要根据实施的可行性来选择，理论上的技术方案在实现时会有很多的折衷。