|
|
@@ -1,2 +1,42 @@
|
|
|
# erlang_test
|
|
|
|
|
|
+Реализовать приложение для вызова событий по времени.
|
|
|
+
|
|
|
+Приложение должно работать с относительной и абсолютной величинами таймингов
|
|
|
+1. Текущее время + относительная часть (например 30 сек)
|
|
|
+2. Абсолютная (сработать, например, 01.01.2016)
|
|
|
+
|
|
|
+Приложение должно иметь протокол:
|
|
|
+1. для приема заявок. Входные параметры:
|
|
|
+ * ID задачи (varchar)
|
|
|
+ * ID процесса (integer)
|
|
|
+ * тип(статика/динамика)
|
|
|
+ * время(integer)
|
|
|
+2. для удаления событий. Входные параметры:
|
|
|
+ * ID задачи (varchar)
|
|
|
+ * ID процесса (integer)
|
|
|
+
|
|
|
+При приеме нового события с одним и тем же (ID задачи, ID процесса) прошлый нужно перезатирать.
|
|
|
+При удалении события вызываться при срабатывании time оно уже не должно.
|
|
|
+
|
|
|
+Общение с основным приложением будет на уровне очереди(rabbitMQ),
|
|
|
+при срабатывании события необходимо бросить в очередь rabbitMQ событие
|
|
|
+(в спецификации очереди есть параметр reply-to, который укажет в какую очередь отправить ответ),
|
|
|
+куда включить ID задачи и ID процесса (для примера {call_timer, ProcID, TaskID}).
|
|
|
+
|
|
|
+Для экономии памяти необходима гибридная схема:
|
|
|
+храним N задач по процессу, остальное в базе.
|
|
|
+Когда очередь задач по процессу иссякла, идем в базу и набираем еще порцию данных.
|
|
|
+
|
|
|
+Для уменьшения запросов в БД необходимо агрегировать запросы в базу
|
|
|
+(чтобы не случилось так, что 1000 обработчиков захотели получить данные в единицу времени).
|
|
|
+
|
|
|
+Приложение должно с легкостью управляться с нагрузкой -
|
|
|
+20тысяч приемов новых заявок и 20 тысяч удалений в секунду одновременно.
|
|
|
+Время срабатывания события критично до секунды.
|
|
|
+
|
|
|
+Выполнять задание в репозитории типа github. Использовать тесты.
|
|
|
+
|
|
|
+
|
|
|
+Задание можно полностью не сделать. Важен подход и оформление кода.
|
|
|
+
|
221V