I get, +1. Zexuan Luo <spacewan...@apache.org> 于2021年7月7日周三 上午8:55写道：
> 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? > > > >
