Вышла новоая версия языка Go - Go 1.24.
https://go.dev/doc/go1.24
Основные изменения в новой версии:
Go 1.24 теперь полностью поддерживает псевдонимы обобщённых типов (generic type alias) — псевдоним типа может быть параметризирован, как и впервые определяемый тип (при определении псевдонима типа теперь допускается указание параметров типа);
Оптимизация среды выполнения снизила нагрузку на процессор на 2–3%. Оптимизации включают новую реализаций операций со словарями на основе хэш‑таблиц Swiss Table, более эффективное распределение памяти для небольших объектов и новую реализацию внутреннего мьютекса во время выполнения
Команда go теперь предоставляет механизм отслеживания зависимостей инструментов для модуля. Определение утилит в файле go.mod производится через директиву tool, для добавления которой в текущий модуль предложена команда go get ‑tool (например, go get ‑tool golang.org/x/tools/cmd/stringer). Для запуска утилиты, указанной в директиве tool, добавлена команда «go tool имя_утилиты».
В команды go build и go install добавлена опция ‑json для вывода в формате JSON
Добавлена переменная окружения GOAUTH для задания параметров аутентификации, необходимых для извлечения модулей, доступ к которым ограничен.
В команде go vet реализован новый анализатор тестов (test analyzer), выявляющий типовые ошибки при включении тестов, fuzzing‑инструментов, утилит проверки производительности и примеров приложений;
В стандартную библиотеку добавлены реализации криптоалгоритмов из стандарта FIPS 140–3. Помимо FIPS 140, несколько пакетов, которые ранее были в модуле x/crypto, теперь доступны в стандартной библиотеке.
В пакет testing добавлен метод B.Loop для выполнения тестов производительности. Применение for b.Loop() {... } вместо обычных циклов позволяет исключить выполнение компилятором полной оптимизации тела цикла и вынести из цикла стадии настройки и очистки теста
Добавлен тип os.Root, позволяющий изолировать операции с файловой системой заданным каталогом.
В среду выполнения добавлен новый механизм финализации runtime.AddCleanup, более гибкий и эффективный, чем runtime.SetFinalizer.
Добавлен пакет weak c реализацией слабых указателей, которые не владеют объектом, не увеличивают счётчик ссылок и не препятствуют освобождению объекта
Добавлены пакеты crypto/mlkem с реализацией криптоалгортимов ML‑KEM-768 и ML‑KEM-1024 (Kyber), стойких для подбора на квантовом компьютере; crypto/hkdf c реализацией функции формирования ключа на базе HMAC (RFC 5869); crypto/pbkdf2 c реализацией функции формирования ключа на базе пароля (PBKDF2, RFC 8018); crypto/sha3 c реализацией хэшей SHA-3;
Добавлен экспериментальный пакет testing/synctest с функциями для тестирования многопоточности;
Улучшена поддержка WebAssembly. Добавлена возможность сборки Go‑приложений в форме библиотеки или обработчика WASI (WebAssembly System Interface). Реализована директива go:wasmexport для экспорта функций для использования в WebAssembly;
В утилиту objdump добавлена поддержка дизассемблирования для архитектур LoongArch (GOARCH=loong64), RISC‑V (GOARCH=riscv64) и S390X (GOARCH=s390x).
https://go.dev/doc/go1.24
Основные изменения в новой версии:
Go 1.24 теперь полностью поддерживает псевдонимы обобщённых типов (generic type alias) — псевдоним типа может быть параметризирован, как и впервые определяемый тип (при определении псевдонима типа теперь допускается указание параметров типа);
Оптимизация среды выполнения снизила нагрузку на процессор на 2–3%. Оптимизации включают новую реализаций операций со словарями на основе хэш‑таблиц Swiss Table, более эффективное распределение памяти для небольших объектов и новую реализацию внутреннего мьютекса во время выполнения
Команда go теперь предоставляет механизм отслеживания зависимостей инструментов для модуля. Определение утилит в файле go.mod производится через директиву tool, для добавления которой в текущий модуль предложена команда go get ‑tool (например, go get ‑tool golang.org/x/tools/cmd/stringer). Для запуска утилиты, указанной в директиве tool, добавлена команда «go tool имя_утилиты».
В команды go build и go install добавлена опция ‑json для вывода в формате JSON
Добавлена переменная окружения GOAUTH для задания параметров аутентификации, необходимых для извлечения модулей, доступ к которым ограничен.
В команде go vet реализован новый анализатор тестов (test analyzer), выявляющий типовые ошибки при включении тестов, fuzzing‑инструментов, утилит проверки производительности и примеров приложений;
В стандартную библиотеку добавлены реализации криптоалгоритмов из стандарта FIPS 140–3. Помимо FIPS 140, несколько пакетов, которые ранее были в модуле x/crypto, теперь доступны в стандартной библиотеке.
В пакет testing добавлен метод B.Loop для выполнения тестов производительности. Применение for b.Loop() {... } вместо обычных циклов позволяет исключить выполнение компилятором полной оптимизации тела цикла и вынести из цикла стадии настройки и очистки теста
Добавлен тип os.Root, позволяющий изолировать операции с файловой системой заданным каталогом.
В среду выполнения добавлен новый механизм финализации runtime.AddCleanup, более гибкий и эффективный, чем runtime.SetFinalizer.
Добавлен пакет weak c реализацией слабых указателей, которые не владеют объектом, не увеличивают счётчик ссылок и не препятствуют освобождению объекта
Добавлены пакеты crypto/mlkem с реализацией криптоалгортимов ML‑KEM-768 и ML‑KEM-1024 (Kyber), стойких для подбора на квантовом компьютере; crypto/hkdf c реализацией функции формирования ключа на базе HMAC (RFC 5869); crypto/pbkdf2 c реализацией функции формирования ключа на базе пароля (PBKDF2, RFC 8018); crypto/sha3 c реализацией хэшей SHA-3;
Добавлен экспериментальный пакет testing/synctest с функциями для тестирования многопоточности;
Улучшена поддержка WebAssembly. Добавлена возможность сборки Go‑приложений в форме библиотеки или обработчика WASI (WebAssembly System Interface). Реализована директива go:wasmexport для экспорта функций для использования в WebAssembly;
В утилиту objdump добавлена поддержка дизассемблирования для архитектур LoongArch (GOARCH=loong64), RISC‑V (GOARCH=riscv64) и S390X (GOARCH=s390x).
go.dev
Go 1.24 Release Notes - The Go Programming Language
❤7🔥2👍1🥰1
Архитектурный шаблон Модульный монолит
В мире архитектуры программного обеспечения уже давно лидируют два доминирующих шаблона.
🔸 Монолитная архитектура
Классический подход, при котором все компоненты приложения тесно интегрированы в единое целое.
🔸 Архитектура микросервисов
Приложение разбито на небольшие независимые службы, которые взаимодействуют по сети.
Модульный монолит представляет собой нечто среднее, прагматичный подход, сочетающий в себе лучшее из обоих миров.
Он направлен на решение следующих проблем:
◾️ Проблемы с поддержкой монолитов
- Благодаря внедрению модульности кодовая база становится более организованной, простой для понимания и менее подверженной синдрому «big ball of mud».
◾️ Сложность микросервисов
- Он позволяет избежать операционных издержек, характерных для распределенных систем, что делает его более доступным вариантом для небольших команд или проектов, которым не требуется полный масштаб микросервисов.
📌 Основные характеристики модульных монолитов
Модульный монолит = Монолитная простота + Модульная гибкость ]
◾️ Кодовая база разделена на четко определенные модули, каждый из которых инкапсулирует определенную бизнес-возможность или домен.
◾️ Каждый модуль инкапсулирует собственные данные, логику и уровни представления, способствуя разделению задач и удобству обслуживания.
◾️ Модули взаимодействуют через понятные интерфейсы (API), способствуя слабой связанности и независимой эволюции.
◾️ Модули могут совместно использовать общие библиотеки или утилиты для повышения эффективности, сохраняя при этом инкапсуляцию.
◾️ Приложение развертывается как единое целое, что упрощает операции по сравнению с распределенными микросервисами.
📌 Когда следует рассмотреть?
◾️ Проекты на ранних стадиях
◾️ Меньшие команды или ограниченные ресурсы
◾️ Приложения средней сложности
◾️ Переход от монолита
- Модульный монолит может стать ступенькой на пути к микросервисам.
📌 Некоторые проблемы и их решения при работе с модульными монолитами
◾️ Поддержание модульности
- Требует дисциплины и постоянного рефакторинга, чтобы избежать «спагетти-кода» по мере роста приложения.
◾️ Межмодульная связь
- Разрабатывайте четкие шаблоны общения (внутрипроцессные звонки или легкие сообщения), чтобы избежать тесной связи.
◾️ Тестирование
- Тщательно протестируйте взаимодействие модулей, чтобы убедиться, что приложение работает как единое целое.
◾️ Масштабируемость
- Масштабирование отдельных модулей может оказаться более сложным, чем масштабирование независимых микросервисов.
В мире архитектуры программного обеспечения уже давно лидируют два доминирующих шаблона.
🔸 Монолитная архитектура
Классический подход, при котором все компоненты приложения тесно интегрированы в единое целое.
🔸 Архитектура микросервисов
Приложение разбито на небольшие независимые службы, которые взаимодействуют по сети.
Модульный монолит представляет собой нечто среднее, прагматичный подход, сочетающий в себе лучшее из обоих миров.
Он направлен на решение следующих проблем:
◾️ Проблемы с поддержкой монолитов
- Благодаря внедрению модульности кодовая база становится более организованной, простой для понимания и менее подверженной синдрому «big ball of mud».
◾️ Сложность микросервисов
- Он позволяет избежать операционных издержек, характерных для распределенных систем, что делает его более доступным вариантом для небольших команд или проектов, которым не требуется полный масштаб микросервисов.
📌 Основные характеристики модульных монолитов
Модульный монолит = Монолитная простота + Модульная гибкость ]
◾️ Кодовая база разделена на четко определенные модули, каждый из которых инкапсулирует определенную бизнес-возможность или домен.
◾️ Каждый модуль инкапсулирует собственные данные, логику и уровни представления, способствуя разделению задач и удобству обслуживания.
◾️ Модули взаимодействуют через понятные интерфейсы (API), способствуя слабой связанности и независимой эволюции.
◾️ Модули могут совместно использовать общие библиотеки или утилиты для повышения эффективности, сохраняя при этом инкапсуляцию.
◾️ Приложение развертывается как единое целое, что упрощает операции по сравнению с распределенными микросервисами.
📌 Когда следует рассмотреть?
◾️ Проекты на ранних стадиях
◾️ Меньшие команды или ограниченные ресурсы
◾️ Приложения средней сложности
◾️ Переход от монолита
- Модульный монолит может стать ступенькой на пути к микросервисам.
📌 Некоторые проблемы и их решения при работе с модульными монолитами
◾️ Поддержание модульности
- Требует дисциплины и постоянного рефакторинга, чтобы избежать «спагетти-кода» по мере роста приложения.
◾️ Межмодульная связь
- Разрабатывайте четкие шаблоны общения (внутрипроцессные звонки или легкие сообщения), чтобы избежать тесной связи.
◾️ Тестирование
- Тщательно протестируйте взаимодействие модулей, чтобы убедиться, что приложение работает как единое целое.
◾️ Масштабируемость
- Масштабирование отдельных модулей может оказаться более сложным, чем масштабирование независимых микросервисов.
👍4🤩4❤1👏1
Правительство РФ утвердило параметры эксперимента по внедрению системы добровольного подтверждения компетенций для разработчиков ПО. Это возможность для работодателей и образовательных учреждений точнее определять уровень ИТ-компетенций и подбирать подходящих сотрудников, а для специалистов — проверить свои знания и получить сертификат, подтверждающий их уровень. С 31 мая 2025 года любой желающий, независимо от уровня образования, сможет пройти тесты и выполнить практические задания. В этом году на платформе планируется разместить материалы по 21 направлению (Python, Java, Git и другие).
С 14 февраля 2025 года по 31 декабря 2026 года в России пройдёт эксперимент по внедрению системы добровольного подтверждения компетенций для разработчиков программного обеспечения.
Суть эксперимента заключается в предоставлении специалистам бесплатного инструмента для проверки собственного уровня владения различными ИТ-компетенциями. Речь идёт о цифровой платформе, воспользовавшись которой программисты смогут пройти тесты и выполнить практические задания.
В случае успешного прохождения испытаний они получат сертификат, подтверждающий их знания и навыки работы. Он будет отправляться в личный кабинет на портале Госуслуг. Срок его действия составит 1 год.
В ходе эксперимента компании-работодатели, образовательные учреждения и другие организации, которые станут его участниками, получат возможность подобрать подходящего программиста, а также оценить уровень профессионализма действующих сотрудников.
Участвовать в эксперименте смогут разработчики ПО независимо от уровня образования.
Оператор эксперимента будет отобран на конкурсной основе до 31 марта 2025 года. Его определением займётся президиум правительственной комиссии по цифровому развитию.
Практическая стадия эксперимента начнётся с 31 мая 2025 года, когда ИТ-специалисты получат доступ к платформе подтверждения своих компетенций и смогут пройти тесты и выполнить задания.
https://news.1rj.ru/str/mintsifry/2436
http://government.ru/news/54223/
С 14 февраля 2025 года по 31 декабря 2026 года в России пройдёт эксперимент по внедрению системы добровольного подтверждения компетенций для разработчиков программного обеспечения.
Суть эксперимента заключается в предоставлении специалистам бесплатного инструмента для проверки собственного уровня владения различными ИТ-компетенциями. Речь идёт о цифровой платформе, воспользовавшись которой программисты смогут пройти тесты и выполнить практические задания.
В случае успешного прохождения испытаний они получат сертификат, подтверждающий их знания и навыки работы. Он будет отправляться в личный кабинет на портале Госуслуг. Срок его действия составит 1 год.
В ходе эксперимента компании-работодатели, образовательные учреждения и другие организации, которые станут его участниками, получат возможность подобрать подходящего программиста, а также оценить уровень профессионализма действующих сотрудников.
Участвовать в эксперименте смогут разработчики ПО независимо от уровня образования.
Оператор эксперимента будет отобран на конкурсной основе до 31 марта 2025 года. Его определением займётся президиум правительственной комиссии по цифровому развитию.
Практическая стадия эксперимента начнётся с 31 мая 2025 года, когда ИТ-специалисты получат доступ к платформе подтверждения своих компетенций и смогут пройти тесты и выполнить задания.
https://news.1rj.ru/str/mintsifry/2436
http://government.ru/news/54223/
Telegram
Минцифры России
🚀 В России появится Национальная система подтверждения ИТ-компетенций
ИТ-специалисты смогут бесплатно пройти тестирование и подтвердить свои компетенции на отечественной платформе. Эксперимент по её внедрению начнётся 14 февраля 2025 года и продлится до…
ИТ-специалисты смогут бесплатно пройти тестирование и подтвердить свои компетенции на отечественной платформе. Эксперимент по её внедрению начнётся 14 февраля 2025 года и продлится до…
🤡16😁6👍2🔥1💊1
Представлен новый рейтинг TIOBE. Его авторы отмечают продвижение «быстрых» языков, которые позволяют обрабатывать растущие объёмы данных в условиях, когда «железо» не может удовлетворять рост потребностей.
Так, на втором месте C++, Go прочно вошёл в топ-10, а Rust достиг рекордной доли на рынке в 1,47%. В топ-50 пытаются войти языки Mojo и Zig, которые уже занимают 51-ю и 56-ю позиции соответственно.
Особняком стоит Python, который занимает 1-е место и известен как медленный язык. Это потому, что в настоящее время есть еще один драйвер, кроме производительности: насколько легко выучить новый язык программирования. Авторы рейтинга связывают это с простотой языка и с тем, что рынку требуется больше программистов, при этом вузы не закрывают потребность в инженерах ПО, а в программирование приходят специалисты из других сфер, которые предпочитают Python.
Так, на втором месте C++, Go прочно вошёл в топ-10, а Rust достиг рекордной доли на рынке в 1,47%. В топ-50 пытаются войти языки Mojo и Zig, которые уже занимают 51-ю и 56-ю позиции соответственно.
Особняком стоит Python, который занимает 1-е место и известен как медленный язык. Это потому, что в настоящее время есть еще один драйвер, кроме производительности: насколько легко выучить новый язык программирования. Авторы рейтинга связывают это с простотой языка и с тем, что рынку требуется больше программистов, при этом вузы не закрывают потребность в инженерах ПО, а в программирование приходят специалисты из других сфер, которые предпочитают Python.
9 вариантов использования баз данных NoSQL
1 - MongoDB (хранилище документов)
Используется для систем управления контентом и управления каталогами. Имеет формат BSON, дизайн без схем, поддерживает горизонтальное масштабирование с шардингом и высокую доступность с репликацией.
2 - Cassandra (хранение данных в широких столбцах)
Идеально подходит для управления данными временных рядов и рекомендательных механизмов. Предлагает широкостолбцовый формат, распределенную архитектуру и CQL для SQL-подобных запросов.
3 - Redis (хранилище ключей и значений)
Подходит для кэширования, управления сеансами и т.п. Предоставляет хранилище в памяти, поддержку сложных структур данных и параметры сохранения с RDB и AOF.
4 - Couchbase (хранилище документов с ключом-значением)
Используется для систем управления контентом и платформ электронной коммерции. Сочетает операции на основе ключей и документов с архитектурой, ориентированной на память, и репликацией между центрами обработки данных.
5 - Neo4j (БД на основе графов)
Отлично подходит для социальных сетей и обнаружения мошенничества. Соответствует требованиям ACID, имеет смежность без индексов, язык запросов Cypher и возможности кластера HA.
6 - Amazon DynamoDB (ключ-значение и документ)
Идеально подходит для бессерверных и IoT-приложений. Поддерживает как данные «ключ-значение», так и сложные данные документов, управляемые AWS, с такими функциями, как разделение данных по узлам и потоки DynamoDB.
7 - Apache Hbase (хранение данных в широких столбцах)
Используется для хранилища данных и крупномасштабной обработки данных. Создан по образцу Google Bigtable, предлагает интеграцию с Hadoop, автоматическое шардинг, сильную согласованность и региональные серверы.
8 - Elasticsearch (поисковая система)
Идеально подходит для полнотекстового поиска, анализа данных журналов и событий. Создан на базе Apache Lucene, ориентирован на документы, с возможностями шардинга и репликации, а также интерфейсом RESTful.
9 - CouchDB (хранилище документов)
Подходит для мобильных приложений и CMS. Ориентирован на документы, обеспечивает согласованность данных без блокировки, поддерживает конечную согласованность и использует RESTful API.
1 - MongoDB (хранилище документов)
Используется для систем управления контентом и управления каталогами. Имеет формат BSON, дизайн без схем, поддерживает горизонтальное масштабирование с шардингом и высокую доступность с репликацией.
2 - Cassandra (хранение данных в широких столбцах)
Идеально подходит для управления данными временных рядов и рекомендательных механизмов. Предлагает широкостолбцовый формат, распределенную архитектуру и CQL для SQL-подобных запросов.
3 - Redis (хранилище ключей и значений)
Подходит для кэширования, управления сеансами и т.п. Предоставляет хранилище в памяти, поддержку сложных структур данных и параметры сохранения с RDB и AOF.
4 - Couchbase (хранилище документов с ключом-значением)
Используется для систем управления контентом и платформ электронной коммерции. Сочетает операции на основе ключей и документов с архитектурой, ориентированной на память, и репликацией между центрами обработки данных.
5 - Neo4j (БД на основе графов)
Отлично подходит для социальных сетей и обнаружения мошенничества. Соответствует требованиям ACID, имеет смежность без индексов, язык запросов Cypher и возможности кластера HA.
6 - Amazon DynamoDB (ключ-значение и документ)
Идеально подходит для бессерверных и IoT-приложений. Поддерживает как данные «ключ-значение», так и сложные данные документов, управляемые AWS, с такими функциями, как разделение данных по узлам и потоки DynamoDB.
7 - Apache Hbase (хранение данных в широких столбцах)
Используется для хранилища данных и крупномасштабной обработки данных. Создан по образцу Google Bigtable, предлагает интеграцию с Hadoop, автоматическое шардинг, сильную согласованность и региональные серверы.
8 - Elasticsearch (поисковая система)
Идеально подходит для полнотекстового поиска, анализа данных журналов и событий. Создан на базе Apache Lucene, ориентирован на документы, с возможностями шардинга и репликации, а также интерфейсом RESTful.
9 - CouchDB (хранилище документов)
Подходит для мобильных приложений и CMS. Ориентирован на документы, обеспечивает согласованность данных без блокировки, поддерживает конечную согласованность и использует RESTful API.
👍1🤝1
Модель Pub/Sub (Издатель-Подписчик)
Распределенные системы должны управлять масштабируемыми, отвязанными друг от друга компонентами. Шаблон обмена сообщениями «публикация-подписка» (publish-subscribe) позволяет это сделать, предоставляя асинхронное, событийное распределение сообщений
В этом процессе участвуют три элемента: издатели (publishers), темы и подписчики (subscribers). Подписываясь на тему, подписчики (Subscribers) сообщают системе, какие сообщениях они хотят получать. Издатели (Publishers) отправляют сообщения по темам, не зная, кому именно отправляется сообщение. Затем брокер сообщений или шина событий пересылает эти сообщения соответствующим подписчикам.
Соцсети и мессенджеры обладают рядом функций, которые идеально подходят для этой модели.
Отправители и получатели сообщений отвязаны друг от друга в модели Pub/Sub. Это ведет к большей масштабируемости, гибкости и отказоустойчивости. В итоге эта модель часто применяется в распределенных системах с большим объемом коммуникации между узлами
Распределенные системы должны управлять масштабируемыми, отвязанными друг от друга компонентами. Шаблон обмена сообщениями «публикация-подписка» (publish-subscribe) позволяет это сделать, предоставляя асинхронное, событийное распределение сообщений
В этом процессе участвуют три элемента: издатели (publishers), темы и подписчики (subscribers). Подписываясь на тему, подписчики (Subscribers) сообщают системе, какие сообщениях они хотят получать. Издатели (Publishers) отправляют сообщения по темам, не зная, кому именно отправляется сообщение. Затем брокер сообщений или шина событий пересылает эти сообщения соответствующим подписчикам.
Соцсети и мессенджеры обладают рядом функций, которые идеально подходят для этой модели.
Отправители и получатели сообщений отвязаны друг от друга в модели Pub/Sub. Это ведет к большей масштабируемости, гибкости и отказоустойчивости. В итоге эта модель часто применяется в распределенных системах с большим объемом коммуникации между узлами
👍7🔥1👏1
Memcached представляет распространенную систему кэширования в памяти.
Memcached изначально был создан 2003 для решения проблемы производительности в LiveJournal, популярной платформе для ведения блогов. Изначално он был написан на 𝐏𝐞𝐫𝐥, но вскоре переписан на 𝐂.
Идея была проста => хранить часто используемые данные в памяти, чтобы избежать повторного обращения к базе данных.
В 2004 году Memcached стал проектом с открытым исходным кодом.
Основные характеристики:
◾️ Memcached — это быстрая распределенная система кэширования в памяти, используемая для ускорения работы приложений за счет хранения данных в оперативной памяти.
◾️ Он работает путем хранения пар «ключ-значение» и их быстрого извлечения при необходимости.
◾️ Это снижает необходимость доступа к более медленным источникам данных, таким как базы данных, что приводит к сокращению времени отклика и повышению производительности.
◾️ Memcached особенно эффективен для кэширования часто используемых данных, таких как результаты запросов к базе данных, ответы API и информация о сеансе.
Вкратце процесс работы
Приложение отправляет команду 𝐬𝐞𝐭
◾️ Приложение указывает ключ, значение и (необязательно) срок действия.
◾️ Узел Memcached вычисляет хэш ключа, чтобы определить, где хранить элемент в своей хэш-таблице.
Приложение отправляет команду 𝐠𝐞𝐭 -
◾️ Приложение предоставляет ключ.
◾️ Узел Memcached вычисляет хэш, находит элемент в хэш-таблице и возвращает значение приложению.
Основные компоненты
[1.] Хэш-таблица
◾️ Memcached использует большую хеш-таблицу, находящуюся в оперативной памяти, для хранения пар ключ-значение.
◾️ Это обеспечивает быстрый поиск со сложностью O(1).
[2.] Алгоритм удаления LRU
◾️ Memcached имеет фиксированный объем памяти.
◾️ Когда он заполняется, он применяет алгоритм LRU, который удаляет старые, наименее используемые элементы, освобождая место для новых.
[3.] Распределение памяти на блоки
◾️ Для эффективного управления памятью Memcached делит выделенную память на «блоки» разных размеров.
◾️ Это предотвращает фрагментацию памяти и повышает производительность.
[4.] Простой текстовый протокол
◾️ Memcached взаимодействует с клиентами (вашими приложениями) с помощью простого текстового протокола.
[5.] Распределенная архитектура
◾️ Memcached можно развернуть на нескольких серверах.
◾️ Это позволяет масштабировать его горизонтально и обеспечивает отказоустойчивость.
Ограничения
[1.] Данные не сохраняются
◾️ Данные теряются в случае сбоя или перезапуска сервера, поскольку Memcached хранит данные исключительно в памяти.
[2.] Отсутствие резервирования данных
◾️ Если вы используете один экземпляр Memcached, то нет встроенного резервирования для защиты от потери данных.
[3.] Ограниченные типы данных
◾️ Данные хранятся в виде простых пар «ключ-значение», что может не подходить для сложных структур данных.
Если несколько клиентов одновременно запрашивают кэшированный элемент, срок действия которого истек, они все могут одновременно обратиться к внутренней базе данных, что приведет к проблемам с производительностью.
Memcached изначально был создан 2003 для решения проблемы производительности в LiveJournal, популярной платформе для ведения блогов. Изначално он был написан на 𝐏𝐞𝐫𝐥, но вскоре переписан на 𝐂.
Идея была проста => хранить часто используемые данные в памяти, чтобы избежать повторного обращения к базе данных.
В 2004 году Memcached стал проектом с открытым исходным кодом.
Основные характеристики:
◾️ Memcached — это быстрая распределенная система кэширования в памяти, используемая для ускорения работы приложений за счет хранения данных в оперативной памяти.
◾️ Он работает путем хранения пар «ключ-значение» и их быстрого извлечения при необходимости.
◾️ Это снижает необходимость доступа к более медленным источникам данных, таким как базы данных, что приводит к сокращению времени отклика и повышению производительности.
◾️ Memcached особенно эффективен для кэширования часто используемых данных, таких как результаты запросов к базе данных, ответы API и информация о сеансе.
Вкратце процесс работы
Приложение отправляет команду 𝐬𝐞𝐭
◾️ Приложение указывает ключ, значение и (необязательно) срок действия.
◾️ Узел Memcached вычисляет хэш ключа, чтобы определить, где хранить элемент в своей хэш-таблице.
Приложение отправляет команду 𝐠𝐞𝐭 -
◾️ Приложение предоставляет ключ.
◾️ Узел Memcached вычисляет хэш, находит элемент в хэш-таблице и возвращает значение приложению.
Основные компоненты
[1.] Хэш-таблица
◾️ Memcached использует большую хеш-таблицу, находящуюся в оперативной памяти, для хранения пар ключ-значение.
◾️ Это обеспечивает быстрый поиск со сложностью O(1).
[2.] Алгоритм удаления LRU
◾️ Memcached имеет фиксированный объем памяти.
◾️ Когда он заполняется, он применяет алгоритм LRU, который удаляет старые, наименее используемые элементы, освобождая место для новых.
[3.] Распределение памяти на блоки
◾️ Для эффективного управления памятью Memcached делит выделенную память на «блоки» разных размеров.
◾️ Это предотвращает фрагментацию памяти и повышает производительность.
[4.] Простой текстовый протокол
◾️ Memcached взаимодействует с клиентами (вашими приложениями) с помощью простого текстового протокола.
[5.] Распределенная архитектура
◾️ Memcached можно развернуть на нескольких серверах.
◾️ Это позволяет масштабировать его горизонтально и обеспечивает отказоустойчивость.
Ограничения
[1.] Данные не сохраняются
◾️ Данные теряются в случае сбоя или перезапуска сервера, поскольку Memcached хранит данные исключительно в памяти.
[2.] Отсутствие резервирования данных
◾️ Если вы используете один экземпляр Memcached, то нет встроенного резервирования для защиты от потери данных.
[3.] Ограниченные типы данных
◾️ Данные хранятся в виде простых пар «ключ-значение», что может не подходить для сложных структур данных.
Если несколько клиентов одновременно запрашивают кэшированный элемент, срок действия которого истек, они все могут одновременно обратиться к внутренней базе данных, что приведет к проблемам с производительностью.
👍7❤1
Как масштабировать компонент?
✅ Вертикальное и горизонтальное масштабирование
Самый простой способ масштабирования компонента — вертикальное масштабирование.
Стандартная стратегия - увеличение объема оперативной памяти., больший диск или более мощный процессор.
Экономически эффективно в краткосрочной перспективе. Плюс, избегаем усложения, которое есть в распределенных архитектурах
Но в долгосрочной перспективе становится дорогостоящим и не позволяет увеличить отказоустойчивость
Горизонтальное масштабирование компонента происходит путем добавления большего количества машин.
✅ Горизонтальное масштабирование приложений без сохранения состояния
Компонент без сохранения состояния не сохраняет клиентские данные из одного сеанса для использования в следующем сеансе. Это облегчает горизонтальное масштабирование.
Для распределения запросов между несколькими компонентами без сохранения состояния можно использовать балансировщик нагрузки.
✅ Горизонтально масштабируемые компоненты с отслеживанием состояния
Компонент с отслеживанием состояния сохраняет данные из одного сеанса в следующий.
Например, веб-приложение, которое хранит информацию о сеансе. Или база данных/хранилище ключей и значений.
Для масштабирования компонентов с отслеживанием состояния придется использовать такие методы, как репликация, сегментирование и т. д.
👉 НЕкоторые аспекты:
- Вертикальное масштабирование менее сложное, и обычно подходит для большинства приложений.
- На горизонтальное масштабирование обычно переходят, когда вертикальное масштабирование больше не является экономически эффективным.
- Сначала лучше построить уровень приложения без сохранения состояния, иак как его легче масштабировать.
- Для компонентов с сохранением состояния, таких как базы данных, лучше выбирать современные варианты, разработанные для горизонтальной масштабируемости.
✅ Вертикальное и горизонтальное масштабирование
Самый простой способ масштабирования компонента — вертикальное масштабирование.
Стандартная стратегия - увеличение объема оперативной памяти., больший диск или более мощный процессор.
Экономически эффективно в краткосрочной перспективе. Плюс, избегаем усложения, которое есть в распределенных архитектурах
Но в долгосрочной перспективе становится дорогостоящим и не позволяет увеличить отказоустойчивость
Горизонтальное масштабирование компонента происходит путем добавления большего количества машин.
✅ Горизонтальное масштабирование приложений без сохранения состояния
Компонент без сохранения состояния не сохраняет клиентские данные из одного сеанса для использования в следующем сеансе. Это облегчает горизонтальное масштабирование.
Для распределения запросов между несколькими компонентами без сохранения состояния можно использовать балансировщик нагрузки.
✅ Горизонтально масштабируемые компоненты с отслеживанием состояния
Компонент с отслеживанием состояния сохраняет данные из одного сеанса в следующий.
Например, веб-приложение, которое хранит информацию о сеансе. Или база данных/хранилище ключей и значений.
Для масштабирования компонентов с отслеживанием состояния придется использовать такие методы, как репликация, сегментирование и т. д.
👉 НЕкоторые аспекты:
- Вертикальное масштабирование менее сложное, и обычно подходит для большинства приложений.
- На горизонтальное масштабирование обычно переходят, когда вертикальное масштабирование больше не является экономически эффективным.
- Сначала лучше построить уровень приложения без сохранения состояния, иак как его легче масштабировать.
- Для компонентов с сохранением состояния, таких как базы данных, лучше выбирать современные варианты, разработанные для горизонтальной масштабируемости.