If we have N route configuration data for the same route, the limit-req rank will be N * rate as each configuration has its own counter.
ZhengSong Tu <tzssanggl...@gmail.com> 于2021年7月6日周二 下午9:19写道： > > I think I see what you mean. When apisix has some data stored in a lua > shared dict, > the data structure of the current communication between > apisix and runner cannot be expressed, is that what you mean？ > > > we need a way to store route > > level data, which is useful for limit-req or other similar features. > > I still don't understand very well here. Can you use limit-req as an > example to describe exactly what is problem. > > > Zexuan Luo <spacewan...@apache.org> 于2021年7月6日周二 下午3:59写道： > > > Because APISIX is multiple worker architecture, the same route > > configuration will be sent multiple times as different PrepareConf > > Requests. > > > > When developing a plugin in the runner, we need a way to store route > > level data, which is useful for limit-req or other similar features. A > > natural way to do it is to store the data in the route configuration. > > However, as the PrepareConf Requests are redundant, we can't ensure > > the route configurations in the runner to be unique per route. > > > > Therefore, here I propose to add the idempotent key to the PrepareConf > > request. We already use a conf_key as the key to identify routes at > > the worker level. What we need to do is: > > 1. send this key via a new field "key" in the PrepareConf request to the > > runner. > > 2. before parsing the configuration, the runner needs to check if the > > request with the same key has been processed. If so, the runner > > returns the token of the previous request directly. > > > > What about your opinions? > >
