Как Обрабатывать Возможные Проблемы согласованности в Разделении Чтения / Записи MySQL

Question

Я искал решения для масштабирования MySQL.За исключением добавления слоя Memcached часто возникает разделение на чтение / запись - все записи отправляются на мастер, а все чтения - на набор ведомых с балансировкой нагрузки.

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

Кто-нибудь знает конкретные стратегии для решения этой проблемы?Я читал о концептуальном частичном решении способности «читать-что-ты-пишешь».Но есть ли у кого-нибудь идеи, как реализовать такое решение - концептуально или конкретно в стеке Spring / Hibernate?

Answer 1

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

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

Вы можете обнаружить, что есть некоторые (интенсивно для записи) случаи использования, когда эта стратегия сводит на нет преимущества наличия чтения / записиТрещина.Но я бы поспорил, что в большинстве случаев дополнительная проверка memcache и случайные повторные чтения мастера все равно будут делать это.

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

Все это говорит: не забывайте тамЕсть много случаев, когда лаг приемлем.Например, если у вас есть веб-сайт, на котором пользователи обновляют свои профили, если их изменения не распространяются полностью в течение пяти минут, в большинстве случаев это нормально.Ключ, я думаю, не в том, чтобы что-то чрезмерно спроектировать, чтобы получить мгновенное распространение, если в этом нет необходимости.