Кластеризация против репликации

Question

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

1. кластеризация. Использование терракоты и использование второго (пассивного) сервера, установленного на узле.
2. Репликация / Синхронизация. Моя оригинальная идея: разрешить узлам отключаться при сбоях сети, а затем перезапускать операции.

Что вы рекомендуете?

PS Если в моих рассуждениях что-то не так, скажите, пожалуйста

Answer 1

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

И извиняюсь за свои короткие навыки общения, я все еще изучаю английский!

Answer 2

Я думаю, вы говорите, что у вас есть одна машина, на ней у вас есть приложение, использующее Hibernate, и база данных MySql. Если вы потеряете эту машину, ваши пользователи не смогут работать. Вы спрашиваете, возможна ли дополнительная устойчивость, и считаете, что вы определили два решения.

Вы не дадите подробностей ни о каком решении, поэтому я не буду пытаться угадать, что вы имеете в виду.

Вы также мало говорите о характере приложения. Если (например) он был полностью доступен только для чтения, обновления баз отсутствуют, тогда репликация сравнительно проста. Если все записи аддитивны и не могут конфликтовать (например, какой-то опрос общественного мнения, проголосуйте «за» / «нет»), то повторная репликация с небольшим количеством очередей сравнительно проста.

Однако это традиционное приложение с пользователями, обновляющими общие данные, где согласованное представление важно (например, мы не хотим продавать последний доступный номер в отеле дважды), тогда тиражирование становится сложным.

Один из подходов состоит в том, чтобы разделить базу данных на уровень высокой устойчивости, такие продукты, как Oracle RAC, обладают очень умными характеристиками устойчивости, и я полагаю, вы платите за интеллектуальность. Если у вас есть устойчивая база данных, кластеризация вашего приложения становится намного проще. Я часто вижу множество дешевых коробок, запускающих приложение параллельно, потому что БД управляет окончательной «истиной».

Однако даже это сложно, если приложение не было разработано заранее для репликации. Вы обнаружите, что на основе приложения делаются тонкие предположения, и в некотором смысле можно полагаться на его прежнее представление об истине. Такие продукты, как Terracotta, вполне могут (я никогда не пробовал, поэтому я не знаю) помочь реализовать отказоустойчивый дизайн, но, если дизайн не будет хорошо продуман, у него могут быть недостатки в бизнесе.

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