Группы

Материалы и архитектура реализации групп
В основе функционирования групп лежит реляционная база данных PostgreSQL с горизонтальным шардированием по идентификатору группы. Первичный ключ — 64-битный unsigned integer, генерируемый распределенным счетчиком на основе etcd. Схема данных группы включает поля: id (BIGINT UNSIGNED), owner_id (BIGINT UNSIGNED, внешний ключ к таблице пользователей), title (VARCHAR(128), валидация через regex: /^[a-zA-Zа-яА-Я0-9\s]{3,128}$/), slug (VARCHAR(64), уникальный, генерируется автоматически из title с транслитерацией и дедупликацией), category_id (SMALLINT UNSIGNED, внешний ключ к справочнику категорий), member_count (INT UNSIGNED, денормализованное поле, обновляется через триггеры), created_at (TIMESTAMP), updated_at (TIMESTAMP). Индексация: B-tree по owner_id, category_id, updated_at. Для полнотекстового поиска используется GIN-индекс по tsvector-полю title_search.
Спецификации и отличия от альтернатив
В отличие от «страниц-аналогов» (News Feed pages), группы имеют гранулярную систему прав доступа на уровне строк. Каждый пост в группе проверяется через ACL-сервис на основе RBAC-модели (роли: owner, admin, moderator, member, banned). Альтернативные решения (например, списки рассылки) используют pull-архитектуру, тогда как группы работают по push-модели: при создании поста триггер отправляет событие в Apache Kafka, откуда его потребляют микросервисы ленты новостей и уведомлений. Заявки на вступление обрабатываются через очередь RabbitMQ с приоритетами (ручная модерация — приоритет 1, автоматическое одобрение по whitelist доменов email — приоритет 0).
Производственный процесс и качество реализации
- Кэширование: данные группы (кроме member_count, который обновляется каждые 60 секунд через CRON-задачу) кешируются в Redis Cluster. Ключ: group:{id}, TTL — 3600 секунд. При любом UPDATE соответствующая запись инвалидируется через Pub/Sub канал.
- Контроль версий: каждое изменение группы сохраняется в таблицу group_history (снапшоты) для возможности отката (rollback). Версионирование — MVCC через PostgreSQL. Retention policy — 90 дней.
- Валидация имени: проверка на столкновение с зарезервированными словами (список из 512 терминов, включая системные имена). Используется Bloom-фильтр для минимизации обращений к базе.
- Медиаконтент: аватары и обложки групп проходят конвейер обработки: ресайз до 256x256 и 1024x300, сжатие WebP (quality: 85), хранение в S3-совместимом объектном хранилище. CDN — CloudFront. Среднее время загрузки — 120 мс (p99).
- Тестирование: unit-тесты на Python (pytest) покрывают 92% логики создания и модерации. Интеграционные тесты — 78%. Нагрузочное тестирование проводится с помощью Locust: target — 10k RPS на эндпоинт /groups/join.
Стандарты аудита и безопасности
Все операции с группами логируются в централизованную систему ELK. Аудит доступа: каждое чтение данных группы фиксируется с таймстемпом, ID пользователя и типом запроса (API / WebSocket / Backend). Верификация владельцев групп для статуса «официальная» требует: 2FA при входе и WebAuthn для подтверждения. Секретные группы (visibility = 'secret') не индексируются поисковыми ботами — в robots.txt добавлен запрет на /groups/secret/*. Шифрование данных в покое: AES-256-GCM для таблицы group_settings (настройки приватности, whitelist, password). Ключи ротируются ежемесячно. Стандарты соответствуют ISO 27001:2025 (контроль A.8.2.1 — управление доступом, A.12.6.1 — управление уязвимостями).
Добавлено: 12.05.2026
