Principio de Reinicio Suave
¿Qué es un reinicio suave?
El reinicio suave es diferente al reinicio normal; permite reiniciar el servicio (generalmente se refiere a negocios de conexión corta) sin afectar a los usuarios, de modo que se pueda recargar el programa PHP y completar la actualización del código del negocio.
El reinicio suave se aplica generalmente durante el proceso de actualización de negocios o lanzamiento de versiones, y puede evitar el impacto de la temporal indisponibilidad del servicio debido a que el reinicio se produce al publicar código.
Nota
El sistema Windows no soporta reload.Nota
En negocios de conexión larga (por ejemplo, websocket), las conexiones se cortarán durante el reinicio suave de los procesos. La solución es usar una arquitectura similar a gatewayWorker, donde un grupo de procesos se encarga de mantener las conexiones y se establece el atributo reloadable de este grupo de procesos en false. La lógica del negocio inicia otro grupo de procesos worker para manejarlo, y el gateway se comunica con los procesos worker a través de TCP. Cuando se necesita cambiar el negocio, solo se reinician los procesos worker.
Restricciones
Nota: Solo los archivos cargados en los callbacks on{...} se actualizarán automáticamente después de un reinicio suave; los archivos cargados directamente en el script de inicio o el código escrito no se actualizarán automáticamente al ejecutar reload.
El siguiente código no se actualizará después de reload
$worker = new Worker('http://0.0.0.0:1234');
$worker->onMessage = function($connection, $request) {
$connection->send('hi'); // Código escrito no soporta actualización en caliente
};
$worker = new Worker('http://0.0.0.0:1234');
require_once __DIR__ . '/your/path/MessageHandler.php'; // Archivos cargados directamente en el script de inicio no soportan actualización en caliente
$messageHandler = new MessageHandler();
$worker->onMessage = [$messageHandler, 'onMessage']; // Supongamos que la clase MessageHandler tiene un método onMessage
El siguiente código se actualizará automáticamente después de reload
$worker = new Worker('http://0.0.0.0:1234');
$worker->onWorkerStart = function($worker) { // onWorkerStart es el callback que se dispara después de iniciar el proceso
require_once __DIR__ . '/your/path/MessageHandler.php'; // Archivos cargados después de iniciar el proceso soportan actualización en caliente
$messageHandler = new MessageHandler();
$worker->onMessage = [$messageHandler, 'onMessage'];
};
Después de modificar MessageHandler.php, ejecuta php start.php reload, MessageHandler.php se recargará en la memoria, logrando así la actualización de la lógica del negocio.
Sugerencia
El código anterior utiliza la instrucciónrequire_oncepara facilitar la demostración; si tu proyecto soporta autoloading PSR-4, no es necesario llamar a la instrucciónrequire_once.
Principio del Reinicio Suave
Workerman está dividido en un proceso master y procesos worker, el proceso master se encarga de monitorear los procesos worker, mientras que los procesos worker son responsables de recibir las conexiones de los clientes y los datos de solicitud recibidos, procesarlos y devolver los datos al cliente. Cuando se actualiza el código del negocio, en realidad solo necesitamos actualizar los procesos worker para lograr la actualización del código.
Cuando el proceso master de Workerman recibe la señal de reinicio suave, el proceso master envía una señal de salida segura (permitiendo que el proceso correspondiente complete su solicitud actual antes de salir) a uno de los procesos worker; una vez que este proceso sale, el proceso master crea un nuevo proceso worker (este nuevo proceso carga el nuevo código PHP), luego el proceso master envía nuevamente un comando de detener a otro proceso viejo, así se realiza el reinicio proceso por proceso, hasta que todos los procesos viejos hayan sido reemplazados.
Vemos que el reinicio suave se realiza haciendo que los procesos de negocio viejos salgan uno por uno y luego se creen nuevos procesos uno por uno. Para no afectar a los usuarios durante el reinicio suave, es necesario que los procesos no mantengan información relacionada con el estado del usuario, es decir, es mejor que los procesos de negocio sean sin estado, para evitar la pérdida de información debido a la salida del proceso.