Problemas que todo desenvolvedor Workerman deve saber

1. Restrições do ambiente Windows

No sistema Windows, o Workerman suporta apenas mais de 200 conexões em um único processo.
No sistema Windows, não é possível usar o parâmetro count para definir multiprocessos.
No sistema Windows, não é possível usar os comandos status, stop, reload, restart, etc.
No sistema Windows, não há suporte para processos em segundo plano, assim que a janela do cmd é fechada, o serviço é interrompido.
No sistema Windows, não é possível inicializar múltiplos ouvintes em um único arquivo.
No sistema Linux, não existem essas restrições. Recomenda-se usar o sistema Linux em ambientes de produção, enquanto o sistema Windows pode ser utilizado em ambientes de desenvolvimento.

2. Workerman não depende de Apache ou Nginx

O Workerman já é um container semelhante ao Apache/Nginx, e desde que o ambiente PHP esteja OK, o Workerman pode ser executado.

3. Workerman é iniciado via linha de comando

O método de inicialização é semelhante ao do Apache, utilizando um comando para iniciar (geralmente o espaço web não permite o uso do Workerman). A interface de inicialização é semelhante a esta abaixo:

4. Conexões longas devem ter heartbeat

Conexões longas devem ter heartbeat, conexões longas devem ter heartbeat, conexões longas devem ter heartbeat, é tão importante que deve ser repetido três vezes.
Conexões longas que não comunicam por um longo período podem ser limpas pelos nós de roteamento, resultando no fechamento da conexão.
Descrição do heartbeat do Workerman, Descrição do heartbeat do GatewayWorker

5. O protocolo entre cliente e servidor deve corresponder para comunicação

Este é um problema muito comum para os desenvolvedores. Por exemplo, se o cliente usa o protocolo websocket, o servidor também deve usar o protocolo websocket (o servidor new Worker('websocket://0.0.0.0...')) para que a conexão e a comunicação sejam possíveis.
Não tente acessar a porta do protocolo websocket pela barra de endereços do navegador, não tente usar o protocolo websocket para acessar portas de TCP nuas; o protocolo deve corresponder.

O princípio aqui é semelhante ao de se comunicar com um inglês: deve-se usar inglês. Para se comunicar com um japonês, deve-se usar japonês. Aqui, as linguagens são análogas aos protocolos de comunicação, ambos (cliente e servidor) devem usar a mesma linguagem para se comunicarem. Caso contrário, a comunicação não será possível.

6. Possíveis causas para falhas na conexão

Um problema muito comum ao usar o Workerman pela primeira vez é a falha na conexão do cliente ao servidor. As causas geralmente são:

O firewall do servidor (incluindo grupos de segurança de servidores em nuvem) bloqueou a conexão (50% de chance que seja isto)
O protocolo usado pelo cliente e servidor é inconsistente (30% de chance)
O IP ou a porta estão incorretos (15% de chance)
O servidor não foi iniciado

7. Não use as instruções exit, die, sleep

Executar as instruções exit ou die no negócio fará com que o processo saia, resultando no erro WORKER EXIT UNEXPECTED. Claro, ao sair, um novo processo será imediatamente reiniciado para continuar o serviço. Se for necessário retornar, pode-se usar return. A instrução sleep fará com que o processo entre em modo de espera, e durante esse tempo não executará nenhum negócio; o framework também parará, fazendo com que todos os pedidos de cliente desse processo não sejam processados.

8. Não use a função pcntl_fork

pcntl_fork é usada para criar novos processos dinamicamente. Se você usar pcntl_fork no código de negócios, pode acabar criando processos órfãos que não podem ser coletados, resultando em anomalias. No negócio, o uso de pcntl_fork também afetará o manuseio de conexões, mensagens, encerramento de conexões, temporizadores e outros eventos, causando anomalias imprevisíveis.

9. Não deve haver loops infinitos no código do negócio

Não deve haver loops infinitos no código do negócio, pois isso impedirá que o controle seja devolvido ao framework Workerman, impossibilitando a recepção e o processamento de outras mensagens de clientes.

10. Para alterar o código, é preciso reiniciar

O Workerman é um framework residente em memória, e para ver os efeitos do novo código, é necessário reiniciar o Workerman.

11. Aplicações de conexão longa devem usar o framework GatewayWorker

Muitos desenvolvedores usam o Workerman para desenvolver aplicações de conexão longa, como comunicação em tempo real, Internet das Coisas, etc. Recomenda-se usar diretamente o framework GatewayWorker, que é uma encapsulação adicional sobre o Workerman, facilitando e simplificando o desenvolvimento de aplicações de conexão longa.

12. Suporte a alta concorrência

Se o número de conexões concorrentes em seu negócio exceder 1000 simultaneamente online, certifique-se de otimizar o kernel do Linux e instalar a extensão event.