Backend Portal | Программирование

Шпаргалка по командам Redis 🔸Server Commands - PING : проверить, жив ли сервер - FLUSHDB : удалить все ключи в текущей базе - FLUSHALL : удалить все ключи во всех базах - DBSIZE : количество ключей в текущей базе - INFO : информация о сервере 🔸Basic Key Operations - SET key value : сохранить значение по ключу - GET key : получить значение ключа - DEL key [key ...] : удалить ключ(и) - EXISTS key : проверить, существует ли ключ - EXPIRE key seconds : установить время жизни ключа (в секундах) - TTL key : получить оставшееся время жизни 🔸String Commands - INCR key : увеличить числовое значение ключа - DECR key : уменьшить числовое значение ключа - APPEND key value : добавить строку к значению ключа - GETRANGE key start end : получить подстроку 🔸Hash Commands - HSET key field value : установить поле в hash - HGET key field : получить значение поля - HGETALL key : получить все поля и значения - HDEL key field [field ...] : удалить поле(я) - HMSET key field value [field value ...] : установить несколько полей 🔸List Commands - LPUSH key value [value ...] : добавить в начало списка - RPUSH key value [value ...] : добавить в конец списка - LPOP key : удалить и вернуть первый элемент - RPOP key : удалить и вернуть последний элемент - LRANGE key start stop : получить элементы по диапазону 🔸Set Commands - SADD key member [member ...] : добавить элемент(ы) в set - SMEMBERS key : получить все элементы - SREM key member [member ...] : удалить элемент(ы) - SISMEMBER key member : проверить, есть ли элемент - SUNION key [key ...] : объединить set’ы 🔸Sorted Set Commands - ZADD key score member [score member ...] : добавить с весом - ZRANGE key start stop [WITHSCORES] : получить элементы по индексу - ZREM key member [member ...] : удалить элемент(ы) - ZCARD key : количество элементов 🔸Persistence & Config - SAVE : синхронно сохранить на диск - BGSAVE : сохранить на диск в фоне - CONFIG GET/SET parameter : получить или задать конфигурацию 🔸Client Connections - AUTH password : авторизация с паролем - SELECT db : выбрать базу данных (по умолчанию 0) - QUIT : закрыть соединение 👉 @BackendPortal

🚀 БАГодельня возвращается в Telegram! 🚀 Долгожданное возвращение старого доброго ресурса для всех, кто увлекается разработкой и кибербезопасностью. На канале вы найдете разбор CTF-задач на реальных примерах, полезные советы и инсайты от техдира — профессионала с многолетним опытом. 🔹 Уникальный контент по разработке и кибербезопасности 🔹 Анализы CTF-задач с практическими рекомендациями 🔹 Эксклюзивные материалы и разборы сложных кейсов 🔹 Ревью кода из реальных проектов 🔹 Посты о курьезных случаях из мира IT Багодельня — это место для тех, кто хочет учиться, развиваться и быть в курсе последних трендов в мире разработки и безопасности. Ссылка на канал: @bug_makers

Мы и так используем базы данных, так почему бы не заменить ими кэши? Можно ли вообще полностью отказаться от кэширующих сервисов в пользу БД? В посте автор делится мыслями и разбирает, как постепенно идёт движение в эту сторону. Читать здесь: https://avi.im/blag/2025/db-cache/ 👉 @BackendPortal

Нравится контраст между буферизацией страниц данных в MySQL и Postgres. Подходы кардинально разные. InnoDB в MySQL делает ставку на больший контроль. С innodb_flush_method='O_DIRECT' движок обходит большую часть накладных расходов на кэш страниц ОС и управляет всем сам. Объём кэша задаёт innodb_buffer_pool_size. На выделенных БД-серверах это часто 70%+ всей RAM. Пул делится на несколько подэкземпляров. Каждый держит двухчастный список страниц LRU: young и old. Новые страницы попадают в old и должны «прожить» без вытеснения заданное время (innodb_old_blocks_time), прежде чем их пустят в young. Это защищает от thrashing при массовых операциях вроде table scan. Postgres выбирает более простой внутренний кэш и полагается на кэш страниц ОС для загрузки/выгрузки. Размер задаёт shared_buffers. Часто ставят около 30% доступной RAM, оставляя место под кэш ОС. Для вытеснения Postgres использует clock-sweep. У каждой страницы в shared_buffers есть счётчик: он увеличивается при обращениях (до лимита) и уменьшается при проходе «часов». Когда счётчик падает до 0, страницу можно заменить другой. Отличный README из репозитория Postgres: ссылка 👉 @BackendPortal

Stack Overflow не просто вытеснили ИИ Он сам вырастил себе замену. Было время, когда программирование выглядело так: уперся в стену — открыл пять вкладок Stack Overflow и лихорадочно ищешь тот самый ответ с зелёной галочкой 2012 года. До ChatGPT, Claude или DeepSeek было только одно место, где можно было: • найти потерянную точку с запятой • расшифровать загадочную ошибку • скопировать рабочий сниппет кода (и надеяться, что взлетит) Каждый разработчик хотя бы раз шептал себе: «Да благословит бог этого анонима», когда находил решение ровно под свою проблему. Сегодня мы просто спрашиваем у ИИ — и получаем готовый ответ. Но прикол в том, что: Все эти ИИ учились именно на данных Stack Overflow. Тот регекс, который тебе написал ChatGPT? Он вырос из Stack Overflow. Советы по отладке от Claude? Питаются миллионами ответов SO. Подсказки кода от DeepSeek? Это знания Stack Overflow в новом обличии. Stack Overflow создал самую полную базу знаний по программированию, а потом эта база научила ИИ, как заменить её. Классический момент «я тебя вырастил». Конец одной эпохи. Начало другой. А у тебя какой самый запоминающийся случай, когда Stack Overflow спас твою задницу? 😁 👉 @BackendPortal

WebSockets придумали ещё в 2010 году, может и раньше. Их сразу заточили под то, чтобы заголовки занимали минимум места, и это реально круто. Вместо фиксированного размера заголовка под длину данных сделали 7-битный индикатор, который показывает, сколько байт нужно для хранения длины. Если payload ≤ 125 хватает 7 бит Если payload больше 125 и меньше 65 536 длина указывается в двух следующих байтах Если payload больше 65 536 длина пишется в восьми следующих байтах 👉 @BackendPortal

Retry-паттерн может как спасти систему, так и угробить её. Это простой способ добавить устойчивости, но большинство используют его неправильно . Главное правило это не пытаться ретраить бесконечно. Повторы стоят ресурсов: если их мало, то ты сдаёшься на временных сбоях вроде сетевого глюка, если слишком много — перегружаешь систему и скрываешь настоящие ошибки. Обычно трёх повторов достаточно, дальше речь уже скорее идёт о реальной проблеме, а не о временном сбое. Не менее важно время между повторами. Без задержек все запросы будут сыпаться одновременно и добьют систему. Экспоненциальный бэкофф, где паузы растут от секунды к двум, четырём и дальше, даёт сервису шанс восстановиться и не превращает ретраи в отдельную проблему. Ретраить нужно только временные ошибки. Например, таймауты или перегрузку сервера. Но если сервер возвращает битый запрос или запрет доступа, повторять нет смысла, это баг данных или дизайна. Представь автомат, если он пишет «временно не работает», можно попробовать позже. Если он требует другую купюру, повторная попытка ничего не изменит. И ещё одна защита — circuit breaker. Если сервис реально лежит, ретраи могут устроить каскад отказов. Circuit breaker следит за количеством ошибок, отключает запросы, если порог превышен, и снова включает их, когда система оживает. Если всё сделать правильно, повторы делают систему надёжной. Если неправильно, то это, как подливать бензин в огонь. 👉 @BackendPortal

Коллекционирую инструменты, которые помогают в разработке ПО: сервисы, утилиты, базы данных, языки программирования и многое другое. Регулярно делаю на них мини-обзоры. В основном стараюсь находить новое, но бывает и всякое недооцененное старое. Без спама, без роботов и без рандомных репозиториев: только уникальный и отборный контент! ✨ Подробнее

9 лучших практик работы с Docker 1. Используй официальные образы

    
           FROM node:14-alpine{}
    

Гарантия безопасности, стабильности и регулярных обновлений. 2. Фиксируй конкретную версию

    
           FROM node:14.17.0-alpine3.13{}
    

Тег latest непредсказуем, лучше указывать точную версию. 3. Многоэтапные сборки (multi-stage builds)

    
           FROM build-image AS build
   # шаги сборки
   FROM production-image
   COPY --from=build /app /app{}
    

Снижает размер финального образа, исключая инструменты сборки и зависимости. 4. Используй .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. Правильный порядок инструкций для кэша

    
           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{}
    

Находит уязвимости в безопасности. 👉 @BackendPortal

99% "медленных API" работают медленно из-за таких причин: - N+1 запросы - нет индексов - чрезмерно многословные эндпоинты (слишком много мелких запросов туда-сюда) - возвращают больше данных, чем нужно - криво настроено кэширование 👉 @BackendPortal