SQL存主数据同步ES场景下，需实时数据的机器人端是否需单独搭建SQL取数API

没必要从零搭建一套和现有UI端API完全平行的、独立直连SQL的独立服务，这种做法在当前场景下属于过度拆分，重复维护成本很高，业界更通用的落地方式是在现有统一API架构上做数据源分层路由，而非平行建设两套割裂的查询链路。

• 逻辑重复成本高：两类客户端的查询需求高度相似，独立搭两套意味着同样的权限校验、业务过滤规则、字段映射逻辑要维护两份，后续任何业务规则调整都要两边同步迭代，很容易出现逻辑错位——比如UI端过滤了未审核的敏感数据，bot端的独立API漏了同样的规则，就会出现数据合规问题。
• 能力重复建设：现有API层已经做过的鉴权、限流、日志、错误码统一这类通用能力，独立的SQL直连API要全部重新实现一遍，平白增加运维和测试成本。
• 主库压力容易失控：独立的API没有和现有链路做统一的流量管控，很容易因为bot侧的流量波动直接冲击SQL主库，影响核心交易写入的稳定性。

1. 统一API层做动态数据源路由 #

把原来硬绑定ES的API处理器，改成根据请求携带的实时性标识自动切换数据源：

• UI端的请求默认携带stale_allowed=true标识，走原有的ES查询链路，充分利用ES的大规模检索性能。
• bot侧需要实时数据的请求，携带require_realtime=true标识，API层将同一套查询语义自动翻译成SQL查询语句，直接从主库取数。
• 核心原则是查询逻辑只维护一份：上层接收的查询条件、返回结构、业务校验规则都是同一套代码，只是最后根据数据源类型做语法适配，不做两套独立的逻辑。

2. 做细粒度的性能和一致性平衡 #

不需要对所有bot请求都走全量直连SQL，按实时性要求分层处理：

• 对允许10秒以内延迟的bot请求，可以走“ES快速检索 + 增量一致性补偿”的逻辑：先用ES返回大部分匹配结果，再比对SQL主库最近数秒的写入增量，把缺失的记录补充到返回结果中，既保证了实时性，也不会对主库造成过高的查询压力。
• 只有要求强实时、零延迟的请求，才完全切换到直连SQL的路径，并且给这类请求单独配置SQL访问的限流规则，避免查询流量冲击主库的写入性能。

3. 长期演进的平衡方向 #

直连SQL的链路只是阶段性的兜底方案，不是长期的最优解：

• 如果后续bot侧的实时查询量持续上涨，要优先优化现有ES同步链路的延迟（比如把当前3-4秒的延迟压到1秒以内），逐步把bot请求也切回ES链路，毕竟SQL主库是为事务写入优化的存储，并不适合承载大规模的复杂检索请求。
• 要明确划清两类链路的使用边界，禁止UI端的请求因为临时需求走SQL取数，避免主库被非核心检索流量占用。

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