Какие два числа до 60 наименее кратны друг другу в прогрессии?

Question

[Al_Ko]

Есть два параллельно запущенные стенда, которые выгребают все возможные созданные любым из софтов этих стендов данные из одного источника. Хочу понять какие лучше задержки поставить, чтобы как можно реже была вероятность "race condition" при наибольшей частоте опроса в пределах 1-й, максимум 2–3 минут.

Например, вероятность того, что первое приложение заберёт данные созданные вторым, при опросах 6 секунд для первого и 7 секунд для второго ниже всего в пределе 10-и секунд, ведь пересечение происходит раз в 42 секунды (могу быть не прав, буду благодарен если поправите). Вероятной потерей данных в представленном вопросе можно пренебречь, ибо оба стенда тестовые. Запускаться приложения могут как одновременно, так и независимо.

Comments

[Евгений Самсонов]

Звучит как бред. Зачем это нужно?

[lonelymyp]

Евгений Самсонов, А не пофиг зачем? ну вот хочется ему.

Answer 1

[Wataru]

Не очень понятно, но вам, похоже, нужны такие числа, чтобы у них был максимальное наименьшее общее кратное (это то самое 42 для 6 и 7).

Из чисел до 60, очевидно, вам подходят числа 60 и 59 - у них нет общего делителя и НОК равен просто их произведению (3540). Если нужно строго меньше 60, то берите 58 и 59. Вообще, 2 максимальных числа в промежутке будут вашим ответом. У соседних чисел НОК всегда равен их произведению и произведение двух максимальных в отрезке будет самым большим возможным значением.

Comments

[Al_Ko]

Не совсем так, ведь помимо того, что числа или цифры должны иметь как можно большее общее кратное, также крайне желательно, чтобы частота их повторений была как можно выше.

Answer 2

[uvelichitel]

53 / 59

Comments

[lonelymyp]

А по какому принципу именно эти цифры выбирались?

[uvelichitel]

lonelymyp, они простые, гарантированно дадут наибольшее общее кратное.

[shurshur]

uvelichitel, они должны быть всего лишь взаимно просты, так что 58 и 59 дадут большее общее кратное.

Answer 3

[Griboks]

Надо просто избавиться от race condition.

Comments

[Al_Ko]

Вы готовы бадаться с разработчиками "Росреестра" и "Системы межведомственного электронного взаимодействия"? Лично у меня нет желания.

[Griboks]

Al_Ko, это же ваши стенды, значит и проблема ваша. У разработчиков есть отдельные "однопоточные" приложения, а вы их параллельно соединили.

[shurshur]

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

[Al_Ko]

У меня нет проблем, есть затруднение. К тому же я уже получил более или менее квалифицированный ответ.
Как и что соединять решаю не я, а то что без "мотивации" не могут предоставить "многопоточный" интеграционный тестовый стенд, останется на совести жлобствующих. На свою беду предположил, что хоть тут не отвечают в стиле "Капитана".

[shurshur]

Al_Ko, мне всё равно трудно всё это понять. У задачи есть более простое решение, причём максимально наивное и топорное. Можно просто одному делать запросы в нулевую секунду минуты, а второму - в 30 секунду минуты.

[Griboks]

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

[Griboks]

Al_Ko, p.s. чтобы не получать ответы в стиле капитана, не надо задавать вопросы в стиле:
я не могу решить уравнения k(x-y)⋮max(x,y) | k→max | x,y < 60 | k,x,y∈N.

[Al_Ko]

Griboks, бюджет не в моих руках, и как я уже написал выше решение принял не я. Насчёт заплатить кому-либо или нет, я никого не заставляю насильно на бесплатном сервисе отвечать или Вы предлагаете оплачивать Вам пустую болтовню?

[Al_Ko]

Griboks, я не могу его решить. Мало того, что написано в этой формуле я не понял. Забавно то, что "математики" любят решать эфимерные нерешаемые задачи, а когда их спрашиваешь: "Вот, прикладная задача, можно применить в жизни, пожалуйста, помоги решить и объясни". В ответ: "Ой, ну всё..." Интерактивные стороны, где одна из них говорит на понятным только ей лексиконе — это высокомерие. Если это тешит Ваше самолюбие, то пожалуйста.

[Al_Ko]

shurshur, это минимум 2 вероятных пересечения в минуту и частота запросов ниже чем у 6 и 7, как я уже указал.

[shurshur]

Al_Ko, нет, в моём варианте пересечений нет вообще никогда.

[Griboks]

Al_Ko,

Вы предлагаете оплачивать Вам пустую болтовню?

Просто не надо ждать решения вашей проблемы, а особенно предъявлять претензии к этой болтовне. Аналогично тому, как вы решаете проблему y, а не x.

я не могу его решить. Мало того, что написано в этой формуле я не понял.

Вы не можете адекватно объяснить, что хотите сделать, на словах и не можете это сделать на объективном универсальном языке математики. Что же вы ждёте увидеть в ответ?

Забавно то, что "математики" любят решать эфимерные нерешаемые задачи

Конечно, моя формула не совсем корректна, но она показывает идею, а главное, её можно вбить в калькулятор. Кроме того, вам достаточно подумать, чтобы и понять формулу, и лично её составить, и увидеть её практический смысл.

[Al_Ko]

Griboks, для тех кто в танке:
1. У меня нет возможности влиять или изменять поведение приложения контрагента. Я лишь могу делать со своей стороны вызовы и опросы к общему источнику с максимально допустимой частотой, чтобы по возможности как можно чаще обгонять и забирать данные себе. Считаю, что пытаться устранять race condition в рамках тестовых контуров и контуров разработки, где более одного контрагента — Сизифов труд.
2. Также могу повторить условия, возможно в более понятной для Вас условной математической логике, если человеческую Вы понять не в состоянии. Итак, требуется найти два числа удовлетворяющие условиям:
    a) оба этих числа являются делителями для целого числа значение которого стремится к максимально возможному показателю;
    в) при этом значение обоих частных при 60 поделённом на каждое из этих чисел также стремится к мaксимально возможному значению;
3. Если бы я мог понимать и хотел бы тратить время на формулы и изучение математики, то не спрашивал бы тут, а сам нашёл конечные значения.

P.s.: Для меня ответ был не на столько важен, ибо удовлетворяющие меня значения 6 и 7 секунд прекрасно себя зарекомендовали, а к экспертности так называемых здесь "экспертов" у меня возникли вопросы. Разделяю расхожее мнение, что эксперт от шарлотана отличается тем, что может на понятном даже 5 летнему ребёнку языке дать ответ на поставленный вопрос. Если не понял вопрос, то задать уточняющий, вместо того, чтобы демонстрировать своё эго.

[Al_Ko]

shurshur, извините, не сразу понял ответ, но у меня нет возможности оперировать нулевой секундой, ибо это для приложения будет означать, что не нужно вовсе делать вызовы или опросы. Также существует контрагент, которого нужно, по возможности обходить каждый раз по частоте вызовов и запросов. Ход мыслей верный, лично мне нравится больше чем ответ "эксперта". Мысль насчёт прокси отличная, только обмен идёт объёмными данными, боюсь будет часто погибать.

[shurshur]

Al_Ko, оперировать разными задержками тем более плохо, это ничего не решит. Поясню на примере. Пусть мы делаем задержки 6 и 7 секунд, тогда если запросы выполняются и обрабатываются моментально, то пересекаться они будут каждые 42 секунды. Вроде так, но если первый скачивает и обрабатывает данные 2 секунды, а второй - 1 секунду - то они будут делать запросы каждые 8 секунд.

Я бы начал с выяснения того, зачем вообще существуют два стенда. Если это резервирование (чтобы падение одного не вызывало падения сервиса), то это не так делается, тем более если конфликты не просто нежелательны, а недопустимы. Можно, например, сделать один из них пассивным резервом, который будет срабатывать при падении основного (обнаружение его падения - отдельная задача).

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

[Griboks]

Al_Ko, я вам ответил "избавиться от гонки", а вы мне написали, что я дебил и что я должен решить ваш чёрный ящик, потому что я эксперт. Это очень смешно))

Ну ладно, давайте объясню ещё раз как для пятилетнего, который не умеет думать и гуглить)

Race condition - ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода.

Следовательно, проблема - неопределённость очерёдности доступа, причина - ошибка архитектуры.
Как решить проблему: читаем дальше: википедия→способы решения.
Как избавиться от причины: построить правильную архитектуру.
Конкретнее сказать нельзя из-за неизвестности исходных данных.

Один из возможных вариантов архитектуры: поставить маршрутизатор потока данных, который дискретизирует запросы и возвращает уже синхронно закешированные данные, т.е. на вход получаем запросы на 6 и 6,5 секунде, а на выход выдаём результат 6 секунды, т.к. интервал дискретизации 1 секунда.

Но оптимальность и метод решения нужно принимать исходя из исходных данных, которых нет.

Если уж говорить про числа, то задача нерешаема, т.к. точка отсчёта не определена. Например, мы запускаем интервал 1 секунду, а через 0,5 секунды запускаем интервал 2 секунды. Тогда пересечения не произойдёт никогда при условии мгновенной обработки запроса. Опять нужно больше данных.