База данных как антипаттерн МПК

Question

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

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

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

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

Спасибо за внимание.

Answer 1

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

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

h ttp: //127.0.0.1: 5544 / search_zip_code / 80203

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

{"city": "Denver", "state": "Colorado"}

и затем на стороне 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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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