Вопрос дизайна взаимодействия клиент-клиент?

Question

Хорошо, вот моя ситуация: Я ищу лучший дизайнерский подход. Я работаю в PHP / Smarty на стороне сервера и HTML / jQuery для стороны клиента, но это не очень важно здесь.

У меня есть многопользовательская система на моем сервере. Это своего рода система заказов. Обычный пользователь, назовем его клиентом, может заказать некоторые товары в интернет-магазине. В интернет-магазине представлены товары от нескольких продавцов.

Когда пользователь (клиент) размещает заказ, продавец - также пользователь в системе - должен получить уведомление о наличии нового заказа и подтвердить / отклонить его.

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

Заказы хранятся в базе данных, а также подтверждения заказов.

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

Но я думаю, есть ли способ вызвать уведомления продавца, когда пользователь (клиент) размещает заказ, чтобы продавец мог загружать базу данных только тогда, когда это необходимо, а не постоянно с интервалами?

То же самое относится и к клиенту, когда он / она ожидает подтверждения. Но это не так важно, потому что это не происходит постоянно. Существует предел ожидания, когда заказ будет автоматически отклонен, если продавец не ответит.

Надеюсь, вы понимаете мой вопрос.

Answer 1

Ответ на аналогичный вопрос здесь на Использование Comet с PHP предполагает, что могут быть некоторые проблемы с нитями Apache, связанными со всеми открытыми соединениями с клиентом.

Согласно этому сообщению в блоге PHP Continuations , можно использовать продолжения с PHP, но, похоже, документации на эту тему не так много. Однако CometChat сделал это на PHP . Не ясно, используют ли они продолжения, но они утверждают, что масштабируются до 100 000 соединений. Более подробную информацию о PHP Comet можно найти в этом похожем вопросе о переполнении стека, касающемся решения для Comet и PHP .

Я также собирался предложить использовать Java, поскольку у Java действительно отличный послужной список для реализации масштабируемой Comet с помощью Continuations. Поддержка преобразования - это пример программного обеспечения для чата, использующего комету и продолжения на Jetty Web Server .

Поскольку ваш код написан на PHP, вы можете использовать Querces для запуска своего кода PHP на JVM . Кроме того, запрашивает тесты PHP. Предлагайте это быстрее, чем Apache , что дает вам дополнительные преимущества. Проверьте Querces Project для получения дополнительной информации.

ОБНОВЛЕНИЕ: Я предлагаю вам сделать свои собственные тесты или исследовать проблему скорости самостоятельно, так как может быть некоторая информация, которая может предположить, что Apache работает быстрее. Если вы используете Querces, важно понимать, что вы, по сути, будете писать Java, который выглядит и выглядит как PHP. Поэтому я бы также предложил провести дополнительные исследования, чтобы вы поняли преимущества и недостатки этого подхода.

Answer 2

COMET и длинный опрос, как упомянуто выше, являются общими решениями этой проблемы.Но вы также можете заглянуть в веб-сокеты HTML5.Он поддерживается во всех браузерах, но есть патчи / полифилы для браузеров IE.

Вы также можете посмотреть на Node.js для запуска по стороннему apache.

Answer 3

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

Система, которую вы описываете, звучит так, как если бы она могла начинаться с небольшого масштаба, она легко масштабировалась бы до конфигурации с несколькими серверами.Опрос позволит вам создать сервер опроса, к которому могут обращаться запросы AJAX.Это может быть оптимизировано для небольшого и быстрого характера AJAX, где в качестве стандартного веб-сервера можно выделить отображение веб-страниц в обычном смысле.область опроса полностью независима от браузера.Вы можете обнаружить, что в дальнейшем продавцы в вашей системе предпочитают иметь собственное приложение или даже приложение для iPhone / Android.API REST позволит вам сделать это из любого приложения, которое может сделать HTTP-запрос.

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