База данных как антипаттерн IPC

Я написал многоуровневое веб-приложение, которое состоит из полнофункционального веб-клиента (PHP), который взаимодействует с java-сервисом. Веб-клиент размещается на сервере apache, а служба Java работает на том же физическом компьютере (повторюсь: все приложение, клиент и служба работают на одном физическом компьютере).

Запрос пользователя -> DB ‹- Poller -> RequestHandler -> StoreResult в БД -> веб-клиент обновляет страницу с результатом (AJAX).

Связь между клиентом и службой использует реляционную базу данных для передачи сообщений. Служба Java имеет однопоточный опросчик, который ищет и затем обрабатывает любые сообщения / запросы от клиента. Система работает, но я не уверен в своем выборе дизайна.

Есть ли у кого-нибудь комментарии по поводу этой стратегии? Я читал, что использование базы данных в качестве антипаттерна IPC - плохая практика или, по крайней мере, неподходящая. Однако альтернативы - XMLRPC, именованные каналы - похоже, связаны с дополнительными зависимостями.

Спасибо, что искали.


person meta.matt    schedule 28.09.2010    source источник
comment
Вы используете базу данных как очередь сообщений. Вам следует задуматься над тем, является ли это хорошей очередью сообщений? как насчет надежности (не пропустить ни одного сообщения в любой ситуации) и пропускной способности?   -  person jrharshath    schedule 28.09.2010
comment
Базы данных на самом деле не предназначены для очередей / очередей. Они используются для постоянства программного обеспечения очередей, например ActiveMQ. Но некоторые базы данных предоставляют поддержка собственной очереди (SQL Server) ...   -  person OMG Ponies    schedule 28.09.2010
comment
Еще кое-что: вы изучали Quercus?   -  person mario    schedule 28.09.2010
comment
@mario для меня вся идея Quercus кажется нечестивой: зачем вам интерпретировать и интерпретировать язык, используя другой интерпретируемый язык? (Я знаю, java не совсем интересен, но вы понимаете)   -  person jrharshath    schedule 28.09.2010
comment
Рассматривали ли вы gearman.org - highscalability.com/?   -  person Fanis Hatzidakis    schedule 29.09.2010
comment
Я уже делал это однажды, и это сработало достаточно хорошо, хотя я бы не стал делать это снова. Две вещи: не индексируйте таблицу очереди и не загружайте базу данных с диска памяти, чтобы ускорить чтение и сократить износ жесткого диска. Имейте в виду, что большинство оптимизаций, используемых для ускорения чтения постоянных данных, замедляют работу базы данных с большим объемом записи.   -  person Evan Plaice    schedule 13.01.2013


Ответы (4)


Если бы это был я, и мне понадобился бы PHP для захвата / использования данных из java-сервиса, я бы сбросил БД.

Попросите службу Java с HTTP прослушивать 127.0.0.1, порт 5544 (или какой-то случайный #). Попросите сервлет / jsp принимать запросы RESTful и выдавать результаты JSON. Итак, если это поиск, URL-адрес будет:

ч. ttp: //127.0.0.1: 5544 / search_zip_code / 80203

и результатом будет простой json:

{"город": "Денвер", "штат": "Колорадо"}

а затем на стороне PHP выполните запрос curl - создайте URL-адрес с параметрами из пользовательского ввода, выполните запрос curl, получите данные обратно и json_decode его ($ result_array = json_decode ($ curl_result);).

Все было бы просто. Таким образом, вы можете легко протестировать любой компонент (выполните curl / wget из командной строки, чтобы протестировать службу Java, или проверьте access_logs на стороне сервера, чтобы увидеть параметры поиска и соединение от клиента).

Для стороны PHP используйте curl_exec и json_decode (ищите эти функции в руководстве по PHP).

Вот случайная ссылка, которую я нашел для стороны Java:

Анализ данных JSON со стойками сервлетов Java

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

person Andy Goodwin    schedule 26.11.2010
comment
Я согласен! В итоге мы сделали нечто очень похожее. Спасибо и приношу свои извинения за задержку с принятием этого ответа. - person meta.matt; 15.03.2011
comment
связанная страница переместилась, скорее всего сюда: Создание синтаксического анализа данных JSON с помощью Java Servlet / Struts / JSP - person Wolf; 23.05.2019

Я вижу следующие аргументы в пользу БД как IPC:

1) Вам необходимо хранить все (или на определенный период) сообщения, которые вы когда-либо получали.

2) Вам нужна высокая надежность и вы не хотите терять сообщения.

3) Производительность противоположных сторон БД сильно различается. Таким образом, левая сторона клиента может генерировать огромное количество сообщений, и многие клиенты на правой стороне будут их обрабатывать. Таким образом, БД похожа на пассивный балансировщик нагрузки с высокой надежностью.

Вам нужны какие-либо из этих функций? Я думаю нет. Вы не можете использовать его в качестве балансировщика нагрузки, потому что все процессы находятся на одном хосте. И я думаю, что вам не нужно хранить все веб-запросы.

В этом случае я бы выбрал простые розетки.

person Donz    schedule 28.09.2010
comment
Действительные баллы. Итак, для сокетов клиенту необходимо открыть сокет и отправить сообщение в службу Java. Следовательно, мне нужно было бы написать код для управления сокетами сервера. Насколько это эффективно? А что насчет надежности - сбой серверного сокета и т. Д. Кроме того, насколько дорого будет открывать клиентский сокет для каждого запроса пользователя? Спасибо за ваше предложение. - person meta.matt; 28.09.2010
comment
Неужели вам не нужно терять ни одного сообщения? Для веб-приложений нормально не доставлять некоторые запросы. Пользователь видит ошибку и пытается еще раз. Так что, как правило, вам не нужна высокая надежность для веб-приложений. - person Donz; 28.09.2010
comment
Неужели вам не нужно терять ни одного сообщения? Для веб-приложений нормально не доставлять некоторые запросы. Пользователь видит ошибку и пытается еще раз. Так что, как правило, вам не нужна высокая надежность для веб-приложений. Когда вы подключаетесь к БД, вы тоже используете сокеты, но на протоколе более высокого уровня. Таким образом, вы можете достичь большей эффективности с помощью сырых сокетов. Если вы не хотите изобретать велосипед, вы можете использовать HTTP-запрос от одной службы к другой. Даже с HTTP вы будете использовать меньше ЦП и памяти, чем с БД. Главный момент - понять преобладающие функции, которые вам действительно нужны, и выбрать соответствующий протокол (или может быть БД) - person Donz; 28.09.2010

Если вам просто нужна передача сообщений для PHP, просто используйте ActiveMQ - точно так же, как очереди сообщений в UNIX IPC. Однако база данных может быть хорошим эквивалентом разделяемой памяти и семафоров, известных из UNIX IPC. Таким образом, имея ActiveMQ и базу данных, вы можете делать то же самое, что и с UNIX IPC, но его можно кластеризовать, если одного сервера вам будет мало.

person iirekm    schedule 12.10.2010

Это взлом, но он, очевидно, работает для вас. Вот веб-сайт о том, как реализовать очередь сообщений с таблицей БД в PHP.

person Romain Hippeau    schedule 28.09.2010