demand

After servitization, the final consistency of data is not good, resulting in a lot of dirty data generated by services. Therefore, it is necessary to add a lot of extra scripts to check and monitor data, and the monitoring results need to be sent to the nail in time. Under normal circumstances, there are not many exception messages per day, but every time a new script is added and all historical data needs to be scanned, the spike message will be sent very frequently.

However, the frequency limit of the pin robot is 20 times per minute. If the limit is exceeded, an error message will be sent to send too Fast, and the next message will be sent directly and the limit is 10 minutes

Simple solution

Merge the message into one big message, but the message can’t be too big, actually a few thousand words at most like, the data is too big to send.

A temporary solution

The simple solution still does not solve the problem of initializing historical data and sending massive messages. Due to the time problem, the initial temporary solution was to sleep for 3 seconds at the end of each sending, which would never exceed the limit. But there are big problems

  • The script efficiency becomes low after being sent

Final plan

Because Redis supports a variety of types, is easy to use, and is efficient, many companies use Redis without additional installation. The solution is:

  1. A group can apply for up to six robots and keep the six tokens in an array
  2. Check the redis of each token each time it is sentsorted setSet to the last minutetimestamp 为 scopeNumber of ranges
  3. If the value is greater than 18, the next token is queried. Otherwise, the token is available

Part of the code is as follows:

The last special step, if all six tokens are unavailable, is to store the message in a set valid for 7 days, which is better than losing the message, but this should happen very rarely. Because 6 robots can send 6 * 18 = 108 messages in a minute at most, if it is a single-process script, the sending interval of each execution is only as small as ~ 50 ms, which can basically meet the current needs.

Now we can safely remove sleep(3) from the previous code after sending the message