Neki 的架构
内容提要
Neki为Postgres提供基于原生实例的分片扩展。核心组件：PostgresManager管理实例，Sidecar连接池，Router统一入口解析并路由查询，Admin负责故障转移与持久性策略，Operator在Kubernetes上管理生命周期，Replicator支持表迁移、重分片和在线DDL。etcd存储数据拓扑，确保各组件配置一致。
延伸解读
基于原生Postgres的架构选择
Neki没有修改Postgres内核，而是直接使用标准Postgres实例，因此保留了MVCC、事务和现有驱动兼容性。这种设计意味着用户无需改变应用连接方式，但Neki需要额外组件来管理实例、连接和查询路由。对于已经使用Postgres的团队，迁移成本较低，但需接受Neki在Postgres之上引入的抽象层。
分片一致性与权威分片机制
由于每个分片是独立Postgres集群，自定义类型的OID可能不同。Neki指定一个权威分片作为OID翻译源，确保客户端缓存类型信息时不会因分片不同而出错。同时，权威分片的Sidecar监控模式变更并通知Router，使路由层能及时感知表结构变化。这一机制是跨分片查询正确性的基础。
故障转移与持久性策略
Admin组件负责健康检查、故障检测和主库切换。它支持异步、同步和跨可用区同步三种持久性策略，分别对应不同的提交确认条件。故障转移时使用pg_rewind同步分歧数据，减少恢复时间。计划内切换（如升级）和紧急故障转移都通过Admin协调，Router可缓冲可重试查询，避免应用感知中断。
在线数据迁移与重分片
Replicator支持MoveTables、Reshard和OnlineDDL三种工作流，通过逻辑复制捕获变更并应用，实现数据在线迁移。OnlineDDL通过影子表加最终重命名完成模式变更，避免阻塞操作。切换阶段Router会缓冲查询，确保应用在数据迁移过程中保持可用。这些能力让Neki能在不中断服务的情况下调整数据布局。
Q&A
Neki 是什么？它和普通的 PostgreSQL 分片方案有什么不同？
Neki 是为原生 PostgreSQL 提供分片和扩展的解决方案。它不修改 PostgreSQL 源码，也不是兼容协议的重实现，而是基于普通的 PostgreSQL 实例构建，让应用通过单一连接字符串访问大规模分片数据库。
Neki 的 Router 组件是如何处理跨分片查询的？
Router 接收客户端连接，解析查询并根据分片布局进行规划。如果查询涉及多个分片（如跨分片连接或聚合），Router 会将其作为分布式查询执行，自行选择嵌套循环、哈希或合并连接，并基于成本估算做出决策。
Neki 如何保证自定义类型 OID 在不同分片间的一致性？
Neki 指定一个分片作为权威分片，该分片是自定义类型 OID 的翻译来源。当其他分片返回结果时，权威分片会将其中的自定义类型 OID 转换为一致的 OID，确保客户端缓存和解析正确。
Neki 的 Admin 组件在故障转移时做了什么？
Admin 会健康检查所有 Sidecar，跟踪复制延迟，并在主节点故障时协调紧急故障转移，提升一个副本成为新主节点。它还会使用 pg_rewind 将偏离的实例同步到新主节点的时间线，并维护每个分片的持久性策略。
Neki 的 Replicator 支持哪些数据迁移操作？
Replicator 支持三种工作流：MoveTables（迁移表，包括从外部 PostgreSQL 导入）、Reshard（重新分布数据以拆分分片）和 OnlineDDL（通过影子表在线修改表结构）。它通过逻辑复制流捕获变更并应用，实现数据同步。
Neki 的 Operator 在 Kubernetes 上如何管理集群生命周期？
Operator 将集群建模为层次结构：集群拥有路由器和分片，分片拥有运行 PostgreSQL 实例和 Sidecar 的 Pod。当配置变化时，Operator 决定创建、更新或删除哪些 Pod。对于运行中的实例，它会先构建替代实例并确认其赶上进度后再删除旧实例；对于故障节点，则从零重建。
