необходимость
Поскольку окончательная непротиворечивость данных не обеспечивается после разделения службы, что приводит к большому количеству бизнес-генераций.脏数据. Следовательно, необходимо добавить множество дополнительных сценариев для проверки и мониторинга данных, а также своевременно отправлять результаты мониторинга в DingTalk. В нормальных условиях ненормальных сообщений каждый день не так много, но каждый раз, когда добавляется новый сценарий, необходимо сканировать все исторические данные, и сообщения DingTalk будут отправляться очень часто.
Но ограничение частоты отправки робота DingTalk
20条/每分钟, если предел превышен, он вернетsend too fastСообщение об ошибке, отправьте его еще раз, только напрямую302и ограничьте отправку до 10 минут
Простое решение
Объединение сообщений в одно большое сообщение, Но сообщение не может быть слишком большим, фактический максимум составляет несколько тысяч слов, кажется, что данных нельзя отправить слишком много.
временный план
Простые решения все еще не могут решить проблему инициализации исторических данных и отправки большого количества сообщений. Из-за проблемы со временем первое временное решение, которое пришло на ум, заключалось в том, чтобы засыпать в течение 3 секунд в конце каждой передачи, чтобы лимит никогда не был превышен. Но есть большая проблема
- При нормальной работе эффективность скрипта снижается после отправки
окончательный план
Поскольку Redis поддерживает类型丰富,用法简单,效率高и другие функции, и многие компании будут использовать Redis без дополнительной установки.
Решение:
- Группа может подать заявку на шесть роботов и сохранить шесть токенов в массиве.
- Каждый раз, когда вы отправляете, проверяйте redis каждого токена по очереди.
sorted setпоследняя минута в сбореtimestampзаscopeколичество диапазонов - Если оно больше 18, запрашивается следующий токен, в противном случае это доступный токен.
Часть кода выглядит следующим образом:
В конце идет специальная обработка, если все 6 токенов недоступны, сохранить сообщение вsetВ сборнике срок действия 7 дней, что лучше, чем потеря сообщений, но это должно быть редко. Из-за 6 роботов 6 * 18 = 108 сообщений могут быть отправлены не более чем за одну минуту.Если это однопроцессный скрипт, интервал отправки между каждым выполнением составляет всего лишь~ 50 ms, в основном удовлетворяет текущие потребности.
Теперь можно смело ставить предыдущий код, предварительно отправив сообщениеsleep(3)удален