Axon Query最大返回数据大小限制及超大数据处理咨询

Axon核心框架本身没有为查询返回结果设置任何硬编码的大小上限，实际业务运行中遇到的返回体积约束，全部来自你选型的配套组件默认配置，和框架本身无关：

• 若使用HTTP作为跨节点查询的传输通道，实际返回上限来自Web容器（Tomcat、Undertow等）配置的单响应报文最大体积
• 若使用AMQP、Kafka这类消息中间件做分布式查询总线的跨节点路由，返回上限来自对应中间件配置的单消息最大承载量
• 实际生产中最先触发的瓶颈往往是应用自身堆内存：如果查询处理器直接把Repository全量查询的结果加载到内存再返回，哪怕框架不做限制，数据量达到一定阈值就会直接触发OOM，根本走不到网络传输那一步。

针对会出现大体积返回的查询场景，可以按以下方案改造规避风险：

• 下推分页替代全量返回
  不要在查询处理器中直接返回repository.findAll()获取的全量List，给查询对象增加offset、limit分页参数，将分页条件直接下推到仓储层的数据库查询语法中，单次返回固定大小的数据集（根据单条对象体积调整，通常单页控制在100-500条即可），由消费端逐页拉取全量数据。注意不要把全量数据捞到应用内存后再做内存切页，这种方式和全量返回的内存风险没有本质区别。
• 流式分批遍历处理全量数据
  如果业务场景必须要遍历全量数据（比如批量导出、历史数据同步），不要用同步一次性返回的查询模式，改用Axon的流式查询/订阅查询能力：仓储层采用数据库游标逐批读取数据，查询处理器以固定批次为单位逐块把结果推送给消费端，全程不把全量数据加载到应用堆内存中，从源头避免大对象内存占用。
• 结果投影裁剪冗余字段
  绝大多数场景下的大体积返回，都来自于查询返回时携带了大量非必要字段：比如直接把仓储层的实体对象（嵌套了关联子实体、大文本审计字段、序列化用的冗余属性）直接返回，而不是只查询业务需要的核心DTO字段。这种裁剪可以直接把单条数据的体积压缩到原来的1/10甚至更低，从总量上降低返回的整体体积。
• 查询资源的隔离保护
  把大数据量的查询任务和核心交易类查询放到独立的线程池、内存配额下运行，给这类大查询配置单独的超时熔断规则，避免单次大查询占用过多应用资源，影响核心业务链路的正常运行。

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