Реализация распределенного кеша с использованием языка балерины была моей первой стажировкой в WSO2. В то время я учился на втором курсе с неплохими навыками программирования, но понятия не имел, что такое распределенные вычисления, поэтому этот проект стал для меня уникальным опытом. Эта статья представляет собой попытку объяснить, как я узнал о распределенных системах, а также о процессе разработки и реализации распределенного кэша с нуля.
Требования и рассуждения
Это исследовательский проект, целью которого было познакомить стажера с основами распределенных вычислений, поскольку он охватывает множество концепций распределенных вычислений. Вы можете проверить раздел результатов обучения, чтобы узнать больше об этом.
Требовалось реализовать с нуля автономный распределенный кеш с использованием языка балерины. Это означает, что мне не разрешено использовать такие инструменты, как Zookeeper. Ballerina - это новый облачный язык программирования, разработанный WSO2, чтобы упростить разработчикам создание распределенных систем. Я считаю, что им нужно было проверить, способен ли язык создавать сложные распределенные приложения, подобные этому. Кроме того, поскольку в то время у Ballerina не было существующих библиотек, мне пришлось изучить и реализовать эти алгоритмы.
Когда я начинал проект, я даже не знал, что такое распределенный кеш. Поэтому мне пришлось провести некоторое исследование существующих систем, чтобы понять предметную область и варианты ее использования. В результате я нашел такие решения, как Memcached, Hazelcast IMDG, EHCache. Затем я провел углубленное исследование функций, архитектуры и реализации этих платформ, и это постепенно помогло мне познакомиться с предметной областью и получить глубокое понимание электронной конструкции и реализации распределенного кеша.
Эта проблема
Изучая существующие системы, я обнаружил, что разработчики неохотно используют распределенные кеши по разным причинам.
При изменении членства в кластере кэш выполняет дорогостоящую задачу перемещения, чтобы восстановить возможную потерю данных, вызванную изменением членства. Затем, когда узел снова в сети, это вызовет еще одну задачу восстановления данных. Если сеть ненадежна, это может происходить неоднократно. Это приводит к отказу в обслуживании и, в конечном итоге, к сбою всего кластера. что может привести к перегрузке базы данных и значительному снижению производительности приложения.
Дальнейшее объяснение этой проблемы можно найти в следующем сообщении блога.
Дизайн
Оценка алгоритмов для каждого компонента была самой сложной и интересной частью этого проекта. Мне пришлось изучить все связанные концепции и методы, которые можно было использовать в компонентах, и оценить наиболее подходящий для каждого компонента.
Управление членством
Основным проектным решением было обеспечение надежности участников кластера. Для достижения этого требования был выбран протокол RAFT Consensus. RAFT - это надежность популярных платформ, таких как Kubernetes и т. Д.
Протокол Raft состоит из следующих механизмов
- Механизм Heartbeat для постоянного мониторинга состояния узлов кластера.
- Leader Election Механизм выбора лидера для кластера и управления кластером в заданное время.
- Механизм репликации журнала для обеспечения безопасности данных конечного автомата.
Если вас интересует этот потрясающий протокол, вы можете найти дополнительную информацию в этом блоге.
Детектор отказов
Консенсус Raft состоит из механизма сердцебиения, однако он не содержит надлежащего детектора сбоев. Поскольку проблема возникает из-за неправильного обнаружения отказов, детектор отказов был разработан как расширение механизма тактового сигнала Raft.
Детектор отказов был разработан с учетом правильности. Лидер кластера ведет журнал состояния всех узлов и снижает его, если он не реагирует на тактовые импульсы. Когда состояние узла низкое, узел будет удален из распределения кеша и будет отслеживаться в течение определенного времени перед добавлением обратно в кеш.
Когда узел находится в фазе мониторинга, лидер кластера будет продолжать посылать контрольные сообщения с вызовами RPC на отслеживаемый узел. Этот монитор также действует как усовершенствованный автоматический выключатель для обнаружения отказов. Все новые элементы кластера и восстановленные узлы будут проверены на работоспособность перед добавлением в распределение кэша.
Распространитель записей в кэш
При разработке распределителя записей кэша были учтены несколько факторов. Для этого распределения записей использовалась расширенная версия алгоритма согласованного хеширования. При выборе алгоритма согласованного хеширования с ограниченными нагрузками были приняты во внимание следующие факторы.
- Запись и чтение производительности
Согласованное хеширование - это схема распределенного хеширования, которая работает независимо от количества серверов или объектов в распределенной хэш-таблице, назначая им позицию в абстрактном круге или хэш-кольце. Это позволяет масштабировать серверы и объекты, не влияя на систему в целом.
2. Репликация
Репликация входа - решающий фактор в любой распределенной среде. Согласованное хеширование обеспечивает простой механизм репликации, который реплицирует данные без дублирования в одном узле.
3. Перенос данных
Согласованное хеширование позволяет свести к минимуму количество ключей, которые необходимо перемещать при добавлении или удалении серверов.
4. Сбалансированная нагрузка
Несогласованность распределения данных - один из основных недостатков согласованного хеширования. Алгоритм согласованного хеширования с ограниченными нагрузками позволяет равномерно заполнять записи в кластере, не перегружая ни один из узлов.
Результаты обучения
Как упоминалось в начале блога, у меня не было опыта работы с распределенными вычислениями. Я узнал о теореме CAP, алгоритмах консенсуса, схемах и протоколах членства, сетевых протоколах с низкими накладными расходами, таких как gRPC, стратегиях широковещательной передачи сообщений, алгоритмах распределения данных, хэш-функциях, отказоустойчивости, разработке хаоса, порядке событий и времени, стратегиях репликации данных, облаке. шаблоны проектирования и языки формальных определений, такие как TLA +.
Если вы новичок в распределенных вычислениях, приведенные выше ключевые слова могут быть немного подавляющими. Вы можете использовать следующие ресурсы для самостоятельного изучения распределенных вычислений. Как только вы поймете основы, изучение конкретных алгоритмов станет очень простой задачей.
Вы можете реализовать свой собственный распределенный кеш в качестве практического проекта, чтобы применить полученные знания на практике. Не стесняйтесь оценивать и использовать другие алгоритмы, если считаете, что они лучше того, что использовал я. Не забудьте также прокомментировать свои рассуждения в комментариях.
