Neki Router：用一个 PostgreSQL 连接协调分片查询

预计阅读时间：8 分钟

应用接入分片数据库时，最棘手的部分往往不是保存数据，而是让业务代码理解分片规则、寻找目标节点，并处理跨分片查询。Neki router 提供了另一种边界：应用只连接一个 PostgreSQL 入口，而路由器负责规划并协调后端分片上的查询。

应用看到 PostgreSQL，路由器看到分片

从应用一侧看，Neki router 提供的是 PostgreSQL 连接。这意味着现有服务可以继续使用熟悉的 PostgreSQL 驱动、连接池和 SQL 工具，不必为每个分片分别维护连接逻辑。

路由器背后的工作可以拆成两个动作：

规划查询：判断一条 SQL 应该访问哪些分片，以及哪些工作可以下推到分片执行。
协调执行：向相关分片发出查询，并把结果整理成应用能够接收的 PostgreSQL 查询结果。

例如，带有明确分片键的查询通常具备较小的访问范围：

SELECT order_id, status, total_amount
FROM orders
WHERE tenant_id = 42
  AND order_id = 9001;

如果 tenant_id 是分片键，路由器就有机会把请求定位到对应分片。相反，下面的查询没有限定租户，可能需要协调多个分片：

SELECT status, count(*)
FROM orders
GROUP BY status;

这里需要注意：来源摘要只说明 Neki 会规划和协调分片查询，并未给出它支持的 SQL 子集、聚合策略或事务语义。因此，单分片定位和跨分片聚合是理解这种架构的典型示例，不应直接视为 Neki 已公开承诺的具体实现细节。

为什么这个连接边界很重要

如果没有统一入口，分片知识很容易扩散到每个应用：服务需要计算分片编号、选择连接池、处理节点变化，并在查询多个分片时合并结果。随着服务数量增加，同一套路由规则会出现多份实现，升级和排障成本也随之增加。

Neki router 把这个职责集中到数据库访问层。应用仍然提交 SQL，路由器则拥有后端拓扑和查询协调视角。这样做的直接价值是降低应用与物理分片布局之间的耦合，同时保留 PostgreSQL 连接作为兼容边界。

不过，兼容 PostgreSQL 连接并不等于拥有单机 PostgreSQL 的全部行为。团队在采用前仍需验证：

参数化查询、预处理语句和常用数据类型是否符合现有驱动预期；
JOIN、聚合、排序、分页等操作跨分片时如何执行；
多语句事务能否限制在一个分片，跨分片事务有什么约束；
超时、取消查询和部分分片故障如何反馈给客户端；
会话级状态、临时表和 PostgreSQL 扩展是否可用。

可以这样实践：用标准 PostgreSQL 工具验证入口

下面是一个可直接改造的连通性与行为测试。由于摘要没有提供 Neki 的实际地址、端口和认证格式，这里假设它暴露标准 PostgreSQL 连接参数。运行前替换 NEKI_HOST、NEKI_PORT、用户名、密码和数据库名。

export PGHOST="neki.example.internal"
export PGPORT="5432"
export PGUSER="app_user"
export PGPASSWORD="replace-me"
export PGDATABASE="app_db"
export PGCONNECT_TIMEOUT="5"

psql -v ON_ERROR_STOP=1 <<'SQL'
SELECT current_timestamp AS connected_at;

SELECT order_id, status, total_amount
FROM orders
WHERE tenant_id = 42
ORDER BY order_id DESC
LIMIT 10;
SQL

这段命令刻意使用 psql 和标准 PG* 环境变量，目的是验证 Neki 是否能作为普通 PostgreSQL 端点接入现有工具链。表名和字段需要替换成测试环境中的真实结构。

应用侧也可以继续使用 PostgreSQL 驱动。下面的 Python 示例需要安装 psycopg，并沿用相同环境变量：

python -m pip install "psycopg[binary]"

import os
import psycopg

conninfo = (
    f"host={os.environ['PGHOST']} "
    f"port={os.getenv('PGPORT', '5432')} "
    f"dbname={os.environ['PGDATABASE']} "
    f"user={os.environ['PGUSER']} "
    f"password={os.environ['PGPASSWORD']} "
    "connect_timeout=5"
)

with psycopg.connect(conninfo) as conn:
    with conn.cursor() as cur:
        cur.execute(
            """
            SELECT order_id, status, total_amount
            FROM orders
            WHERE tenant_id = %s
            ORDER BY order_id DESC
            LIMIT 10
            """,
            (42,),
        )
        for row in cur.fetchall():
            print(row)

这个示例保留了参数化 SQL，避免应用为了路由而拼接查询。至于 tenant_id 是否必须出现、它是否真的是分片键，以及路由器如何处理缺少分片键的请求，需要根据 Neki 的实际配置与文档确认。

上线前别只测“能连上”

对分片路由器而言，连接成功只是最低门槛。更有价值的验收方法，是从真实业务查询中挑选三组样本：明确命中单个分片的请求、必须访问多个分片的读请求，以及可能跨分片的写事务。分别记录延迟、返回结果、错误行为和资源消耗。

采用时可以遵循一份简短清单：

明确业务使用的分片键，并检查高频 SQL 是否携带它；
为单分片与跨分片查询分别建立延迟基线；
验证连接池、预处理语句、事务和取消请求；
对路由失败、分片超时和部分结果制定可观测性方案；
在确认 SQL 与事务边界后，再逐步迁移生产流量。

Neki router 的核心价值不是让分片消失，而是把分片规划与协调从应用代码中收拢到一个 PostgreSQL 连接入口。这个边界能否真正降低系统复杂度，最终取决于应用查询是否适合分片，以及团队是否验证了跨分片操作的性能和语义。

Neki Router：用一个 PostgreSQL 连接协调分片查询

应用看到 PostgreSQL，路由器看到分片

为什么这个连接边界很重要

可以这样实践：用标准 PostgreSQL 工具验证入口

上线前别只测“能连上”

相关推荐

建议反馈