Приложения тормозят. Пользователи уходят. Бизнес недоволен. Знакомая картина? Часто корень зла – медленный доступ к данным. Кеширование может стать спасательным кругом. Но это не серебряная пуля. Неправильно настроенный кеш – источник новых проблем, иногда похуже старых.

Зачем нам кеш?

Представьте себе частого посетителя архива. Ему нужна одна и та же папка с документами каждый день. Бегать каждый раз в хранилище, ждать архивариуса, листать описи – долго и муторно. Проще один раз взять папку, сделать копию нужных листов и положить их себе на стол. Кеш – это такой "рабочий стол" для данных вашего приложения.

Основные выгоды кеширования

1. Быстрый отклик. Данные из кеша (обычно это быстрая память, RAM) извлекаются в разы, а то и на порядки шустрее, чем из основной базы данных (БД) или от внешнего сервиса. Пользователь получает ответ почти мгновенно. Меньше ожидания – больше счастья.

2. Разгрузка основных систем. База данных часто становится бутылочным горлышком. Кеш забирает на себя львиную долю повторяющихся запросов. Это дает БД возможность спокойно обрабатывать сложные, уникальные операции, которые нельзя закешировать. То же касается и внешних API, которые могут иметь ограничения на число вызовов или просто быть медленными.

3. Экономия ресурсов. Меньше запросов к диску, меньше сетевого трафика между сервисами, ниже нагрузка на процессоры основной БД. Это может приятно сказаться на счетах за инфраструктуру.

Звучит отлично. Но дьявол, как всегда, в деталях.

Типичные проблемы кеширования и их решения

Кеш – это хорошо, но он порождает свои уникальные проблемы. Их нельзя игнорировать.

1. Протухшие данные (Stale Data)

Самая частая головная боль. Данные в БД изменились, а в кеше лежит старая версия. Пользователь видит вчерашний день.

• Решения:

  • Время жизни (TTL - Time To Live): Простейший вариант. Каждой записи в кеше даем "срок годности". Истек – запись удаляется или считается невалидной.

    • Засада с TTL: Трудно угадать идеальное значение. Слишком короткое – кеш почти бесполезен, хитов мало. Слишком длинное – данные долго "тухнут".

  • Активная инвалидация: Когда данные в БД меняются, приложение (или специальный сервис) явно говорит кешу: "Удали (или обнови) запись по ключу X".

    • Пример: После UPDATE users SET email = 'new@example.com' WHERE id = 123; тут же выполнить cache.del("user:123");.

    • Засада: Требует дополнительной логики. А если команда инвалидации не прошла?

  • Событийная инвалидация: Использовать брокеры сообщений (Kafka, RabbitMQ). Сервис, меняющий данные в БД, публикует событие "Данные X изменились". Другой сервис слушает эти события и инвалидирует кеш.

    • Засада: Усложняет архитектуру. Могут быть задержки в доставке событий.

2. Согласованность данных (Data Consistency)

Особенно актуально для распределенных кешей или при использовании Write-Back. Как сделать так, чтобы все экземпляры приложения видели одинаковые данные, и чтобы кеш не врал относительно БД?

• Решения:

  • Паттерн Write-Through: Помогает держать данные в тонусе, но платим скоростью записи.

  • Короткий TTL: Уменьшает окно, в котором данные могут быть несинхронны.

  • Механизмы блокировок или версионирования: При обновлении данных можно использовать оптимистичные/пессимистичные блокировки на уровне кеша или БД.

  • Для распределенных кешей: Использовать решения, которые сами заботятся о репликации и консистентности (например, Redis Cluster, Hazelcast).

3. "Грозовая стая" (Thundering Herd)

Картина маслом: популярный ключ в кеше разом "протух" (TTL закончился). И тут же на систему налетает толпа запросов за этими данными. Кеш пуст. Все эти запросы, как один, ломятся в базу данных, пытаясь одновременно загрузить одно и то же. База может захлебнуться.

• Решения:

  • Блокировки на уровне приложения (single-flight request collapsing): Первый запрос, который наткнулся на cache miss, ставит "замочек" на этот ключ (например, используя std::mutex и std::set для отслеживания ключей в процессе загрузки). Остальные запросы по этому ключу видят замочек и ждут (или получают старые данные, если это приемлемо). Первый "счастливчик" загружает данные, кладет в кеш, снимает замок. Остальные тут же получают данные из кеша.

    #include <string>
    #include <optional>
    #include <mutex>
    #include <condition_variable>
    #include <set>
    
    static std::mutex g_sf_mutex;
    static std::condition_variable g_sf_cv;
    static std::set<std::string> g_sf_loading_keys;
    
    std::optional<Data> get_data_sf(const std::string& key, MyCache& cache, MyDB& db) {
        std::optional<Data> data = cache.get(key);
        if (data) return data;
    
        std::unique_lock<std::mutex> lock(g_sf_mutex);
        data = cache.get(key);
        if (data) return data;
    
        while (g_sf_loading_keys.count(key)) {
            g_sf_cv.wait(lock);
            data = cache.get(key);
            if (data) return data;
        }
    
        g_sf_loading_keys.insert(key);
        lock.unlock();
    
        std::optional<Data> db_result;
        try {
            db_result = db.query(key);
            if (db_result) {
                cache.set(key, *db_result, 300);
            }
        } catch (...) {
            std::unique_lock<std::mutex> recovery_lock(g_sf_mutex);
            g_sf_loading_keys.erase(key);
            recovery_lock.unlock();
            g_sf_cv.notify_all();
            throw;
        }
    
        std::unique_lock<std::mutex> final_lock(g_sf_mutex);
        g_sf_loading_keys.erase(key);
        final_lock.unlock();
        g_sf_cv.notify_all();
    
        return db_result;
    }

  • Проактивное обновление: Незадолго до реального истечения TTL, один из запросов (выбранный случайно или по условию) обновляет данные в кеше, продлевая им жизнь. Это "размазывает" нагрузку.

  • Мягкое истечение (Soft TTL) / Использование протухших данных: Если данные в кеше "умерли", система может вернуть старые данные (если они есть) и одновременно в фоне запустить их обновление. Лучше старые данные на пару секунд, чем ошибка или долгое ожидание.

4. Политики вытеснения (Cache Eviction Policies)

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

• LRU (Least Recently Used): Выкидываем то, что дольше всего лежало без дела. Часто хороший выбор "по умолчанию".

• LFU (Least Frequently Used): Этот вариант хорош, когда есть данные, к которым обращаются постоянно, пусть и не каждую секунду.

• FIFO (First In, First Out): Тут все по-честному – кто первый вошел, тот первым и выйдет. Легко, но не всегда умно.

• MRU (Most Recently Used): Удаляем самое свежее. Неожиданно? Да. Но для особых задач, вроде полного перебора данных (когда к прочитанному точно не вернутся), – самое то.

• Random: Просто случайный выбор "жертвы". И знаете, бывает, что такая простота и отсутствие лишних подсчетов дают очень даже неплохой результат.

• Какую политику выбрать? Тут надо смотреть, как ваши данные живут и как к ним обращаются. Большинство кеш-систем (Redis, Memcached) позволяют это настраивать.

5. Холодный старт (Cold Start)

Приложение перезапустили, кеш-сервер подняли с нуля – кеш пуст. Первые запросы будут медленными, как черепахи, а нагрузка на БД подскочит до небес.

• Решения:

  • Прогрев кеша (Cache Warming): При старте приложения можно заранее загрузить в кеш самые популярные или критически важные данные. Список "горячих" ключей можно взять из аналитики или логов предыдущих сессий.

  • Постоянный кеш (Persistent Cache): Есть такие умные кеш-системы, вроде Redis с его фишками RDB/AOF, которые могут всё своё барахло скинуть на диск. А после рестарта – хоп! – и всё на месте, кеш не пустой.

6. Атаки на пустой кеш (Cache Penetration)

Хакер или ошибка в коде начинает бомбить систему запросами к данным, которых заведомо нет и никогда не было в БД (например, ID=-1, случайные строки). Каждый такой запрос – это cache miss, затем бесполезный запрос в БД, которая тоже ничего не находит. Это создает ненужную нагрузку.

• Решения:

  • Кеширование "пустых" ответов: Если БД сказала "не найдено" для ключа X, можно закешировать этот "пустой" результат на короткое время. Следующий запрос по этому же несуществующему ключу быстро получит "не найдено" из кеша и не будет мучить БД.

  • Фильтр Блума (Bloom Filter): Компактная вероятностная структура данных. Может быстро сказать: "этого элемента точно нет в наборе" или "этот элемент возможно есть". Если фильтр Блума говорит "точно нет", то в кеш и БД можно даже не соваться. Это просто спасение от лишних походов в базу за тем, чего там нет.

  • Проверяйте входящие данные: всякий мусор вроде кривых запросов (минусовые ID, гигантские строки, левый формат) рубите на корню, еще до того, как они до кеша доберутся.

7. Лавина кеша (Cache Avalanche)

Похоже на "грозовую стаю", но причина иная. Случается, когда огромное количество ключей в кеше истекает почти одновременно (например, у них был один и тот же TTL, или упал и перезапустился кеш-сервер). Это вызывает массовые cache miss и резкий, как удар, скачок нагрузки на БД.

• Решения:

  • Рандомизация TTL: Вместо фиксированного TTL (скажем, 300 секунд), использовать небольшой случайный разброс (например, от 280 до 320 секунд). Это "размажет" время истечения ключей и сгладит пик.

  • Многоуровневое кеширование: Если один слой кеша падает, другой может смягчить удар.

  • Проактивное обновление (как при "грозовой стае"): Стараться обновлять ключи до их массового "вымирания".

  • Ограничение числа одновременных запросов к БД на уровне приложения или проксирующего слоя.

Практические рекомендации: что делать и чего не делать

• Не кешируйте всё подряд.

  • Определите, какие данные действительно выиграют от кеширования. Обычно это часто читаемые и редко изменяемые данные. Профилировщик вам в помощь – он покажет, где код "кипит" и какие запросы к данным жрут больше всего времени.

  • А вот данные, что уникальны для каждого чиха или обновляются с каждой сменой погоды, в кеш тащить – это почти всегда пустая трата сил. Иногда стоимость поддержки кеша (запись, инвалидация, память) может перевесить выгоду.

• TTL – выбирайте с умом.

  • Универсального TTL не существует. Для одних данных это секунды, для других – часы или дни.

  • Ищите баланс между свежестью данных и эффективностью кеша. Чем короче TTL, тем актуальнее данные, но ниже процент попаданий (hit rate).

  • Не стесняйтесь использовать разные TTL для разных типов данных.

• Стратегия инвалидации – это критично.

  • Простого TTL часто недостаточно. Если актуальность данных – вопрос жизни и смерти, нужна активная инвалидация.

  • Инвалидация должна быть надежной. Что если запрос на удаление из кеша потерялся? Нужны механизмы повторов или фоновые сверки.

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

• Следите, следите и еще раз следите за своим кешем!

  • Вы просто обязаны быть в курсе, что там у него и как. Ключевые метрики:

    • Hit Rate (процент попаданий): (число попаданий / общее число запросов к кешу) * 100%. Чем выше, тем лучше.

    • Miss Rate (процент промахов): (число промахов / общее число запросов к кешу) * 100%.

    • Задержка (Latency): Время ответа от кеша. Должно быть минимальным.

    • Размер кеша: Объем используемой памяти. Не допускайте переполнения.

    • Число вытеснений (Evictions): Как часто данные удаляются из-за нехватки места. Частые вытеснения могут говорить о маленьком кеше или неправильной политике.

  • Настройте алерты на аномалии (резкое падение hit rate, переполнение кеша, недоступность кеш-сервера).

• Начинайте с простого.

  • Cache-Aside – прекрасная отправная точка. Легко реализовать, легко понять.

  • Не усложняйте без веской причины. Продвинутые паттерны (Read-Through, Write-Back) требуют более сложной инфраструктуры и отладки.

• Безопасность кеша.

  • Секретную информацию (пароли, ключи, личные данные) в кеше "голышом" держать нельзя. Особенно если ваш кеш не за семью замками или им пользуются разные приложения, которым вы не доверяете на все сто.

  • Если уж такие данные попали в кеш – подумайте о шифровании прямо там.

  • Доступ к самим серверам кеша тоже надо закрывать (файрволы, пароли на вход).

• Тестируйте свои стратегии кеширования.

  • Кеширование может маскировать проблемы производительности в других частях системы.

  • Тестируйте поведение системы с кешем и без него (если возможно).

  • Проверяйте, как система ведет себя при "холодном старте" или после массовой инвалидации.

  • Нагрузочное тестирование поможет понять реальный hit rate под нагрузкой и выявить узкие места.

• Многоуровневое кеширование.

  • Иногда имеет смысл использовать несколько слоев кеша:

    • L1-кеш: Внутрипроцессный кеш (in-memory) прямо в вашем приложении. Молниеносный, но ограничен памятью процесса и не разделяется между экземплярами приложения. В C++ это может быть std::map с std::mutex или готовые библиотеки.

    • L2-кеш: Распределенный кеш (out-of-process). Общий для всех экземпляров приложения. Медленнее L1, но гораздо больше по объему и более устойчив к падению отдельных инстансов приложения. Примеры: Redis, Memcached.

  • Запрос сначала идет в L1, если там нет – в L2, если и там пусто – только тогда в БД.

• Выбор инструмента для кеширования.

  • Redis: Он и правда очень популярен. Суть в том, что он работает с разными типами данных (не одними строками – есть списки, хеши, наборы). Плюс, умеет сохранять данные на диск, копировать их на другие серверы (это репликация) и объединять в группы (кластеризация). Из-за этого его часто выбирают не только для кеширования, но и как быструю базу данных, или как способ обмениваться сообщениями между сервисами.

  • Memcached: Проще Redis. Чистое key-value хранилище строк. Очень быстрый, хорошо масштабируется горизонтально. Не имеет встроенной персистентности "из коробки".

  • Локальные кеши (внутри процесса): Для небольших объемов данных или для очень частых обращений к одним и тем же данным внутри одного экземпляра приложения. Легко реализуются стандартными средствами языка.

• Не кешируйте ошибки надолго.

  • Если внешний сервис или база данных ответили ошибкой, не надо кешировать эту ошибку надолго, как обычный успешный ответ. Иначе ваше приложение будет упрямо твердить об ошибке, хотя проблема на той стороне уже решена. Для ошибок ставьте очень короткое время жизни в кеше, или вообще не кладите их туда.

• Помните о цене сериализации/десериализации.

  • Объекты, помещаемые в кеш (особенно распределенный), обычно нужно превратить в поток байт (сериализовать), например, в JSON, Protobuf, или собственный бинарный формат. При извлечении – обратный процесс (десериализация). Эти операции тоже тратят время и ресурсы CPU. Выбирайте эффективные форматы. В C++ это может быть ручная сериализация, Boost.Serialization или FlatBuffers/Protobuf.

• Размер объектов в кеше.

  • Огромные объекты занимают много места в кеше и могут приводить к частым вытеснениям. Их передача по сети (для распределенных кешей) также накладна.

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

• Кеширование и транзакции.

  • Особая песня – кеширование данных, которые крутятся в транзакциях базы. Если транзакция вдруг откатится, а кеш об этом не узнает, получите протухшие данные. Аккуратнее тут! Инвалидация кеша должна быть частью логики управления транзакциями (например, после успешного commit) или происходить по событиям из БД, если это возможно.

Основные паттерны кеширования

Есть несколько проверенных временем подходов к организации работы с кешем. Выбор конкретного зависит от данных, с которыми вы работаете, и требований к их актуальности и доступности.

1. Cache-Aside (Ленивая загрузка, кеш "в стороне")

Самый, пожалуй, популярный и интуитивно понятный метод. Логика проста:

• Приложение хочет получить данные.

• Сначала оно лезет в кеш: "Эй, кеш, есть у тебя данные по ключу X?"

• Если данные в кеше нашлись (cache hit) – ура, берем их и радуемся.

• Если в кеше пусто по этому ключу (cache miss) – приложение само идет в основную БД.

• Данные, полученные из БД, кладутся в кеш на будущее. "Вот, кеш, сохрани, может еще пригодится."

• Данные отдаются тому, кто их просил.

#include <string>
#include <optional>
#include <iostream> // Для примера вывода

// Предположим, у нас есть такие интерфейсы (очень упрощенно):
struct Data { std::string content; int id; };
class MyCache {
public:
    std::optional<Data> get(const std::string& key) {
        // Логика получения из кеша
        if (key == "user:123" && has_user_123_in_cache) { // Псевдо-проверка
            return Data{"Cached User 123 Data", 123};
        }
        return std::nullopt;
    }
    void set(const std::string& key, const Data& value, int ttl_seconds) {
        // Логика сохранения в кеш
        std::cout << "Cache: Storing " << key << " for " << ttl_seconds << "s.\n";
        has_user_123_in_cache = (key == "user:123"); // Псевдо-сохранение
    }
    void del(const std::string& key) { // Добавим псевдо-метод удаления
        std::cout << "Cache: Deleting " << key << "\n";
        if (key == "user:123") has_user_123_in_cache = false;
    }
private:
    bool has_user_123_in_cache = false; // Очень упрощенное состояние для примера
};

class MyDB {
public:
    std::optional<Data> query(const std::string& query_key) {
        // Логика запроса к БД
        std::cout << "DB: Querying for " << query_key << "\n";
        if (query_key == "user_id_123") { // Предположим, это ключ для БД
            return Data{"Fresh User 123 Data from DB", 123};
        }
        return std::nullopt;
    }
    void save_user(const std::string& user_key_in_db, const Data& data) { // Псевдо-метод сохранения
         std::cout << "DB: Saving data for " << user_key_in_db << " with content: " << data.content << "\n";
    }
};

// Глобальные экземпляры для простоты примера
MyCache g_cache;
MyDB g_db;

std::optional<Data> get_data_cache_aside(const std::string& data_key, const std::string& db_query_key) {
    auto cached_item = g_cache.get(data_key);
    if (cached_item) {
        std::cout << "Cache hit for " << data_key << "\n";
        return cached_item;
    }

    std::cout << "Cache miss for " << data_key << ". Fetching from DB.\n";
    auto db_item = g_db.query(db_query_key); // Используем db_query_key для БД
    if (db_item) {
        g_cache.set(data_key, *db_item, 300); // Кешируем на 5 минут
    }
    return db_item;
}

• Плюсы:

  • Просто реализовать. Логика работы с кешем явно видна в коде приложения.

  • Кеш упал? Не беда (ну, почти). Приложение просто будет чаще ходить в БД. Производительность просядет, но система не ляжет костьми.

  • Кешируются только те данные, которые реально кому-то нужны.

• Минусы:

  • Первый запрос за любыми данными всегда будет "холодным" – cache miss и поход в БД.

  • Код приложения знает про кеш, это немного "загрязняет" его.

  • Данные могут слегка "протухнуть", если в БД они обновились, а в кеше старая копия. Решается временем жизни (TTL) или явной инвалидацией.

2. Read-Through (Чтение сквозь кеш)

Похож на Cache-Aside, но тут само приложение не ходит в БД за данными, если их нет в кеше. Оно просто просит данные у "провайдера кеша", а тот уже сам разбирается.

• Приложение всегда стучится только в кеш: "Дай данные по ключу X".

• Если данные есть – кеш их отдает.

• Если данных нет – сам кеш-провайдер идет в БД, загружает их, сохраняет у себя и отдает приложению.

Приложение даже не в курсе, откуда пришли данные – из быстрой памяти кеша или их только что подтянули из медленной БД.

#include <string>
#include <optional>
#include <iostream>

class ReadThroughCacheProvider {
public:
    ReadThroughCacheProvider(MyDB& db_ref, MyCache& cache_ref) 
        : db(db_ref), cache_storage(cache_ref) {}

    std::optional<Data> get(const std::string& key) {
        std::optional<Data> item = cache_storage.get(key); 
        if (item) {
            return item;
        }

        item = db.query(key); 
        if (item) {
            cache_storage.set(key, *item, 300); 
        }
        return item;
    }
private:
    MyCache& cache_storage; 
    MyDB& db;
};

• Плюсы:

  • Код приложения чище. Он просто просит данные, не думая об их источнике.

  • Логика загрузки данных централизована в кеш-провайдере.

• Минусы:

  • Сам кеш-провайдер становится сложнее. Ему нужно уметь общаться с БД.

  • Первый запрос по-прежнему медленный.

3. Write-Through (Запись сквозь кеш)

Этот паттерн касается записи данных. Идея в том, чтобы писать данные одновременно и в кеш, и в основное хранилище (БД).

• Приложение хочет обновить/создать данные.

• Данные сначала пишутся в кеш.

• Затем они пишутся в базу данных.

• Операция считается успешной только после того, как данные сохранены и там, и там.

#include <string>
#include <optional>   
#include <iostream>   
#include <stdexcept> 

void save_data_write_through(const std::string& key, 
                             const Data& data_to_save, 
                             MyCache& cache, 
                             MyDB& db) {
    cache.set(key, data_to_save, 300);
    try {
        db.save_user(key, data_to_save);
    } catch (const std::exception& /* e */) { // e можно не использовать, если только перебрасываем
        cache.del(key);
        throw;
    }
}

• Плюсы:

  • Данные в кеше и БД почти всегда одинаковы. То, что читается из кеша, будет актуальным.

  • Надежность: данные сразу же попадают в постоянное хранилище.

• Минусы:

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

  • Если кеш и БД на разных машинах, добавляется сетевая задержка на вторую запись.

4. Write-Back (Отложенная запись, или Write-Behind)

Тут запись происходит очень быстро, потому что данные сначала попадают только в кеш.

• Приложение обновляет/создает данные.

• Данные моментально пишутся только в кеш. Приложению тут же говорят: "Все ОК, записано".

• Сам кеш-провайдер (или отдельный сервис) через какое-то время или при накоплении пачки изменений асинхронно записывает эти данные в БД.

#include <vector>
#include <mutex>
#include <thread> 

void save_data_write_back(const std::string& key, const Data& data_to_save, MyCache& cache) {
    cache.set(key, data_to_save, 3600); // Пишем в кеш (возможно, с долгим TTL)
    std::cout << "WriteBack: Saved to cache " << key << ". Queued for DB.\n";
}

• Плюсы:

  • Очень быстрые операции записи. Идеально для систем, где скорость записи решает все.

  • Снижение пиковой нагрузки на БД, так как записи могут группироваться и выполняться пачками.

• Минусы:

  • Риск потери данных. Если сервер с кешем упадет до того, как данные успели записаться в БД, эти изменения пропадут. Катастрофа.

  • Сложнее в реализации. Нужны надежные механизмы управления очередью "грязных" данных и их сброса в БД, обработка ошибок.

  • Данные в БД могут быть неактуальны какое-то время. Это нужно учитывать.

5. Write-Around (Запись в обход кеша)

При этом подходе запись идет напрямую в базу данных, кеш не трогаем.

• Приложение обновляет/создает данные.

• Данные пишутся только в базу данных.

• Кеш в этот момент не обновляется. Если эти данные потом понадобятся для чтения, они загрузятся в кеш по одной из "читающих" стратегий (Cache-Aside или Read-Through).

• Плюсы:

  • Кеш не засоряется данными, которые могут никогда не понадобиться для чтения (например, какие-нибудь редкие логи или аудиторские записи).

  • Полезно, когда данные часто пишутся, но редко или никогда не читаются сразу после записи.

• Минусы:

  • Если прочитать данные сразу после записи, всегда будет cache miss, и придется идти в БД.

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

Кеширование – мощный инструмент. Но, как и любой мощный инструмент, требует умелого обращения. Это всегда поиск компромиссов. Нет двух одинаковых систем, и каждый проект – это своя история. То, что взлетело в интернет-магазине, может с треском провалиться в соцсети или навороченной финансовой системе.

Главное – это врубиться в саму суть. Понимать, как эти паттерны работают, где их сила, а где – слабое место. И, само собой, постоянно держать руку на пульсе: измерять, думать, снова измерять. Начинайте с малого, смотрите, что получилось. А потом уже, если припрёт, потихоньку усложняйте. Только так и строится быстрая система, от которой пользователи пищат от восторга, а бизнес не лезет на стенку от счетов.