[Feature Request]: Support for Multiple API Keys with Random Selection

[G-TTYg]

Problem Description

Currently, the project likely only supports a single API key. When the API call limit is reached (e.g., hitting a rate limit), or if the single API key encounters an issue, the entire project can be affected, either failing to function correctly or experiencing reduced efficiency. This is particularly problematic in scenarios requiring frequent API calls where a single key's limitations become a bottleneck.

Solution Description

I would like the ability to configure multiple API keys within the project. When the project needs to make an API call, it should randomly select one of the configured keys to use. This would effectively distribute API call requests, preventing a single key from hitting the rate limit and improving the project's stability and availability.

Alternatives Considered

No response

Additional Context

No response

[Amery2010]

Previously, there was a need to implement too many keys, but this also led to unsolvable situations. For example, attachment uploads contain user information. For example, files uploaded by key A cannot be accessed by key B. If a random key is used, the attachment cannot be parsed.
If you want to solve this problem, you need to consider setting up a lightweight user system, which will be implemented in later versions.

[Amery2010]

Available in v1.6.0.
Use , to separate multiple keys, such as key1,key2,key3