Шпаргалка по перенаправлениям системы ввода-вывода в Linux #linux

Монолит или Микросервисы

Монолит или Микросервисы

𝟏. Что такое Монолит?
Монолитная архитектура — это традиционный подход, при котором все части пользовательского интерфейса приложения, бизнес-логики, доступа к данным создаются и развертываются как единое, тесно связанное целое. Все компоненты используют одну и ту же кодовую базу и напрямую связаны, что означает, что любое изменение требует повторного развертывания всего приложения.

2. Что такое Микросервисы?
Микросервисы разбивают приложение на набор небольших независимых сервисов. Каждый сервис фокусируется на определенной бизнес-возможности, работает в своем собственном процессе и взаимодействует с другими через API. Их можно разрабатывать, развертывать и масштабировать независимо.

3. Монолит: Плюсы и минусы
Плюсы:
🔹 Простота разработки, тестирования и развертывания — отлично подходит для небольших команд и проектов
🔹 Более простая отладка, поскольку все находится в одном месте
🔹 Немного более высокая производительность для внутренней коммуникации

Минусы:
🔹 Трудно масштабировать отдельные функции; необходимо масштабировать все приложение
🔹 Сильная связанность — изменения в одной части могут повлиять на всю систему
🔹 Трудно самостоятельно внедрять новые технологии или реорганизовывать отдельные компоненты
🔹 Риск полного отказа в случае выхода из строя одного компонента

4. Микросервисы: Плюсы и минусы
Плюсы:
🔹 Слабосвязанные сервисы могут обновляться, развертываться или масштабироваться независимо.
🔹 Организация на основе бизнес-возможностей, что позволяет создавать специализированные команды разработчиков, которые занимаются отдельными компонентами независимо друг от друга
🔹 БОлее лучшая масштабируемость и устойчивость: сбой в одной службе не приводит к сбою всего приложения.
🔹 Хорошо работает с облачными и CI/CD-конвейерами.

Минусы:
🔹 Более сложная разработка, тестирование и отладка из-за распределенной природы.
🔹 Требует надежного DevOps, мониторинга и межсервисного взаимодействия.
🔹 Более высокие первоначальные затраты на настройку и инфраструктуру.

5. Когда что выбирать?
🔹 Монолит: лучше всего подходит для небольших проектов, MVP или команд, впервые работающих с распределенными системами.
🔹 Микросервисы: идеально подходят для крупных, сложных или быстро развивающихся приложений, где приоритетами являются масштабируемость, устойчивость и независимое развертывание.

👉 Монолиты предлагают простоту и скорость для небольших проектов, в то время как микросервисы обеспечивают гибкость и масштабируемость для сложных современных приложений. Правильный выбор зависит от размера вашего проекта, опыта команды и долгосрочных целей.

Два дня назад в облачных сервисах Google произошел крупный глобальный сбой. Как сообщили в компании, причиной сбоя стал нулевой указатель - отсутствовала обработка на нулевой указатель, который допускался данным кодом. ПРичем ошибка произошла в новом коде, развертывание которого началось 29 мая 2025 года 🤔

https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

В руководство по языку Go добавлена серия статей про Пакеты и модули
https://metanit.com/go/tutorial/5.1.php
#go #golang

Шпаргалка ко командар Docker

Вкратце схема по созданию сократителя ссылок

Управление памятью Java: Сборка мусора

𝟏) Что такое сборка мусора
Сборка мусора (GC) — это автоматизированный процессдля освобождения памяти путем удаления объектов, которые больше не нужны или на которые не ссылается приложение. Это помогает предотвратить утечки памяти и обеспечивает эффективную работу приложения.

𝟐) Как она работает?
В основе сборки мусора в Java лежит алгоритм Mark and Sweep (отметить и убрать):

🔹𝗠𝗮𝗿𝗸: GC начинает с корневых ссылок (таких как статические переменные, активные потоки и стеки методов) и помечает все достижимые объекты как «используемые».
🔹𝗦𝘄𝗲𝗲𝗽: Затем GC сканирует кучу на предмет объектов, не помеченных как «используемые», и освобождает их память, делая ее доступной для новых выделений.

𝟑) Когда выполняется сборка мусора?
Сборщик мусора может быть запущен автоматически JVM в следующих случаях:
🔹 Куча заполнена или близка к заполнению.
🔹 Куча старого поколения достигает порога.
🔹 Область памяти PermGen/Metaspace заполнена (в зависимости от версии Java).
🔹 Вручную вызван метод System.gc()

𝟒) Сборка мусора для поколений
Современные JVM делят кучу на поколения (молодые, старые и иногда ряд других). Большинство объектов умирают молодыми, поэтому GC фокусируется на молодом поколении для частой и быстрой очистки, в то время как старые объекты собираются реже, но более тщательно.

𝟓) Оптимизация
После очистки некоторые сборщики уплотняют память, перемещая активные объекты вместе, что снижает фрагментацию и ускоряет выделение памяти для новых объектов.

𝟔) Почему это важно?
Автоматическая сборка мусора освобождает разработчиков от ручного управления памятью (в отличие от C/C++), уменьшая количество ошибок, таких как утечки памяти и висячие указатели, и позволяя вам сосредоточиться на создании функций, а не на отслеживании памяти.

#java

Сравнение дизайна Liquid Glass («Жидкое стекло») на разных версиях iOS

B+ trees (Деревья B+) и их применение в базах данных

Деревья B+ являются наиболее широко используемой структурой данных для индексирования в современных реляционных системах баз данных. Они специально разработаны для эффективного хранения и извлечения больших объемов данных на диске, обеспечивая высокую производительность поиска, вставки, удаления и запросов диапазона.
Основные реляционные базы данных, такие как MySQL (InnoDB), PostgreSQL, SQL Server и Oracle, используют деревья B+ для первичных и вторичных индексов, что делает их незаменимыми для масштабируемых, высокопроизводительных систем баз данных.

КЛЮЧЕВЫЕ ХАРАКТЕРИСТИКИ

- Все данные в листовых узлах
В B+ дереве все фактические данные записей (или указатели на полные записи) хранятся исключительно в листовых узлах. Внутренние узлы хранят только ключи и указатели на дочерние узлы, облегчая навигацию.

- Сбалансированная, многоуровневая структура
B+ деревья всегда сбалансированы по высоте. Все листовые узлы находятся на одной глубине, обеспечивая сложность O(log n) для операций поиска, вставки и удаления, независимо от размера базы данных.

- Эффективные запросы диапазона и упорядоченные запросы
Листовые узлы связаны вместе в двунаправленном списке, что позволяет быстро выполнять последовательный доступ для запросов диапазона, таких как BETWEEN, ORDER BY и сканирование индексов.

- Высокая степень заполнения
Каждый узел может содержать много ключей (высокая степень заполнения), что минимизирует высоту дерева и уменьшает дисковый ввод-вывод за счет максимизации данных на чтение.

- Оптимизация диска
B+ деревья разработаны для соответствия размерам блоков диска, что уменьшает количество обращений к диску, необходимых для операций.


ПОЧЕМУ B+ ДЕРЕВЬЯ ПРЕДПОЧИТАЮТСЯ В БАЗАХ ДАННЫХ?

- Сбалансированная структура обеспечивает последовательный доступ.

- Высокая степень заполнения соответствует размерам страниц диска, уменьшая ввод-вывод.

- Связанные листья делают сканирование диапазона быстрым.

- Узлы могут быть разделены/объединены с минимальным блокированием, поддерживая высококонкурентные среды.

ИСПОЛЬЗОВАНИЕ В ОСНОВНЫХ СИСТЕМАХ БАЗ ДАННЫХ

- MySQL (InnoDB)
Кластерный индекс (первичный ключ): хранит всю строку данных в B+ дереве.
Вторичные индексы: B+ деревья содержат индексированные столбцы и указатели на первичный ключ.

- PostgreSQL
Тип индекса по умолчанию (btree) для большинства столбцов.
Используется для уникальных и неуникальных индексов.
Поддерживает эффективные запросы на равенство и диапазон.

- СУБД Oracle
B+ деревья используются для стандартных индексов (одиночные, составные, основанные на функциях).
Организованные таблицы индексов (IOT) хранят все данные в листовых блоках B+ дерева.
Листовые блоки связаны для сканирования диапазона.

#database

Управление памятью. Стек и куча (heap) в C и Java
В языке C управление памятью осуществляется с помощью malloc и free.
В Java JVM управляет памятью с помощью сборки мусора.

Как происходит выполнение SQL-запроса в базе данных #sql

Запуск ChatGPT загрязнил мир навсегда, как и первые испытания атомного оружия
Запуск ChatGPT от OpenAI 30 ноября 2022 года изменил мир подобно взрыву первой атомной бомбы. Стремительный рост ChatGPT и целая плеяда последовавших генеративных моделей конкурентов уже загрязнили интернет таким количеством ненужного хлама, что это уже тормозит развитие ИИ.
Генеративные модели уже создали большое количество контента — достаточное, чтобы другие ИИ обучались именно на их творениях. В результате это напоминает игру в «испорченный телефон», в которой все игроки стремительно «глупеют». В индустрии такой сценарий развития называют «коллапсом модели».
Проявляется и другой эффект: данные из той версии интернета, которая предшествовала активному росту ChatGPT и других ИИ, стали представлять чрезвычайную ценность.
Сотрудник Центра изучения экзистенциального риска при Кембриджском университете Морис Чиодо заявил, что использование данных, произведенных до 2022 года, позволяет быть уверенным в минимальном наличии «загрязнения» от ИИ. А более поздние данные нельзя назвать «безопасными, хорошими и чистыми»
https://www.theregister.com/2025/06/15/ai_model_collapse_pollution/

Глава Amazon предупредил сотрудников о сокращениях из-за ИИ
Из-за внедрения искусственного интеллекта в бизнес-процессы Amazon «понадобится меньше людей для выполнения некоторых видов задач», предупредил Энди Джасси. С 2022 года компания уволила 27 тыс. сотрудников
Генеральный директор Amazon Энди Джасси в служебной записке для сотрудников предупредил о сокращении штата в ближайшие несколько лет из-за планов активнее задействовать искусственный интеллект и выполнении различных задач.

Внедрение генеративного ИИ должно «изменить способ выполнения работы» в компании, заявил Джасси. «Нам понадобится меньше людей для выполнения некоторых видов задач, и больше для других», — написал глава Amazon, добавив, что прогнозировать результаты в долгосрочной перспективе сложно.

Джасси также призвал сотрудников «интересоваться ИИ» и тем, как его использовать. «Те, кто примет эти изменения, освоит ИИ, поможет нам совершенствовать наши возможности, <...> смогут помочь нам преобразовать компанию», — написал он.
https://www.rbc.ru/business/18/06/2025/6852179c9a7947a95cf80522

Аутентификация на основе сессий и JWT

Аутентификация на основе сессий и JWT (описание к предыдущему посту)

Большинство веб-приложений выбирают один из двух путей входа: сессии (при которых состояние хранится на сервере) или JWT (при которых состояние передается вместе с клиентом).

1. Аутентификация на основе сессий
При входе пользователя бэкенд создает случайный идентификатор сессии, сохраняет его в кэше или базе данных и устанавливает этот идентификатор в виде HTTP-only куки-файла в браузере. Каждый раз при отправке запроса браузер передает куки, сервер проверяет запись сессии и восстанавливает контекст пользователя. Это позволяет хранить конфиденциальные данные на стороне сервера и мгновенно завершать сеанс путем удаления записи.

Почему стоит выбрать сессии:

✅ Мгновенное аннулирование ("выйти везде") — достаточно удалить строку из Redis или SQL.

✅ Никакие секретные ключи никогда не покидают бэкэнд, снижая риск случайного раскрытия.

✅ Подходит для небольших и средних систем, где общий кэш не является узким местом.

Однако будьте осторожны: горизонтальное масштабирование зачастую требует либо прикрепленных сессий, либо реплицированного кеша, что может привести к увеличению задержки и усложнению операций.

2. Аутентификация на основе JWT
После успешного входа сервер подписывает JSON Web Token, содержащий заголовок (alg, typ), полезную нагрузку (например, поля вроде sub или role) и подпись. Токен кодируется в Base64, но не шифруется, позволяя любому прочитать содержимое полезной нагрузки, однако подделать токен может лишь тот, кто владеет секретным ключом. Сервер не хранит никакого состояния, любой узел сети способен проверить подпись и доверять заявленным данным.

Почему стоит рассмотреть использование JWT:

⚡️ Бессессионность: каждый микросервис или пограничный узел может локально проверять токены, исключая необходимость общего хранилища.

⚡️ Отлично подходит для SPA-приложений и мобильных приложений, непосредственно обращающихся к нескольким бекенд-сервисам.

⚡️ Легковесность: легко помещается в заголовок Authorization или куки.

Обратите внимание, что однажды выданный JWT остается действительным вплоть до истечения срока его действия; отозвать его без дополнительной инфраструктуры невозможно, что делает блокировку аккаунта или экстренный выход сложными задачами.

Таким образом, если вам важнее всего возможность отзывания доступа, придерживайтесь серверных сессий.

Если вам нужно масштабирование приложения без сохранения состояния, то подписанные JWT — это то, что вам нужно, но при проектировании учитывайте тот факт, что вы не сможете отозвать их обратно, как только они появятся в открытом доступе.

В руководство по языку Go добавлены новые статьи

Строки и руны
https://metanit.com/go/tutorial/4.6.php

Пакет string. Операции со строками
https://metanit.com/go/tutorial/4.7.php

#go #golang