Архитектура кеширования советуют для конкретного сценария - PullRequest
6 голосов
/ 12 апреля 2011

SETUP:

У нас есть приложение .Net, которое распределено по 6 локальным серверам с локальной базой данных (ORACLE), 1 основным сервером и 1 машиной балансировки нагрузки.Запросы поступают на балансировщик нагрузки, который перенаправляет входящие запросы на один из 6 локальных серверов.Через определенные промежутки времени данные собираются на главном сервере и перераспределяются на 6 локальных серверов, чтобы иметь возможность принимать решения с полными данными.

Каждый локальный сервер имеет компонент кэширования, который кэширует входящие запросы на основе различных параметров (местоположение, входящие параметры и т. Д.).С каждым запросом локальный сервер решает, пойти ли в базу данных (ORACLE) или получить ответ из кэша.Однако в обоих случаях локальный сервер должен перейти в базу данных, чтобы выполнить 1 вставку и 1 обновление на запрос.

ПРОБЛЕМА:

В пиковый день каждый локальный сервер получает 2000 запросов в секунду, и система начинает замедляться (ЦП: 90%).Я пытаюсь увеличить емкость, прежде чем добавить еще один локальный сервер в смесь.После выполнения некоторых тестов узким местом, как и всегда, кажется неизбежное 1 вставка и 1 обновление на запрос к базе данных.

ПРОБНЫЕ МЕТОДЫ

Чтобы уменьшить частоту, я создал службу Windows, которая находится между БД и приложением .NET.Он содержит конвейерный сервер и получает каждую вставку и обновление от основного приложения .NET и сохраняет их в Hashtable.Затем новая служба через определенные промежутки времени отправляется в базу данных один раз для выполнения пакетных вставок и обновлений.Дело было в том, чтобы ходить в базу данных реже.Хотя это имело положительный эффект, оно не принесло такой нагрузки на систему, как я ожидал.Большая часть загрузки процессора происходит от oracle.exe, так как количество запросов в секунду увеличивается.

Я стараюсь избегать как можно большего доступа к базе данных, и единственный способ избежать БД, по-видимому, заключается в увеличении коэффициента попадания в кэш, кроме упомянутого выше решения, которое я пробовал.Мой коэффициент попадания в кеш в настоящее время составляет около 81%.Поскольку каждая локальная машина имеет свой собственный кеш, я фактически пропускаю множество кешируемых запросов.Когда два одинаковых запроса перенаправляют на разные серверы, второй запрос не может получить выгоду от кэшированного результата первого.

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

Заранее спасибо, надеюсь, я прояснил свой вопрос.

Ответы [ 3 ]

4 голосов
/ 12 апреля 2011

Для меня это выглядит как приложение для временного решения.В этом случае вы можете удалить локальные базы данных и вернуться только к одной.Там, где у вас сейчас есть локальные базы данных Oracle, вы можете реализовать кеш-сетку.Скорее всего, это будет кеш AWT (Async, Write Through).См. Основные понятия кэша базы данных Oracle In-Memory Это не дешевый вариант, но, возможно, стоит изучить.Вы можете сосредоточиться на бизнес-логике и не беспокоиться о скорости.Это, конечно, хорошо работает только в том случае, если код приложения уже настроен, а sql является производительным и масштабируемым.SQL должен быть подготовлен (используя переменные связывания), чтобы иметь лучшую производительность.Ваше приложение подключается к кешу, а не к базе данных.Вы создаете таблицы кеша в группе кеша, для которой вы хотите кэшировать.Все таблицы в SQL должны кэшироваться, в противном случае полный SQL передается в базу данных Oracle.В сетке есть механизм объединения кеша, поэтому вы не должны беспокоиться о том, где находятся данные в вашей сетке.В текущую версию включена поддержка .net.Данные согласованы и асинхронно обновляются в базе данных Oracle.Если необходимые данные находятся в кэше, и вы отключили базу данных Oracle, приложение может продолжать работать.Как только база данных снова вернется, синхронизация возобновится.Очень могущественный.

1 голос
/ 16 октября 2012

Я знаю, что вопрос сейчас старый, но я хотел, чтобы все знали, как мы решили нашу проблему.

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

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

Спасибо всем за ваши ответы.

1 голос
/ 12 апреля 2011

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

Может быть NoSQL DB (Redis \ Raven \ Mongo), так как промежуточное ПО подойдет вам.Локальный сервер будет читать \ записывать защищенную NoSQL DB, агрегированные данные будут синхронизироваться с непиковым временем Oracle.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...