Lógica do sistema de emissão de bilhetes

Question

Atualmente, temos um sistema de gerenciamento de tickets e, assim como todos os sistemas de tickets, ele precisa atribuir casos de maneira circular aos agentes. Além disso, ao mesmo tempo, o agente pode aplicar sua própria lógica de filtragem e trabalhar em sua fila.

O problema,

1. A tabela com os tickets é muito grande agora, com mais de 10 milhões de linhas.
2. Um ticket nunca deve ser atribuído a dois usuários diferentes.
3. Para resolver o problema acima, este é o fluxo que temos,
4. Selecionar consulta é disparada com critérios de filtro e limite 0,1
5. A linha retornada pela consulta acima é selecionada com base no ID e bloqueada para atualização.
6. Por fim, acionamos a atualização dizendo que o usuário X escolheu o caso.
7. Enquanto a etapa 3 é executada, outro usuário não pode obter um bloqueio no mesmo caso, portanto eles são acionados 3.uma consulta pode ser várias vezes para obter o próximo caso disponível.
8. À medida que o número de usuários aumenta, esse tempo na etapa 4 aumenta e aumenta.

Nós tentamos fazer um select para atualização na query no passo 4, mas isso faz com que toda a query fique lenta. Supondo que isso ocorra porque um grande número de linhas na consulta de seleção.

Perguntas,

• Existe uma abordagem diferente que precisamos tomar completamente?
• A seleção e a atualização em um procedimento armazenado garantem os mesmos resultados de selecionar e atualizar?

Answer 1

Eu abordaria o problema assim:

1. Atualize o primeiro ticket aberto a ser tratado pelo usuário USERID:

   UPDATE tickets SET processedby=USERID WHERE processedby = (SELECT id FROM tickets WHERE processedby=NULL LIMIT 0,1)

2. Obtenha o tíquete

   SELECT * FROM tickets WHERE processedby=USERID

3. Atualize o ticket depois de processá-lo.