В этой статье представлена реализация и применение очереди сообщений PHP. Чтобы поделиться с вами для вашей справки, следующим образом:
В интернет-проектах разработчики часто сталкиваются с “массовыми пользователями, отправляющими текстовые сообщения”, “система заказов имеет большое количество журналов для записи” или сервер не выдерживает давления мгновенного параллелизма при секционировании бизнеса.
В этом случае, как мы можем обеспечить нормальную и эффективную работу системы?
В настоящее время мы можем ввести концепцию под названием “очередь сообщений” для решения вышеуказанных требований.
Концепция, принцип и сценарий организации очереди сообщений
В случае высокого параллелизма программа часто не справляется со временем. Мы вводим промежуточную систему для шунтирования и разгерметизации.
Таким образом, по сути, очередь сообщений-это промежуточное программное обеспечение структуры очереди. То есть, после того как вы поместили сообщение и содержимое в этот контейнер, вы можете напрямую вернуть его, не дожидаясь результатов его последующей обработки. Также будет программа, которая считывает данные и обрабатывает их по порядку.
1. Промежуточное программное обеспечение структуры очередей 2. После того, как сообщение введено, его не нужно обрабатывать немедленно. 3. Обрабатывается подписчиками/потребителями в порядке
То есть: когда вы сталкиваетесь с большой или трудоемкой ссылкой, и вашему бизнесу не нужно немедленно узнавать результаты этой ссылки, использование очереди сообщений-хороший выбор.
Основная структура выглядит следующим образом:
Сценарии очереди сообщений
I. когда данные нуждаются в избыточности Например, в системе заказов, требуется последующее преобразование и запись данных. Очередь сообщений может постоянно хранить эти данные в очереди, а затем программа последующей обработки заказов обработает их. После обработки запись будет удалена из очереди.
Развязка системы Очередь сообщений решает проблему глубокой связи между двумя системами. При использовании очереди сообщений нет прямой связи между системой в очереди и системой в очереди. Система входа и система выхода, одна из которых не повлияет на нормальную работу другой после сбоя.
III. пик бритья То есть, когда второй убьет и бросится покупать, произойдет резкое увеличение трафика, что оказывает большое давление на сервер. В реальной разработке проекта хорошей схемой является использование очереди сообщений с кэшем.
IV. асинхронная связь Очередь сообщений сама по себе реализует асинхронную работу программ, поэтому очередь сообщений может использоваться до тех пор, пока она подходит для асинхронных сценариев.
V. расширяемость Например, система заказов после поступления заказа в команду может иметь финансовую систему для последующей обработки, но если добавлена система распределения. Просто позвольте системе распространения подписаться на очередь сообщений.
Ви. гарантия последовательности В некоторых сценариях последовательность обработки данных очень важна. Саму очередь можно превратить в один поток, один в одной системе. Таким образом, чтобы эффективно гарантировать, что данные обрабатываются в порядке.
Преимущества и недостатки реализации общей очереди
Носитель очереди:
MySQL: высокая надежность, простота реализации и низкая скорость Red-это: быстрая, низкая эффективность для одного большого пакета сообщений Система сообщений: профессиональная, надежная, высокая стоимость обучения (например, rabbitimq)
Механизм запуска обработки сообщений:
Считывание мертвого цикла: легко реализовать, невозможно восстановить вовремя в случае сбоя; Задача синхронизации: распределение давления с верхним пределом производительности обработки. (самый большой недостаток: необходимо точно определить временной интервал задачи позиционирования и обрабатываемые данные. Если предыдущая задача не была обработана, будет запущена следующая.) Демоны: аналогично php -fpm и php-cgi, требующие знаний оболочки
Случай разделения: система заказов на обработку очередей и система распределения
Мы уже видели сценарий использования очереди сообщений раньше.
Здесь мы рассмотрим один из сценариев: разъединение системы.
В проекте электронной коммерции, когда клиент отправляет заказ, клиент может видеть, что заказ находится в доставке в личном центре. В это время нам нужно участвовать в системе, называемой “система распределения”. Если мы разработаем систему заказов и систему распределения вместе при построении архитектуры, возникнут некоторые проблемы: давление системы заказов относительно велико, но системе распределения не нужно своевременно реагировать на эти давления; нам не нужно вызывать сбой системы распределения после сбоя системы заказов.
Поэтому нам нужно разделить эти две системы и реализовать связь этих двух систем через средний список команд.
Как показано на следующем рисунке:
Специфичная для нашего программного кода общая логика заключается в следующем:
Общий процесс: order.php получает заказ пользователя, генерирует номер заказа и обрабатывает заказ (система заказов); в системе заказов данные, требуемые системой распределения, будут внесены в список команд; наша система распределения, goods.php, будет иметь сценарий синхронизации, который выполняется каждую минуту для обработки данных в списке команд.
Простой список проектной группы
CREATE TABLE `order_queue` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `Order [ID ` int (11) unsigned not null comment 'order ID (from order system)', `User_info ` varchar (255) not null default '' comment 'can be the user's mobile number / user ID, etc. (here is just a demonstration)', `Created "at ` datetime not null comment 'order creation time', `Updated "at ` datetime not null comment 'the last processing completion time of this record', `Status ` tinyint (2) not null comment '0 not processed, 1 processed, 2 processing', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
Очередь заказов MySQL
Мы уже анализировали логику раньше, а остальное-реализация кода.
Примечание: Я просто демонстрирую код здесь, просто чтобы показать процесс реализации.
1. Получите заказ и обработайте order.php
$order_id,
'user_info'=>$_GET['user_info'],
'created_at'=>date('Y-m-d H:i:s',time()),
'status'=>0
);
//Insert the above data into the order queue table
// insert into order_queue
}2. Система распределения goods.php
0);
$lock = array('status'=>2);
//Mark the record with the status of 0 as 2, and update 3 records each time (depending on the situation)
$sql = "update order_queue set status=2 where status=0 limit 3";
//2、
If (update above succeeded){
//Select the order content to be processed
// select * from order_queue where status = 2;
//It is then processed by the distribution system
// todo...
//3. After processing, update the order status to completed.
$success = array(
'status'=>1,
'updated_at'=>date('Y-m-d H:i:s',time())
);
}else{
echo 'All Finished';
}3. Задача синхронизации сервера Linux
Напишите сценарий оболочки: goods.sh
#!/bin/bash date "+%G-%m-%d %H:%M:%S" cd /var/www/ php goods.php
Этот сценарий предназначен для выполнения orders.php программа.
Для развертывания запланированной задачи на сервере Linux:
crontab -e */1 * * * * /var/www/goods.sh >> /var/www/goods_shell.log 2>$1
Оформите товар.sh-файл один раз в минуту и записывайте журнал в goods_shall.файл журнала (создайте файл в соответствующем каталоге)
Для получения дополнительной информации о PHP читатели, интересующиеся PHP, могут обратиться к темам нашего веб-сайта: Учебник по структуре данных и алгоритмам PHP, краткое описание алгоритма программирования PHP, краткое описание использования строк PHP, навыки работы с массивами PHP, общий алгоритм обхода PHP и краткое описание навыков и краткое описание навыков математических операций PHP.
Я надеюсь, что эта статья будет полезна для программирования на PHP.