Я разработал API, который отправляет текстовые сообщения. В настоящее время на одном сервере работают три таблицы MySql (sms_account, sms_number и sms_transaction).
Я хочу использовать haproxy для балансировки нагрузки и повышения производительности для разделения запросов между несколькими веб-серверами, но я не знаю, как обработать часть базы данных. Я знаю, что мог бы создать отдельный кластер базы данных в сценарии мастер-мастер, но задавался вопросом, можно ли это сделать лучше.
Я думал о том, чтобы иметь одну основную кластерную базу данных, которая содержит базу данных, идентичную веб-серверам. Таблицы sms_account и sms_number могут быть обновлены только для этой таблицы, и эта таблица может обновлять таблицы sms_account и sms_number веб-серверов, поскольку они меняются не очень часто. Затем я подумал, что каждый экземпляр веб-сервера / mysql может периодически обновлять основную базу данных записями из каждой таблицы sms_transaction.
Это звучит немного беспорядочно, но при таком подходе загрузка базы данных будет действительно низкой, поскольку все базы данных веб-сервера останутся небольшими и быстрыми, а основная может использоваться для выставления счетов.
Я просто хотел бы получить второе мнение о дизайне. Я думаю, что в случае сбоя любой из веб-серверов может продолжать работать независимо от других серверов.
Веб-серверы буквально регистрируют транзакцию и все. Здесь нет сложных запросов. Я мог бы делать отчеты и т.д. из основной базы данных.
Большое спасибо
Проблема с битом «Периодическое обновление» всегда заключается в согласованности.
Создание собственного алгоритма слияния возможно, но в конечном итоге вы столкнетесь с ошибкой в обработке ошибок.
Я действительно рекомендую вам подождать масштабирования MySQL, пока вам это не понадобится. Держите свой код доступа к данным достаточно хорошо изолированным, и вы всегда можете выполнить рефакторинг, если / когда вам это нужно.
Как только вам нужно провести рефакторинг, вы находитесь в идеальной конфигурации «ведущий / ведомый».
Других решений пока нет …