目前正在测试中:完成后将开放 GitHub 代码。

Ticketing Python 库

GitHub PyPI

仓库

bash

示例

基础示例

应用启动时创建一个broker并共享。wait=0是不入队的一次立即尝试,最大255秒;lease为1–250秒。最后的minimum-work budget为必填,可为0。客户端将不足一秒的值向上取整,并在发送前拒绝越界值或大于规范化lease的budget,绝不clamp。

python
from saro_ticketing import TicketBroker

broker = TicketBroker.connect("127.0.0.1:5225")
await broker.wait_ready(5)

async with await broker.acquire("key", 5, 30, 2) as ticket:
    token = ticket.token
    ...  # Verify/update token high-water and write in the same DB transaction.

Synchronous bridge:

python
with broker.acquire_sync("key", 5, 30, 2) as ticket:
    token = ticket.token
    ...  # Same DB transaction fencing and business write.

自动close/drop只是bounded best-effort release;需要确认结果时使用explicit release API。token必须在同一DB transaction中fence受保护写入。

需要了解的行为

  • 只要request可能已发送一个byte而丢失确定响应,结果就是Indeterminate。客户端不以相同owner自动重发A,caller不得进入critical section。
  • 发送前cancel为unsent;possible-send后cancel关闭session。若并发parse到grant token,则尝试bounded exact-token补偿release。
  • M、所有E、malformed/oversized/unknown response均为session-fatal;未确定的possible-send acquire为Indeterminate。
  • B是capacity的确定拒绝并立即返回。内部不retry;caller可在application backoff后用新owner开始新acquire。
  • explicit/compensating release仅在call/enqueue起绝对5秒内重试exact token。R成功,N表示已不存在或不是current token;没有最终响应是error,不能推定成功。
  • 只有保守剩余时间为正且足够required work budget时才返回Ticket。超过250秒的work在发送前unsupported。
  • DB fencing强制使用token:在同一DB transaction中拒绝token <= stored_high_water,更新high-water并执行business write,commit/rollback结束后release。

安全选项(Token · TLS)

所有选项都是可选的。token 应与服务器的 client_tokens 一致,TLS 有四种模式: 关闭 / 系统信任存储 / 指定 CA / 跳过校验(仅测试用)。

python
broker = TicketBroker(
    ["10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"],
    token="123",
    tls="system-roots",  # "off" | "insecure-skip-verify" | CA 文件路径
)

服务器端的令牌、TLS、集群配置可以在 Ticketing 服务器部署页面生成。