задач которые нужно выполнить. Сейчас задачи складывают в очередь и воркеры их выполняют.
Очередь реализована как
lim = semaphore.NewWeighted(int64(workers))
--- // код воркера // ----
lim.Acquire(task.ctx, 1)
тут код воркера , а потом релиз семафора.
контекст задачи - это task.ctx = context.WithTimeout(.....)
----
все работает как нужно, вот только проблема в том, что задачи идут не в FIFO. и получается что задача которая зашла одной из первых может протухнуть так и не дождавшись выполнения.
можно реализовать на каналах, но тогда не будет работать контекст.
Какую либу можно посмотреть чтобы и FIFO было и контексты работали?
А чем канал не подходит?
запульнул я в канал 100 тыс задач, у каждой из них разный таймаут выполнения. например задача с индексом 50000 протухла по таймауту, мне нужно об этом узнать как можно скорее. А как это сделать в случае с каналами? ведь пока 49999 задач впереди нее не обработаются (предположим у них огромный таймаут), я об этом не узнаю
можно пояснить? не улавливаю мысль, точнее как это поможет узнать что задача протухла?
Ничем. Проблема в том, что у вас задачи протухают. И этот факт должен отслеживать продьюсер этих задач
поясните пожалуйста. Вот прилетел http запрос с заданиями. У каждого задания свой таймаут. Все задания добавились в очередь (как я выше описал), http запрос завершился. задачи выполняются и по результату записывают данные в мемкеш. в случае если задача отвалилась по таймауту в мемкеш тоже пишется информация об этом. Кто тут должен отслеживать?
что-то вы странное говорите или я вас не понимаю. memcache это просто хранилище, как оно что-то может отслеживать?
мемкеш - это кеш. Если вы туда даже что-то записали, не факт что вы прочитаете записанное.
так не гарантирует же он этого =)
Потому что кеш. Потому что когда у него кончится память - он начнёт играть в eviction и будет выкидывать содержимое.
аа в этом плане, ну это учтено. Задача живет несколько минут, кеш - десятки гигов. кеш переполняется за сутки.
Рестарт кеша - и привет
Допустим, задача протухла и мы тут же записали этот факт в мемкеш. А кто опрашивает эти сотни тысяч ключей в нём?
я же говорю, поведение memcache - это учтено. это не страшно.
Вы пытаетесь использовать инструмент не по назначению. которые не лучшим образом справляется со своей задачей. который дает пачку консернов. если на это есть причины - ради бога
опять вы за свое, ну давайте считать что там редис или mysql
Так и храните тогда все задачи в mysql :)
RPS идет 5-10к задач в секунду, mysql наверное будет тяжело :)) дешевле будет на memcache + семафорах. Сейчас выкручиваемся тем, что делаем очередь чуть меньше чем могут обработать воркеры, те воркеры всегда выбирают очередь до того как наступит таймаут.
Так проведите тесты, чтобы понять, будет ли тяжело или нет
тут мемкеш вызывает иногда вопросы (точнее вызывал), щас решили уже. а городить кластер mysql - ну это как-нить без меня. проще тогда scylla использовать
про вариант поднимать горутину с контекстом таймаута на каждую задачу не думали?
лучше уж ring buffer на слайсе и периодически по нему пробегаться и искать задачи что expired
подозреваю, бегать по слайсу накладнее будет, придётся ещё мутексами обмазывать
Зачем мьютексы тут?
спасибо за идею, возможно это поможет, если не найду ничего лучше
Обсуждают сегодня