Redis Mimic MASTER / МАСТЕР?или что-то другое? - PullRequest
6 голосов
/ 22 сентября 2011

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

Scenerio:

у нас есть 2 сайта на противоположных концах США. Мы хотим, чтобы клиенты могли писать на каждом сайте в большом объеме. Затем мы хотим, чтобы каждый клиент мог выполнять чтение на своем сайте. Однако мы хотим, чтобы данные были доступны после записи на дочернем сайте в <50 мс. Учитывая, что у нас много пропускной способности. Есть ли способ настроить Redis для удовлетворения наших потребностей? максимальный размер нашей записи будет порядка 5 Кб, как правило, намного меньше. Главное, как я могу иметь 2 мастера, которые синхронизируются друг с другом, даже если это не поддерживается по умолчанию. </p>

Ответы [ 3 ]

11 голосов
/ 24 сентября 2011

Это около 19 мс со скоростью света, чтобы пересечь США.<50 мс будет трудно достичь.</p>

http://www.wolframalpha.com/input/?i=new+york+to+los+angeles

11 голосов
/ 09 октября 2011

Смысл ответа Тома в том, что вы не используете какой-либо кластер, вы просто пишете на два сервера.Это проблема, если вы хотите обеспечить согласованность между ними.Подумайте, что происходит, когда вашему клиенту не удается выполнить запись на удаленный сервер.Вы отменяете запись в местном?Что происходит с приложением, когда вы не можете написать на удаленный сервер?Что происходит, когда вы не можете читать с местного?

Второй улов - проблема фундаментальной физики, которую поднимает Джошуа.Для двусторонней передачи вы говорите теоретический минимум 38 мс, оставляя теоретическое максимальное время обработки на обоих концах (из трех систем) 12 мс.Я бы сказал, что ожидания слишком велики, и пропускная способность в этом случае не имеет отношения к задержке.Вы могли бы иметь канал 10 ГБ, и эти сроки все еще существуют.Тем не менее, передача 5 КБ через континент за 12 мс также требует больших затрат.Вы уверены, что у вас есть возможность подключения для передачи 5 КБ данных за 50 мс, не говоря уже о 12?Я был на частных каналах без использования по всему континенту и видел, что время пинга превышает 50 мс - и пинг не передает 5 тыс. Данных.

Как вы будете поддерживать синхронизацию двух не связанных серверов?Если вам действительно требуется задержка менее 50 мс на континенте, приведенный выше теоретический лучший вариант означает, что у вас есть 12 мс для запуска алгоритмов синхронизации.Даже один запрос для проверки данных на другом сервере означает, что вы находитесь за пределами окна 50 мс.Если данные не синхронизированы, как вы это исправите?Учитывая вышеприведенное время, я не понимаю, как можно синхронизировать менее 50 мс.

Я бы порекомендовал пересмотреть основные требования к дизайну.В частности, почему это требование?Требования к задержке в 50 мс в оба конца по континенту обычно являются признаком маркетинга или отсутствия внимания к деталям.Держу пари, что если вы проанализируете требования, вы обнаружите, что это окно 50 мс является чрезмерным и ненужным.Если это не так, и синхронизация данных на самом деле важна (вероятно), то кому-то нужно будет определить, стоит ли значительных дополнительных усилий для написания кода синхронизации или вообще возможно удержаться в пределах окна 50 мс.Синхронизация данных между континентами до 50 мс не простая задача.

Если вам не нужна синхронизация, почему бы просто не запустить один сервер?Вы можете использовать раба на другой стороне континента только для целей восстановления.Конечно, это по-прежнему означает, что в лучшем случае у вас есть 12 мс для передачи данных туда и обратно.Я бы не стал рассчитывать на 50 мс туда-обратно + задержка + 5к / 10к передача данных по всему континенту.

2 голосов
/ 24 сентября 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...