Разве wargaming ушли с python? Вроде там до сих пор python и c++

А вы точно не путаете питон с эликсир/эрлангом?

Добавил «раньше» потому что давно не общался/интересовался что там - вдруг все переписано. Раньше на конфах старался посещать их стенды - можно было найти технарей - потрындеть что у них там да как.

Щас не знаю что у них, танки на пайтоне были

корабли тоже на питоне

В 19 веке была бы дуэль ;))

Dmitry S, please, press the button below within the time amount specified, otherwise you will be kicked. Thank you! (60 sec)
Powered by Todorant

Чаще ACL эт обобщенная инфа, которая отдельно хранится. Вот как в spring например
ACL_SID
ACL_CLASS
ACL_OBJECT_IDENTITY
ACL_ENTRY

Добрый день. Мне с моим вопросом посоветовали этот чат, как профильный.
У меня есть 2 сервера, с keydb репликой между ними М-М. В одной из баз используются списки и через реплику я более менее обеспечиваю что данные есть на обоих нодах. У меня есть скрипт который должен монопольно доставать из списков данные и обрабатывать их. Вопрос в следующем - как я могу организовать работу скрипта на обоих нодах? Я так понимаю надо гдето как то маркировать какой скрипт сейчас продуктивный (и придется состояние скрипта отслеживать как то - сейчас все делается в рамках systemd на уровне работает/не работает) или как то организовывать параллельную работу обоих скриптов, что мне нравится меньше. Что можете посоветовать?

Да - я читал Таннебаума по распределенным системам, но хотелось бы полезных практических советов

что значит - работу скрипта на обоих нодах?

В том смысле что скрипт работает одновременно на обоих серверах, но в один момент времени только одна из копий скрипта имеет доступ к данным и обрабатывает их. И если чтото пошло не так - другой скрипт подхватил обработку данных. Ну или работают оба скрипта, но как то отдельные списки в keydb обрабатывают (имена, количество и тд плавающее, поэтому явно не получится задать)

Приходит в голову три варианта - а) сделать мьютекс, если в базе есть поддержка атомарных операций а-ля increment-and-get б) списки разделяются между скриптами по хешу имени, например. в) отдельный сервис гуляет по этим спискам, складывает задачи по их обработке в очередь, два скрипта вычитывают задачи из очереди.

Пока вижу только через марию на обоих нодах кэш сделать с локами - все же реплика там у меня больше доверия вызывает, том более что редис/кейдб не гарантируют доставку данных.

б - сразу не вариант. С ростом нагрузки оно будет сильно гулять. Плюс если скрипт, обрабатывающий очередь помер - другой должен узнать об этом и забрать себе его работу

один скрипт фигачит просто задачи на обработку в очередь непересекающиеся
и сколь угодно много других их обрабатывают

Все равно нужно 2 скрипта, разгребающих задания и задача возвращается к изначальной

почему ващу очередь может только один обрабатывать а не произвольное число?

так хоть 50
если задания не пересекающиеся в чем проблема

Потому что коллцентр - 2 звонка запихать одновременно операторам не получится при всем желании