如何修改Sanic请求排队/堆叠行为 强制请求按发送顺序执行

核心原因 #

你当前的配置（单worker、同步路由）无法保证请求按发送顺序执行，不是框架bug，是两个底层机制导致的必然结果：

• 请求接收顺序不匹配发送顺序：Sanic基于asyncio事件循环监听TCP端口，新请求的入队顺序由内核TCP协议栈上报的可读事件顺序决定，和客户端实际发送顺序没有强绑定关系。网络传输调度、内核协议栈处理逻辑都可能导致后发的请求先被事件循环接收，这也是你观察到第一个请求处理完成后后续请求顺序随机的核心诱因。
• 同步路由默认并发执行：Sanic不会在事件循环线程中直接运行非async定义的同步路由，而是会把同步逻辑丢到独立的线程池执行，默认线程池大小和CPU核心数挂钩，只要工作线程数大于1，多个请求就会并发处理，不存在全局排队逻辑。

可落地的实现方案 #

方案1：全局请求队列（100%满足严格顺序执行要求，框架层无侵入实现）

在应用内维护一个asyncio FIFO队列，所有请求进入后先入队，单独启动一个常驻消费协程，严格按照入队顺序逐个处理请求，一次只执行一个业务逻辑。这个方案不需要修改你现有的同步路由代码，完全在Sanic框架层面实现，能保证请求处理顺序和入队顺序完全一致。
最简实现代码如下：

from sanic import Sanic
from sanic.response import text
import asyncio

app = Sanic("ordered_service")
request_queue = asyncio.Queue()

# 常驻消费协程：串行处理队列内的请求
async def queue_consumer():
    while True:
        request, handler, result_future = await request_queue.get()
        try:
            # 同步执行原有路由逻辑
            resp = handler(request)
            result_future.set_result(resp)
        except Exception as e:
            result_future.set_exception(e)
        finally:
            request_queue.task_done()

# 服务启动前拉起消费协程
@app.listener("before_server_start")
async def init_consumer(app, loop):
    app.add_task(queue_consumer())

# 全局请求中间件：拦截所有请求入队，跳过默认的路由并发执行逻辑
@app.middleware("request", priority=999)
async def enqueue_request(request):
    handler = request.route.handler
    loop = asyncio.get_running_loop()
    res_fut = loop.create_future()
    await request_queue.put((request, handler, res_fut))
    return await res_fut

# 原有业务路由不需要做任何修改，保持同步写法即可
@app.route("/compute")
def compute_handler(request):
    # 你的大量计算逻辑放在这里
    return text("processing done")

if __name__ == "__main__":
    app.run(workers=1)

注意点：把这个入队中间件的优先级设为最高，保证请求一到达就进入队列，避免其他中间件逻辑干扰顺序。

方案2：单线程线程池（改动最小但无法完全保证顺序）

如果你不想引入队列逻辑，可以直接把Sanic执行同步路由的线程池大小设为1，强制同一时间只有一个同步路由在执行。但这个方案只能保证请求串行执行，无法解决内核上报请求顺序和客户端发送顺序不一致的问题，还是会出现乱序，仅适合对顺序要求不极端严格的场景。
配置方式很简单，启动时传入pool_size=1参数即可：

if __name__ == "__main__":
    app.run(workers=1, pool_size=1)

补充说明 #

不要尝试通过调整TCP参数、关闭keepalive这类方式依赖网络层保证顺序，TCP协议本身不保证不同连接上的请求到达顺序，没有应用层的排队逻辑，永远无法实现严格的请求顺序执行。
你提到的服务非RESTful、有状态的特性不影响上述方案的使用，这种全局串行队列是有状态强顺序业务场景下的常规实现方案，没有额外的兼容性问题。

内容的提问来源于stack exchange，提问作者TheOneTheOnly2