Есть задача. Посоветуйте, пожалуйста.

Сеть предприятий, расположенных в основном в пределах европейской части России. Допустим, это гостиницы. Хочу, чтобы клиент мог позвонить в любой из филиалов и забронировать номер в любом из филиалов, а также закать доп. услуги. Причём легко и непринуждённо :)

Часть филиалов объединены в локальную сеть. Своими руками написано многопользовательское приложение, которое работает с SQL-сервером (Postgre). В локальной сети работает всё нормально. Но что делать с другими филиалами. Ведь крайне важно, чтобы не было противоречивых броней. То есть все пользователи должны обладать актуальной информацией о всех свободных номерах хотя бы на месяц вперёд.

-Вопрос надёжности системы критичен. Даже при разорванном соединении с сервером работа не должна приостанавливаться (допустимы ограничения функциональности).

-Вопрос частоты обновления информации также критичен - информации мало, но изменяется очень часто. Насколько я понимаю, есть несколько вариантов.

1. Несколько локальных сетей, пользователи которых работают со своим локальным сервером. Локальные серверы через различные каналы связи связываются друг с другом и их базы данных реплицируются.

2. То же самое, но с центральным сервером.

3. Нет никаких локальных сетей - все просто заходят на какой-то сайт и работают там

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

В дальнейшем хотим на своём сайте разрешить самостоятельное онлайн бронирование (без всяких там подтверждений и перезваниваний).

авторПосоветуйте, какой вариант при таких задачах предпочтительнее. И грабли какие ждут впереди.

Член СП с 1931 гЗначит - п.1 репликация, однозначно.

Согласен. А как сделать так, чтобы это была "разовая" репликация, которая будет происходить только после разрыва/восстановления связи?

автор... (допустимы ограничения функциональности).

Согласен, что требуется локальное приложение. И какое-то локальное хранилище данных на всякий аварийный случай. А если так сделать?
В случае разрыва соединения с сервером, пользователь, работая с ограниченными локальными данными, может бронировать номера только в своём отеле, а все остальные пользователи не могут бронировать номера в "отлетевшем" отеле. А после восстановления соединения с сервером, новые локальные данные поступают на сервер. Дальше, пользователь уже работает снова напрямую с сервером. Все прочие пользователи получают уведомление о восстановлении связи с таким-то отелем. Здесь просто надо будет настроить локальное приложение таким образом, чтобы оно могло работать как сданными сервера, так и с локальными данными, а также организовать поступление части данных с сервера в локальное хранилище.

miksoftКрайне не советую так делать! Есть огромный риск, что конкуретны/хулиганы/ошибки клиентов превратят это бронирование в полную фикцию.
Такой вариант развития событий предусмотрен. Мы сделаем доступными для брони только часть свободных номеров, а доступ к бронированию будет возможен только для постоянных клиентов по паролю. Тем более, напомню, я сказал
авторДопустим, это гостиницы
на самом деле речь идёт о несколько иной отрасли, хотя и очень похожей.

А если это будет служебный сайт, как в таком случае будет поддерживаться "автономная" работа пользователя? Ну, предположим, сгорел этот провайдер вместе с нашим сайтом?

!call center

Такая схема у нас уже работает для части предприятий. Однако, есть недостатки:

1. Это будет неудобно для клиентов. Наверняка, многие общались с консультантами сотовых операторов.
автор
-ля...ля...ля...к сожалению все операторы заняты. подождите полчаса или перезвоните...ля...ля....ля...ля...ля...ля...ля..........
-Консультант Алёна, компания "Траляля". Чем могу помочь?
-Я вот купил себе новый аппарат и не могу настроить на нём жпрс.
-Я могу выслать Вам настройки. Какая у Вас модель?
-Да есть у меня настройки ваши, а жпрс не работает...
-Соединяю с инженерной службой...
-ля...ля....ля...ля...ля...ля...ля..........
-Консультант Евгения, компания "Траляля". Чем могу помочь?
-А мне нужна инженерная служба...
-Может быть я смогу вам помочь?
-Я вот купил себе новый аппарат и не могу настроить на нём жпрс.
-Я могу выслать Вам настройки. Какая у Вас модель?
-Да есть у меня настройки ваши, а жпрс не работает...
-Соединяю с инженерной службой...
-ля...ля....ля...ля...ля...ля...ля..........
-Инженер Владимир, компания "Траляля". Чем могу помочь?
-Я вот купил себе новый аппарат и не могу настроить на нём жпрс.
-Я могу выслать Вам настройки. Какая у Вас модель?
-Да есть у меня настройки ваши, а жпрс не работает... У меня коммуникатор "хххх хх хх"
-Секундочку...ля...ля....ля...ля...ля...ля...ля..........
-...ля...ля...ля...к сожалению все операторы заняты. подождите полчаса или перезвоните...ля...ля....ля...ля...ля...ля...ля..........

Нам так не нравится.

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

3. Сотрудники, которые у нас отвечают на телефонные звонки очень дорого стоят в связи со спецификой предприятия. И те функции, которые может успешно выполнять автомат - мы стараемся передать автомату. Для повышения КПД сотрудника дорогостоящего и редкого :) Пусть они занимаются тем, что автомат решить не в силах ( или пока не в силах)

!Полагаю, что вы не очень хорошо знакомы с предментной областью

Это действительно так. Но есть огромное желание разобраться хотя бы в азах. А книги читать некогда. Вот и решил у людей поспрашивать.

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

micsoftкакие допускаются задержки

до 15 секунд. Это максимум. Вопрос в цене вопроса :)

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

2. Откат. Хотелось бы сказать, что не допускается вообще.. А вы мне, наверное, - "так не бывает, дружище!" ;) В-общем, если провайдеры по статистике сгорают не чаще 1 раза в 3 года, то откат можно допустить на 1 сутки. Если же эта неприятность происходит чаще - откат допустим в пределах времени задержки (15 сек).

3. Строго сформулированного ТЗ нет. Поскольку мы хотим не заработать сейчас денег на этом, и не сэкономить их. Мы хотим их потратить. На то, что кажется нам интересным и прогрессивным. Модным. Возможно в будущем это и начнёт приносить деньги, но сейчас (мы это осознаём) - только отнимет у нас эти деньги. Бюджет с расплывчатыми рамками, условно не ограничен. Сейчас проектирование всей этой системы на таком этапе, когда мы хотим получить конкретные варианты с описанием функциональности, надёжности, скорости работы, стоимости, времени разработки, масштабируемости. Исходя из этой информации будет выбран тот вариант, КПД вложения денег в который в условиях специфики предприятия будет сочтён наиболее высоким.

авторКстати, не помешало бы исследование на тему
Для начала в сети будут:
1. Нижний Новгород
2. Ульяновск
3. Екатеринбург
4. Челябинск
5. Тюмень
6. Курган
7. Магнитогорск
А как это можно узнать? Обратиться непосредственно к провайдерам? По запросу "национальные магистральные операторы интернет трафика" яндекс даёт только ссылки на отдельных операторов. А как узнать какие операторы "трудятся" в каждом конкретном регионе/городе?

п.с. Спасибо Вам большое, miksoft, за поддержку.

miksoftА если канал в данный момент не работает и в ближайшие 15 секунд не заработает? как о бронировании должны узнавать пользователи из других городов?

Если канал не работает, то бронирование не состоится. Я так понимаю. В то же время понимаю, что Вы имели ввиду какую-то другую ситуацию :) Я, честно говоря, не понял.

Но догадываюсь. Варианты:

1. Воспользоваться другим каналом
2. Например позвонить по телефону

Кстати. Наверняка подобные системы уже функционируют где-то. Вот, например, как работают цепочки турагенства/туроператоры/отели? По уму, у них должно быть что-то подобное. Различные федеральные сети магазинов, интегрированных со своими интернет-клонами. Хотя продажа товаров несколько отличается от продажи услуг. А мы продаём услуги...

miksoftА каков будет объем информации, которые должна получать/генерить каждая из точек? а то, может, будет достаточно пары мобильников (от разных операторов для резервирования) с GPRS-ом...

Объём информации максимум 20 кб. GPRS наверное будет достаточно. А эти разные операторы транслируют трафик не через того же "единственного магистрального оператора"? Прошу прощения за терминологию :)

miksoftЯ имел ввиду, когда в городе Н приходит (или звонит) человек и просит забронировать номер в этом же городе Н. А в это время нет связи с центром/другими узлами. Что тогда делать? Отказывать в бронировании?
Казалось бы, нужно принять заказ, но тогда при бронировании информация, имеющаяся на других узлах станет недостоверной.

С другой строны, человек в городе К просит забронировать номер в городе Н. Но именно с этим городом Н в данный момент связи нет. Отказывать?

Мне механизм решения такого "казуса" видится таким.
1. Если в городе Н. нет связи, то город Н. может забронировать номер в городе Н. Эти изменения сохраняются локально. А все остальные узлы должны быть извещены о "проблемах" в городе Н. и доступ к бронированию в городе Н. должен быть закрыт. После воостановления связи в городе Н., локальные данные города Н. передаются на центр/другие узлы, другие узлы получают извещение о восстановлении нормальной работы. Можно ещё предусмотреть такой вариант. Если будет центральный сервер, то, в случае "отваливания" одного из узлов, он автоматически "виртуально" бронирует часть номеров для тех узлов, которые "на связи". И этими виртуальными бронями могут оперировать подключенные узлы. Только вот ещё "отвалившийся" должен как-то узнать о том, что именно забронировано. Можно это делать заранее, до того, как кто-то отвалится.

2. Если человек звонит в город К, который "на связи", и хочет бронь в г. Н, который не "на связи" - оператор города К просто переключит его звонок на оператора города Н.

3. То же самое со звонками в город Н, который не "на связи"

Всего звонков в день на один город 100-500. Фактов бронирования на город в день 10-100 (крайние значения приведены для дней, в которые действуют особые условия, т.е. пора скидок).