Web服务分页中使用DB cursor生成continuation token相关问题

1. 如何生成可供服务使用的continuation token #

Cassandra 原生自动分页能力基于PagingState对象实现，你可以按以下步骤生成符合接口要求的token：

• 首次不带分页标记查询时，执行CQL语句后从结果集中取出二进制格式的PagingState对象
• 对二进制内容做URL安全的Base64编码：将标准Base64中的+替换为-、/替换为_、去掉末尾的填充符=，处理后的字符串即可作为continuation_token参数使用，直接拼接在接口路径后，例如/service_name?continuation_token=编码后字符串
• 收到用户携带token的后续请求时，先做Base64解码还原为原生PagingState对象，传入下一次CQL查询的配置项中，即可从上一次查询中断的位置继续返回数据。

2. DB cursor是否为短期有效？能否直接作为continuation token使用 #

• 你提到的Cassandra侧的DB cursor对应就是PagingState，它是短期有效的：集群拓扑变更、对应表Schema修改、节点重启、版本升级都会导致历史PagingState失效，失效后携带对应token的查询会直接抛出异常。
• 它可以作为生成continuation token的基础，但绝对不能直接对外暴露使用：
  • 原生是二进制格式，不符合HTTP请求参数的传输规范，必须做编码处理
  • 内部包含Cassandra集群的拓扑、数据分布等敏感信息，直接对外暴露有安全风险，建议编码前再加一层对称加密做脱敏
  • 如果你的业务需要支持用户间隔数小时甚至数天继续翻页，不要用原生PagingState生成token，建议自己基于表的分区键、聚类键实现自定义分页标记：记录上一页最后一条数据的聚类键取值，下一次查询直接从该取值之后扫描数据，这种自定义token不受集群状态影响，永久有效。

额外参考：同场景下MongoDB的cursor逻辑和Cassandra类似，默认10分钟无操作就会被服务端自动回收，同样不建议直接传递cursor ID作为continuation token，高并发场景下会占用大量服务端资源，更推荐基于排序字段做自定义分页标记。

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