Архитектура Master + Slave и Master + Memcache - PullRequest
1 голос
/ 10 января 2012

Предположим, у нас есть один сервер с базой данных и N серверов, которые можно использовать для кэширования данных с помощью Memcache. Каждая запись в базе данных может иметь несколько (но существенно меньше, чем N) представлений в кеше. Например, объект с идентификатором 108 может кэшироваться ключами entity_108_1, entity_108_2, ..., entity_108_10. При изменении какой-либо записи в базе данных соответствующие записи в кеше заменяются новыми данными.

Почему эта архитектура не лучше, чем настройка базы данных master / slave? Кажется, что он имеет те же преимущества, но при этом не страдает от задержек репликации.

Ответы [ 2 ]

2 голосов
/ 10 января 2012

Я думаю, что лучше пойти с memcache.Не только задержки во время репликации создают проблемы, но и вашим N-серверам не нужно огромное пространство на жестком диске (если мы предположим, что у вас огромная база данных).С другой стороны, вы не добьетесь избыточности.Если ваш главный сервер базы данных умрет, у вас не будет никого, кто занял его место.Итак, подчиненные серверы необходимы для этих целей, но, скорее всего, вам не нужно N из них, и если вы можете достичь масштабируемости с помощью memcache, то нет причин не делать этого (я имею в виду, если вы разрабатывали приложения, которыезнать, как его использовать).Исходя из моего опыта, всегда легче поддерживать экземпляр memcached, чем подчиненный сервер MySQL (и, вероятно, то же самое с другими механизмами баз данных).

Конечно, все это имеет смысл, если вы разрабатывали приложения, которые знают, как использовать memcache.Всегда проще просто добавить еще одну строку подключения в вашу конфигурацию и использовать ее только для чтения с какого-либо сервера базы данных так же, как вы используете ее с master.Использование данных из какого-либо другого источника данных (например, memcache) предполагает, что вы создали свое приложение таким образом.

0 голосов
/ 11 января 2012

при условии, что у вас все еще будет настройка master / slave для db, даже если у вас есть N узлов для memcache

решение поставляется с минусами и плюсами

это не лучше, чем ведущий / ведомый, если речь идет о сценарии с интенсивной записью.

процесс записи должен был бы истечь все кэшированные объекты на всех узлах memcache и ждать «успешных» ответов, так как вы хотите избежать доступа к любой копии старых данных. в этом случае, в зависимости от количества копий кэшированных объектов и скорости сети, вы можете страдать от низкой производительности. Тем не менее, поскольку вы не знаете, на каком узле есть копия, вам придется отправить запрос на истечение срока действия на все узлы ...... :(

...