Вчера пришёл убитый, поэтому пишу только сейчас.
Итак, начнём с самого важного. Главное при работе с сокетами - это заложить горизонтальное масштабирование, хотя пожалуй это главное почти для всего. Дело в том, что у тебя не будет проблем, когда все твои коннекты висят на одном сервере, но если ты допускаешь, что нагрузка будет расти и понадобится кластер, то ты сразу получишь граблемя по лицу, например: чат между двумя юзерами - один работает с одним сервером, другой с другим и поэтому они про друг по друга ничего не знают и нет никакой возможности узнать о новых сообщениях, кроме как время от времени чекать БД, но сам понимаешь, что это плохой способ. Путей решения несколько, начну от простого к сложному.
1) Заюзать сторонний сервис уведомлений (например,
https://pusher.com/) и работать по схеме: подключаешь их браузерную либу, клиенты конектятся по сокету к их серверам, а они в свою очередь шлют уведомления на твои сервера, где ты через их серверную либу обрабатываешь их.
Плюсы:
Очень просто реализовать.
Легко масштабировать.
Минусы:
Это платная услуга.
Каждый клиент создаёт коннекшин, а число коннекшинов ограничено тарифами.
Каждый клиент генерирует сообщения, число которых также ограничено тарифом.
2) Заюзать сторонний сервис уведомлений, но в качестве клиента использовать свои сервера, т.е. твои пользователи конектятся напрямую к твоим серверам, а они уже конектятся к API сервиса и шлюс сообщения.
Плюсы:
Не сложно реализовать.
Легко масштабировать.
Количество коннекшинов = количество серверов в кластере, а не пользователей, как при первом подходе.
Количество сообщений можно оптимизировать: не слать сообщения, если нет нужны, например если все нужные пользователи подключены к одному серверу.
Минусы:
Это платная услуга.
3) Написать свой (или настроить готовый модуль) сервер сообщений и балансировщик (стратегии использования такие же, как в примерах выше).
Плюсы:
Не надо платить за внешний сервис.
Легко масштабировать (при условии если нормально напишешь).
Минусы:
Это сложнее реализовать.
Появляется дополнительная головная боль, которую сторонний сервис инкапсулирует от нас.
4) WebRTC. Использование P2P подхода может сделать твою систему децентролизованой и значительно облегчить нагрузку на сервер, т.к. он будет рулить рукопожатия клиентов, при необходимости ходить в базу и рассылать сообщения при необходимости.
Плюсы:
Очень сильно сбивает нагрузку на сервер.
Не надо платить за внешний сервис.
Легко масштабировать (при условии если нормально напишешь).
Минусы:
Это сложно реализовать по нормальному.
Постоянный затрах с синхронизацией состояний на разных клиентах.
***
Я юзаю 2-й и 4-й подходы. Следующим постом продолжу лекцию
