票务系统逻辑

票务系统逻辑

目前我们有一个票务管理系统,与所有票务系统一样,它需要以循环方式将案例分配给代理。同时,代理可以应用自己的过滤逻辑并处理他们的队列。

问题,

  1. 现在包含票证的表格非常大,跨越 1000 多万行。
  2. 一张票绝不应该分配给两个不同的用户。
  3. 为了解决上述问题,我们有以下流程,
  4. 选择查询使用过滤条件触发并限制 0,1
  5. 然后根据 id 选择上述查询返回的行并锁定以进行更新。
  6. 最后,我们触发更新,说明用户 X 已选择该案例。
  7. 当步骤 3 执行时,其他用户无法获得同一案例的锁定,因此他们可能会多次触发 3.a 查询以获取下一个可用案例。
  8. 随着用户数量的增加,步骤 4 中的时间也越来越长。

我们尝试在步骤 4 中执行 select for update in query,但这会使整个查询变慢。假设这是因为 select 查询中的行数太多。

问题,

  • 我们是否需要采取完全不同的方法?
  • 在存储过程中执行选择和更新是否可以确保与执行选择更新然后更新相同的结果?

答案1

我会像这样解决这个问题:

  1. 更新第一张待处理的票据,由用户 USERID 处理:

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

  2. 获取门票

    SELECT * FROM tickets WHERE processedby=USERID

  3. 处理完票证后,更新票证。

相关内容