Есть пока чисто теоретическая задача. Не знаю как реализовать лучше сам алгоритм работы. Некая программа должна обращаться на один из трёх серверов в порядке очерёдности. То есть если с первым что-то не так, то ко второму, если и с ним проблема, то к третьему. Если с первым всё нормально, то будет работать только с ним. Функция простая, будет передавать номер (назовём пин), и получать ответ можно ли использовать или он был использован уже. Список пинов будет в виде файла, напротив каждого пина будет флаг использования, 0 или 1. Смысл в том, что бы синхронизировать всё так, что бы пин можно было использовать только один раз и серверы если в рабочем состоянии синхронизировали список. То есть при проверке пина должна производится сверка с двумя другими серверами на предмет его активности. Как мне кажется это возможно только при наличии хотя бы двух работающих серверов в данный момент.
Хотелось бы услышать советы по организации подобного. В голове крутится примерный алгоритм работы, но окончательно не соображу. На серверах средствами PHP планирую реализовать. На данный момент не интересует безопасность и рациональность использования средств, нагрузка небольшая, одновременное обращение маловероятно, акцент делаю на надёжность (доступность хотя бы одного из 3-х серверов) и актуальность информации (что бы нельзя было использовать пин дважды).
Буду благодарен за ваше видение подобного алгоритма как можно конкретней, типа программа обратилась к серверу1, он обратился к серверу2, третий получив что-то подтвердил первому и т.п.

| Сообщение посчитали полезным:

судя по описанию проблемы вижу опыта администрирования серверов и знания модели OSI нет (как я понял, если не так-поправь, ты собрался на первом сервере подымать апа4, там делать редирект на другой сервер, если же какой-то не раболтает то и дальше сверка невозможна). советую если не юзать кластер, то хотя бы не делать все настолько уж по-прикладному (при больших нагрузках веб-сервера лягут). как вариант поднять фряху, там nginx, запоинтить на нее домены трех серверов и "отдавать" по заданому правилу в зависимости от нагрузок один из трех серверов. а там уже можешь ставить себе хоть апач, нагрузки уже на уровне конечной машины будут на минимуме

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

| Сообщение посчитали полезным:

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

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

| Сообщение посчитали полезным:

Пусть у нас будет множество серверов данных (data storage server). Хранят информацию о пинах и блокировках. Нумеруешь их 0,1... Чем меньше номер, тем выше приоритет сервера.
И множество гейтов (user gates). Эти все равноправные. К ним будет обращаться софт для получения ПИНа.
Программа обращается к UG (если не отвечает - к следующему). UG обращается к DSS в порядке приоритета.
Самое сложное в этой схеме - синхронизация и восстановление после отказа.
Синхронизаця push методом. DSS[x] ищет первый отвечающий DSS[x+y], y=1..n. Переводит его в заблокированное состояние и обновляет данные. Попутно повышает его приоритет, если в цепочке есть выпавшие узлы.
Восстановление. Очнувшийся DSS подключается в конец цепочки, ищет первый отвечающий DSS[x-y], y=1..m и посылает ему запрос на синхронизацию.

Остаются чисто технические моменты оптимизации процесса и организации транзакций.

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

-----
старый пень

| Сообщение посчитали полезным:

А нельзя ли сделать один Frontend, который точно не упадет. И пусть к нему обращаются пользователи. А уже он будет осуществлять балансировку нагрузки и репликацию данных.
Например для PostgeSQL есть Pgpool-II, который с этой задачей вполне справится.

| Сообщение посчитали полезным:

Я планировал сделать всё максимально просто, на коленке, средствами PHP, без баз даже. Дело в том, что нагрузка будет никакая, врядле параллельно будет несколько обращений, в списке действующих пинов будет ну сотня максимум. Знаний и средств на решения о которых было написано выше у меня нет. Я думаю, всё это можно сделать на простых и недорогих хостингах, резервные вообще хоть на бесплатных можно было бы. Алгоритм сочинил примерно такой:
Каждый сервер хранит общий список существующих пинов, а номера (индекс в списке или номер строки) использованных хранятся в другом списке. Когда приходит запрос пина на один из серверов скрипт получает списки номеров использованных пинов с двух других серверов при наличии доступа к ним. Списки объединяются и сортируются с удалением дубликатов. Далее если порядковый номер пина присутствует в этом списке, то он не активен и уже был использован, если его нет, то его номер заносится в общий список использованных. Затем производится сверка всех использованных номеров на каждом из резервных серверах с общим списком, находятся уникальные которых нет в списке и посылается то, что нужно добавить до полной картины, так же и со вторым резервным. Таким образом если предположить, что в момент проверки пина всегда работают как минимум 2 из 3-х серверов, смею думать, что информация всегда будет актуальной. Хотелось бы услышать мнения на этот счёт.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Sunzer пишет:
А если будер рабочий один сервер. Пин активируют. Затем этот сервер ляжет, на других пин будет активен еще ведь, и можно повторно активировать....

Я думаю, что на момент проверки пина и его использования должно быть доступно не менее 2-х серверов. Только так можно исключить повторное использование. Ну или если сервер был доступен один, то на момент попытки повторной активации на другом - этот должен быть доступен.

| Сообщение посчитали полезным:

Я бы все же советовал разобраться что такое балансировка нагрузки и репликация данных. Все равно ты в конечном итоге сделаешь то же самое, только на коленке и с костылями.

| Сообщение посчитали полезным:

Azur1d пишет:
на коленке и с костылями


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

| Сообщение посчитали полезным: