Как работает модель протокола TCP/IP

Распространенные три стратегии замещения кеша:

FIFO (First In, First Out) — стратегия, при которой замещается самая старая строка в кэше. Это означает, что данные, которые были добавлены в кэш первыми, будут удалены первыми.

LRU (Least Recently Used) — стратегия, при которой замещается строка, к которой дольше всего не было обращений. Это позволяет сохранять наиболее часто используемые данные в кэше.

Time Aware LRU — модифицированная версия LRU, которая учитывает время последнего обращения к данным. Это может быть полезно для оптимизации производительности в системах с переменной частотой использования данных.

Схема работы PostgreSQL, которая включает основные компоненты и процессы системы

Схема работы PostgreSQL, которая включает основные компоненты и процессы системы
(продолжение предыдущего поста)

1. Web Application: Веб-приложения подключаются к PostgreSQL через соединения (Connection 1, Connection 2, Connection 3). Каждое соединение создает фоновый процесс (Background Process), который обрабатывает запросы.

2. Фоновые процессы (Background Processes):
- Эти процессы работают в фоновом режиме и выполняют задачи, такие как обработка запросов, управление буферами и синхронизация данных.
- Они используют разделяемую память (Shared Memory) для обмена данными между процессами.

3. Разделяемая память (Shared Memory):
- Содержит буферы (Shared Buffers), которые используются для временного хранения данных.
- Включает WAL Buffers для буферизации журнала предзаписи (Write-Ahead Logging).
- Также содержит CLOG Buffers и Temp Buffers для управления транзакциями и временными данными.

4. Вспомогательные процессы (Auxiliary Processes):
- BG Writer: Записывает данные из буферов в файлы данных.
- WAL Writer: Записывает журнал предзаписи (WAL) на диск.
- Auto Vacuum: Автоматически очищает ненужные данные.
- Checkpointer: Обеспечивает целостность данных при перезагрузке системы.
- Stats Collector: Собирает статистику о работе системы.
- SysLogger: Записывает системные журналы.
- Archiver: Архивирует данные.
- Replication Launcher: Управляет репликацией данных.

5. Postmaster Process:
- Главный процесс, который управляет всеми другими процессами и обеспечивает их взаимодействие.

6. Физические файлы:
- Data Files: Файлы данных, где хранятся таблицы и другие объекты.
- WAL Files: Файлы журнала предзаписи.
- Archive Files: Архивированные файлы.
- Log Files: Системные журналы.

В Госдуме опровергли слухи о том, что MAX будет "оформлять доносы"
Депутат Немкин заявил, что мессенджер MAX не может оформлять доносы с помощью ИИ

"На смартфонах большинства граждан давно установлены сервисы крупнейших компаний и госструктур — Сбер, ВТБ, "Госуслуги". За все годы их работы не было ни одного факта использования встроенного ИИ для "доносов" или отслеживания личных действий пользователей", — добавил Немкин.
Как он пояснил, распространение подобных мифов — это способ посеять недоверие к отечественным цифровым продуктам.
"На практике же MAX проходит те же самые проверки безопасности и соответствует тем же правилам, что и другие популярные приложения. Его главная задача — обеспечить удобную и защищённую коммуникацию, а не заниматься слежкой", — заключил депутат.
https://ria.ru/20250903/max-2039498307.html

Проект Primes - проект от бывшего инженера Microsoft для вычисления быстроты/эффективности различных языков программирования на основе вычисления простых чисел
https://github.com/PlummersSoftwareLLC/Primes
Результаты по различным языкам и для разных комбинаций и архитектур можно постротеть здесь https://plummerssoftwarellc.github.io/PrimeView/?rc=50&rs=0&fr=&sc=rc&sd=True
В целом такие языки C/ C++ / Zig / Rust по тесту являются наиболее быстрыми

Шаблон повторных попыток (Retry Pattern)
(описание в следующем посте)

Шаблон повторных попыток (Retry Pattern)
(описание к предыдущему посту)

Это один из самых простых способов повысить отказоустойчивость системы. Как это работает:

1. Не выполняйте повторные попытки бесконечно
Повторные попытки имеют свою цену.

* Слишком мало попыток: вы можете сдаться при временных сбоях (например, кратковременном сетевом сбое).
* Слишком много попыток: вы перегружаете систему, увеличиваете время отклика и маскируете реальные проблемы.

Практическое правило: обычно оптимальным является 3 попытки. После этого более вероятно, что вы имеете дело с реальным сбоем, а не с временным.

2. Используйте экспоненциальную отсрочку
Время повторных попыток важнее их количества.

* Без таймата: все неудачные запросы повторяются мгновенно → увеличивается перегрузка системы.
* С экспоненциальной отсрочкой (таймаутом): время ожидания увеличивается (например, 1 с → 2 с → 4 с → 8 с), давая системам время на восстановление.

Это предотвращает превращение повторных попыток в проблему.

3. Выполняйте повторные попытки только при временных ошибках
Не каждая ошибка заслуживает повторной попытки.

* Подходящие для повтора: 408 (тайм-аут), 5xx (сервер перегружен).
* Неподходящие для повтора: 400 (неверный запрос), 403 (запрещено).

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

Если торговый автомат показывает «временно не работает», попробуйте позже. Если он говорит «вставьте 5 долларов, а не 1», повторная попытка не поможет.

4. Комбинируйте с паттерном Circuit Breaker (предохранитель)
Одни только повторные попытки могут вызвать каскадные сбои, если сервис действительно не работает. Circuit Breaker добавляет защиту:

* Отслеживает частоту сбоев.
* Открывается, когда количество сбоев превышает порог → останавливает повторные попытки на некоторое время.
* Закрывается, когда состояние улучшается.

9 базовых архитектурных паттернов интеграции систем
(описание в следующем посте)

9 базовых архитектурных паттернов интеграции систем:
(описание к предыдущему посту)

1. Peer-to-Peer (P2P)
Децентрализованная сеть, где каждый участник (пир) может быть одновременно отправителем и получателем данных. Пример: обмен файлами через BitTorrent.

2. API Gateway
Центральный компонент, который управляет входящими запросами, выполняет маршрутизацию, авторизацию, ограничение скорости и другие задачи. Пример: Spring Cloud Gateway.

3. Pub-Sub (Publish-Subscribe)
Модель обмена сообщениями, где издатели отправляют сообщения в темы, а подписчики получают их. Пример: системы уведомлений.

4. Request-Response
Классическая модель клиент-сервер, где клиент отправляет запрос, а сервер возвращает ответ. Пример: HTTP-запросы.

5. Event Sourcing
Подход, при котором система сохраняет все изменения состояния в виде последовательности событий. Пример: журнал событий для восстановления состояния системы.

6. ETL (Extract, Transform, Load)
Процесс извлечения данных из источников, их преобразования и загрузки в хранилище. Пример: миграция данных между системами.

7. Batching
Обработка данных пакетами для повышения эффективности. Пример: массовая обработка платежей.

8. Streaming Processing
Обработка потоков данных в реальном времени. Пример: анализ логов приложений.

9. Orchestration
Управление последовательностью выполнения задач между сервисами. Пример: координация микросервисов в сложной системе.

9 рекомендаций по работе с Docker, которые помогут оптимизировать работу с контейнерами
(продолжение в следующем посте)

9 рекомендаций по работе с Docker, которые помогут оптимизировать работу с контейнерами:
(продолжение предыдущего поста)

1. Используйте официальные образы
Использование официальных образов Docker обеспечивает безопасность, надежность и регулярные обновления. Пример: FROM node:14-alpine.

2. Используйте конкретные версии
Указание конкретной версии образа предотвращает неожиданные изменения. Пример: FROM node:14.17.0-alpine3.13.

3. Многоступенчатые сборки
Многоступенчатые сборки уменьшают размер финального образа, исключая инструменты сборки и зависимости. Пример:

   FROM build-image AS build  
   # Build steps  
   FROM production-image  
   COPY --from=build /app /app  
   

4. Используйте файл .dockerignore
Файл .dockerignore исключает ненужные файлы из контекста сборки, ускоряя процесс и уменьшая размер образа. Пример содержимого:

  
   node_modules  
   npm-debug.log  
   

5. Наименьшие привилегии
Запуск приложений с правами непривилегированного пользователя повышает безопасность. Пример:

   RUN useradd -m myuser  
   USER myuser  
   CMD node index.js  
   

6. Используйте переменные окружения
Использование переменных окружения увеличивает переносимость приложения между средами. Пример:

   ENV APP_HOME /app  
   WORKDIR $APP_HOME  
   

7. Порядок инструкций важен для кэширования
Порядок инструкций в Dockerfile влияет на эффективность кэширования. Рекомендуется начинать с менее изменяемых команд. Пример:

   FROM debian  
   RUN apt-get update  
   RUN apt-get -y install openjdk ssh vim  
   COPY . /app  
   CMD ["java", "-jar", "/app/target/app.jar"]  
   

8. Имена для образов
Назначение имен для образов помогают организовать и управлять образами. Пример:

   LABEL maintainer="name@example.com"  
   LABEL version="1.0"  
   

9. Сканирование образов
Проверка образов на уязвимости с помощью команды docker scan помогает предотвратить проблемы безопасности.

#docker

Линус Торвальдс поясняет Биллу Гейтсу, что значит "Vibe" в словосочетании "Vibe Coding"
(Very Inefficient But Entertaining - Очень неэффективно, но занимательно)

Нейросети позволяют программистам работать быстрее, но при этом пишут в 3-4 раза больше кода и создают в 10 раз больше проблем безопасности

Компания Apiiro, занимающаяся безопасностью приложений, сообщает, что проанализировала код из десятков тысяч репозиториев и код нескольких тысяч разработчиков, связанных с предприятиями из списка Fortune 50, чтобы лучше понять влияние помощников ИИ-разработчиков кода, таких как Claude Code от Anthropic, GPT-5 от OpenAI и Gemini 2.5 Pro от Google.

Компания обнаружила, что разработчики, использующие ИИ, создают в 3-4 раза больше кода, чем их коллеги, работающие без него, но при этом создают в 10 раз больше проблем безопасности.

По состоянию на июнь 2025 года код, сгенерированный ИИ, ежемесячно вносил более 10 000 новых «проблем безопасности» в набор данных репозитория Apiiro, что в 10 раз больше, чем в декабре 2024 года, сообщает компания.

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

Помощники ИИ-кода не совсем бесполезны. Они сократили количество синтаксических ошибок на 76%, а логических — на 60%, но за счёт более серьёзных потерь — на 322% увеличилось количество путей повышения привилегий и на 153% увеличилось количество архитектурных недостатков. Другими словами, ИИ исправляет опечатки, но создаёт бомбы замедленного действия

Анализ Апииро также показал, что разработчики, использующие ИИ, раскрывали конфиденциальные учётные данные и ключи в облаке почти вдвое чаще, чем их коллеги-самоучки.

Выводы компании перекликаются с результатами других исследователей. Например, в мае 2025 года учёные из Университета Сан-Франциско, Института искусственного интеллекта Vector (Канада) и Массачусетского университета в Бостоне определили, что итеративное улучшение образцов кода с помощью моделей ИИ снижает безопасность.

https://www.theregister.com/2025/09/05/ai_code_assistants_security_problems/

Минцифры составило список «белых» сайтов - тех, которые будут работать при отключения мобильного интернета. В него вошли «наиболее востребованные и социально значимые российские сервисы и сайты» по мнению Минцифры.
Список планируется пополнять в дальнейшем, подчеркнул источник. Ещё один источник на телеком-рынке подтвердил содержание списка.

В перечне к настоящему моменту присутствуют:

- все государственные сайты, сервис госуслуги, портал электронного дистанционного голосования и выборов, платформы обратной связи;
- сервисы «Яндекса» (какие именно не уточняется);
- соцсети «ВКонтакте» и «Одноклассники»;
- маркетплейсы Ozon и Wildberries;
- сервисы Сбербанка, Альфа-банка, Т-банка, Газпромбанка и Национальной системы платежных карт (НСПК);
- личные кабинеты операторов связи «большой четверки» — МТС, «МегаФона», «Т2 РТК Холдинга» (бренд Т2) и «ВымпелКома» (бренд «Билайн);
- сервисы Mail.ru и «Дзен»;
- доска объявлений Avito;
- видеосервисы Rutube и «Кинопоиск»;
- онлайн-карты 2GIS;
- сайт магазина «Магнит».

https://www.rbc.ru/technology_and_media/05/09/2025/68bab3579a79472a69e13def

Тем временм скоро появится новый отечественный мессенджер.

Компания «Ред Софт» и Passion разрабатывают новый мессенджер «Молния», который вроде как по функционалу сопоставим с мессенджером Max от VK. Как и Max, сервис создается по примеру китайского WeChat с возможностями общения, платежей и покупок.

4 сентября 2025 года на конференции ВЭФ-2025 компании официально анонсировали мессенджер Molniya. Приложение представляет собой совместную разработку, суперапп с расширенными функциями общения — от личных коммуникаций, обмена фото, видео и другим контентом до групповых звонков и совещаний.

Разработчики отмечают, что главная отличительная особенность Molniya — функционал маркетплейса, который будет предложен российским пользователям прямо внутри мессенджера. В приложении будут собственные платёжные инструменты, удобные сервисы размещения товаров и обработки заказов создают новое измерение для электронной торговли как внутри РФ, так и на международном уровне.

Кроме того, функционал супераппа будет включать элементы социальной сети, короткие видеоролики, потоковое вещание (стриминг), возможности трансграничной торговли. Компания «Ред Софт» заявила, что об официальном запуске и функционале мессенджера будет объявлено отдельно.

https://news.1rj.ru/str/redsoft1/2054

Стратегии обновления при критических изменениях
(продолжение в следующем посте)

Стратегии обновления при критических изменениях
(продолжение предыддущего поста)

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

1. Развёртывание синхронным шагом

Все потребители и производитель обновляются одновременно. Это простая стратегия, но несет риски.

* Упрощает обновление, если одна команда управляет всем
* Полностью нарушает принцип «независимого развёртывания» (independent deployability)
* Одно пропущенное обновление может вывести систему из строя

Используйте этот метод только тогда, когда вы полностью контролируете обе стороны интерфейса.

2. Параллельное существование несовместимых версий

Запуск старой и новой версий сервиса параллельно.
Потребители мигрируют по собственному расписанию.

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

Это эффективно, но дорого в обслуживании.

3. Эмуляция старого интерфейса

Предоставление доступа как к версии v1, так и к версии v2. Внутренне преобразуйте запросы v1 в логику v2.

* Позволяет быстро выпустить новую версию
* Потребители переключаются, когда готовы
* Сохраняет единство бэкенда
* Но требуется дисциплина для своевременного вывода старых версий из эксплуатации

Этот подход обеспечивает баланс между безопасностью и прогрессом.

Обшие рекомендации:
* Синхронное развёртывание подходит, только если одна команда владеет производителем и всеми потребителями.
* Параллельное существование версий может работать, но добавляет операционную нагрузку.
* Эмуляция идеальна, когда нужна гибкость без затрат на дублирование.

Карто-ориентированное программирование

В руководство по языку Си добавлена статья про Преобразование строк в целые числа
https://metanit.com/c/tutorial/10.6.php
#c_ansi

И также добавлена статья про Сравнение преобразования строк в целые числа в различных языках программирования
https://metanit.com/common/langs/5.5.php

Dirty reads (Грязное чтение / чтение "грязных" данных) — чтение данных, которые ещё не были подтверждены (committed) и могут быть отменены и уровни изоляции
(продолжение в следующем посте)