Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 3
В примере с почтовыми ящиками пользователей А и Б:
вы приводите схему №8, где опять же нет гарантии, что ящики пользователей А и Б окажутся на одном прокси-сервисе.
Следовательно, если они оказались на разных прокси-сервисах, то чтобы пользователь А получил письмо, написанное пользователем Б, нужно, чтобы прокси-сервис пользователя А получил это письмо от мастер-сервиса.
То есть задача не решена?
Невозможно найти алгоритм распределения данных по экземплярам (шардинг), который гарантирует нахождение ящиков пользователя А и Б в одном экземпляре сервиса. Но и для этой ситуации есть решения. Самое простое: имплицитно разделить сервис (в идеале — через middleware) так, чтобы клиент об этом ничего не знал.
вы приводите схему №8, где опять же нет гарантии, что ящики пользователей А и Б окажутся на одном прокси-сервисе.
Следовательно, если они оказались на разных прокси-сервисах, то чтобы пользователь А получил письмо, написанное пользователем Б, нужно, чтобы прокси-сервис пользователя А получил это письмо от мастер-сервиса.
То есть задача не решена?
Возможны вариации, но вот вариант решения. Соединяем схему 8 и 6. По прецедентам (Use Case)
Фишка в том, что Use Case 2 гораздо чаще используется чем 1,3 или 4. На тех порталах где я имел честь работать 95%++. В основном это проверка — а есть ли новые сообщения.
А убрать 95% запросов — правда неплохо?
Конечно, в схеме есть варианты, например можно сразу обновить ящик а не убирать его из кэша, или не делать нотификацию а кэшить на прокси-сервере А с expiry, например 2 минуты. В таком случае обновление в ящике мы бы увидели, самое раннее, через 2 минуты. В общем много вариантов — правильный для Вас зависит от Ваших требований.
- Пользователь А читает мейл. Прокси-сервер 1 грузит ящик с мастера (ибо первый раз) и отвечает на запрос.
- Пользователь А (снова) читает мейл. Прокси-сервер отвечает из кэша.
- Пользователь Б посылает мейл пользователю А через прокси-сервер 2. Прокси сервер 2 передает мейл на мастер-сервис. Мастер сервис обрабатывает запрос и асинхронно посылает информацию «обновить кэш» на прокси сервер 1 (так как он знает алгоритм распределения по прокси-серверам). Прокси-сервер 1 получает уведомление и маркирует ящик пользователя А как дерти (или просто стирает его с кэша).
- Пользователь А читает мейл. Прокси-сервер 1 грузит ящик с мастера (ибо в кэше нету) и отвечает на запрос.
Фишка в том, что Use Case 2 гораздо чаще используется чем 1,3 или 4. На тех порталах где я имел честь работать 95%++. В основном это проверка — а есть ли новые сообщения.
А убрать 95% запросов — правда неплохо?
Конечно, в схеме есть варианты, например можно сразу обновить ящик а не убирать его из кэша, или не делать нотификацию а кэшить на прокси-сервере А с expiry, например 2 минуты. В таком случае обновление в ящике мы бы увидели, самое раннее, через 2 минуты. В общем много вариантов — правильный для Вас зависит от Ваших требований.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабировать просто. Часть третья — стратегии