I agree with the removal of this plugin. The uuid algorithm is sufficient for now. The snowflake algorithm does not provide additional benefits and leads to possible business disruptions. If the user insists on using this algorithm, as it is only a plugin, it is relatively easy to upgrade up from the old version.
On Thu, Jun 15, 2023 at 12:38 AM LI Fabrice <yihao.li...@hotmail.com> wrote: > Hi, > > First of all, that will be a breaking change. In addition, if the user is > using the old version and then updates to the new version, it is necessary > to verify and explain the change of request-id plugin. Finally, can you > give some info of the request-id plugin when etcd is unavailable? > > Fabriceli > https://github.com/Fabriceli > > > 2023年6月14日 16:55，Ling Samuel <lingsamuelgr...@gmail.com> 写道： > > > > *Background* > > > > The snowflake algorithm in the request-id plugin introduces an > unnecessary > > dependency on etcd. This will significantly affect APISIX performance if > > etcd is unavailable. > > > > Snowflake depends on a unique worker_id, which is acquired from etcd. If > > etcd fails, each request with request-id plugin that uses the snowflake > > algorithm needs to try to retrieve a unique worker_id. This has a > > significant impact on performance. > > > > In addition, the data plane may not have access to etcd. This limitation > > would make the algorithm completely unusable. > > > > In the request-id scenario, uuid can generate a globally unique id, which > > is enough for this case. > > > > So I suggest removing this algorithm from the request-id plugin. There > are > > some benefits here: > > > > 1. reduce code complexity and the maintenance burden > > 2. remove dependency on etcd on the data plane > > 3. reduce the potential instability of request-id that may affect user > > business > >
