Cadence 0.11版本是否有更快获取workflowHistory的方案？

API调用参数优化 #

• 收紧过滤规则：根据业务实际需要选择最窄的filterType枚举值，仅拉取需要的事件类型，避免使用全量过滤HISTORY_EVENT_FILTER_TYPE_ALL_EVENT，可直接降低服务端查询、序列化以及网络传输耗时。
• 按需配置长轮询开关：若业务无需等待未产生的新事件，强制将isLongPoll设为false，避免长轮询的等待耗时。
• 分页拆分拉取：针对事件量较大的工作流，通过HistoryEventIterator的原生分页能力按固定大小分批拉取事件，避免单次请求加载全量历史导致的高耗时和超时风险。

服务端配置调整 #

• 扩容历史存储读资源：为Cadence历史服务依赖的Cassandra/MySQL存储节点新增读副本，针对history相关表开启读请求负载均衡，分散高频读压力。
• 开启服务端历史分片缓存：Cadence历史事件写入后为不可变数据，不存在一致性问题，可在服务端配置文件中调大history.cacheSize参数，开启热历史分片的内存缓存，无需业务端做缓存适配即可降低读耗时。
• 调整读限流阈值：若业务调用QPS超过服务端默认限流阈值，会触发请求排队导致耗时升高，可调整history.rpsLimit、history.readRPSLimit参数匹配业务调用量级。

版本升级优化方案 #

如果可以迭代Cadence版本，可升级至0.12及以上版本：

• 0.12版本对历史事件拉取逻辑做了序列化优化，同等数据量下请求耗时平均降低30%以上。
• 新增的GetWorkflowHistoryRawAPI无需服务端做事件反序列化处理，直接返回二进制序列化数据，性能较原API可提升1倍以上。

架构优化方案 #

如果业务需要持续监听多个工作流的历史变更，可替换轮询拉取方案为服务端主动推送：
注册全局事件监听器或者Archival事件队列，由Cadence服务端主动推送历史事件变更，可大幅降低拉取类请求的数量和整体耗时。

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