Комментарии 5
Сегментирование пользователей это не есть шардирование. Хорошее шардирование должно распределять все нагрузки поровну. В вашем случае я так понимаю если все старые пользователи решили одновременно поиграть в игру будет нагружаться сервер который отвечает за старых пользователей так? Могу посоветовать вам что-то типа postgres-xl. Которая имеет в себе принципы acid. И уже сверху такого шардинга можете поставить любой кэш.
Я шардировал с помошью citusdb.
https://en.wikipedia.org/wiki/ACID
Я шардировал с помошью citusdb.
https://en.wikipedia.org/wiki/ACID
Единственный недостаток ConcurrentDictionary – нет полной документации по его работе
Довольно странно слышать такое, когда все исходники лежат в общем доступе
Разрабатываю свой проект, связанный с асинхронным и многопоточным вычислением. В основном вычисления происходят в максимальной нагрузке в 10-20 копий одного процесса, около 1 млн. обменов в сек. между каждым процессом и одним приложением-сервером. Проще говоря единственный процесс — босс, остальные — подчиненные, у этих подчиненных есть еще подчиненные. Каждый занят своим делом, и между прочим это один и тот же исполняемый файл.
Почему не многопоток в одном процессе?
1. Очень усложняется архитектура приложения. 2. Исторически сложилось что программа пишется на 32 битах, память ограничена. 3. Задел на будущее, если нужно будет запускать на удаленных машинах.
Конечно пришлось избавляться от некоторых проблем винды, вроде того что ядро системы перегружало процессор до максимума из-за использования мэппинга, но факт в том что упрощая архитектуру приложения можно получить больше гибкости.
Почему не многопоток в одном процессе?
1. Очень усложняется архитектура приложения. 2. Исторически сложилось что программа пишется на 32 битах, память ограничена. 3. Задел на будущее, если нужно будет запускать на удаленных машинах.
Конечно пришлось избавляться от некоторых проблем винды, вроде того что ядро системы перегружало процессор до максимума из-за использования мэппинга, но факт в том что упрощая архитектуру приложения можно получить больше гибкости.
Сделал пример своей реализации для блокировки наборов ключей.
Код который использует этот подход предварительно собирает ключи сущностей которые будут затронуты в бизнес операции, затем пытается заблокировать, если не удалось, значит какая-то из сущностей будет обновлена, и нужно повторить операцию, предварительно обновив данные.
Код который использует этот подход предварительно собирает ключи сущностей которые будут затронуты в бизнес операции, затем пытается заблокировать, если не удалось, значит какая-то из сущностей будет обновлена, и нужно повторить операцию, предварительно обновив данные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение кэша с эффективным многопоточным доступом