(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202210749790.8 (22)申请日 2022.06.29 (71)申请人 上海汇付支付有限公司 地址 200233 上海市徐汇区宜山路70 0号C5 栋5楼 (72)发明人 周晔　穆海洁　朱银锋　陈锋　 贾世纪　蔡华涛　徐航　徐清超　 (74)专利代理 机构 上海专利商标事务所有限公 司 31100 专利代理师 施浩 (51)Int.Cl. G06F 16/2455(2019.01) G06F 16/242(2019.01) G06Q 40/04(2012.01) (54)发明名称 一种软件应用多 级缓存及流 量过滤的方法 (57)摘要 本发明公开了一种软件应用多级缓存及流 量过滤的方法， 减少数据库访问， 消除存储和计 算瓶颈， 提升处理性能。 其技术方案为： 第一方 面， 聚合查询结果按记录数和时间区间来缓存， 降低数据库 负载， 提高响应时效。 第二方面， 采用 二级限流策略， 其中一级限流保护数据库为扩容 预留缓冲时间， 二级限额策略对 大额交易实现无 损管控。 第三方面， 利用布隆过滤器在空间和时 间方面有巨大优势， 其概率型数据结构天然契合 黑名单匹配的低命中率场景， 因此无需直接访问 redis库缓存， 系统性能得到数倍 提升。 权利要求书1页 说明书7页 附图5页 CN 115114335 A 2022.09.27 CN 115114335 A 1.一种软件应用多级缓存及流量过滤的方法， 其特征在于， 包括先进行的Mongo库访问 流量过滤的处理， 以及之后进行的Mo ngo库聚合 查询的处 理， 其中： Mongo库访问流 量过滤的处理过程包括： 首先通过第 一限流器判断流量是否大于第 一阈值， 若是则直接限流多余流量不访问数 据库， 若否则继续执 行下一步骤； 通过第二 限流器判断流量是否大于第二阈值， 若是则继续判断是否为小额交易， 若为 小额交易则不访问数据库， 若不会小额交易则进行Mongo库聚合查询， 其中第一阈值大于第 二阈值； Mongo库聚合 查询的处 理包括： 步骤1： 判断缓存是否命中原始的聚合查询请求， 若命中则执行步骤2， 若未命中则执行 步骤3； 步骤2： 在命中缓存的情况下， 缩短原始的聚合查询请求的查询时间区间以生成新的聚 合查询请求， 再 执行步骤3； 步骤3： 进行Mo ngo库的聚合 查询； 步骤4： 判断Mongo查询结果是否触发缓存阈值， 如果触发则进行步骤5， 如果未触发则 Mongo库聚合 查询的流 程结束； 步骤5： 在内存中更新缓存的查询时间区间和聚合查询结果， 然后分别进行步骤6和步 骤7； 步骤6： 非当前缓存失效； 步骤7： 每隔设定周期将内存缓存持久化存 储。 2.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， Mongo库 访问流量过滤 的处理中， 第一限流器和第二限流器的配置组成了数据库二级限流策略， 其 中一级限流保护数据库为扩容预留缓冲时间， 二级限额策略对大额交易实现无损管控。 3.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， 步骤1中 是根据聚合条件SQL是否一致来判断缓存是否命中， 若一致则判定为命中， 若不一致则判定 为未命中。 4.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， 在步骤3 中， 若是在未命中缓存的情况下， 当前聚合查询结果是基于原始的聚合查询请求直接查库 所得到的聚合查询结果； 若是在命中缓存的情况下， 当前聚合查询结果是之前缓存的聚合 查询结果和步骤2中所生成的新的聚合 查询请求所 得到的聚合 查询结果的总和。 5.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， 在步骤7 中， 持久化存储包括存储到本地磁盘或者云存储中， 以防应用启动 或应用故障时内存缓存 数据的丢失。 6.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， 在步骤7 中， 若遇到应用重启则将缓存从 持久化存 储预热到内存中， 以完成 缓存初始化。 7.根据权利要求1所述的软件应用多级缓存及流量过滤的方法， 其特征在于， 方法还包 括： 将布隆过滤器应用于名单匹配， 对名单进行压缩 映射后缓存于内存中， 在交易做名单 匹配时对不在redis库中的名单直接过 滤不访问库。权　利　要　求　书 1/1 页 2 CN 115114335 A 2一种软件应用多级缓存及流量过滤的方 法 技术领域 [0001]本发明涉及 一种多级缓存及流量过滤的方法， 具体涉及应用于支付领域的风控场 景下的软件应用多级缓存及流量过滤的方法， 为基础配置、 热点数据聚合计算、 键值匹配选 择和设计最佳的缓存方案， 减少数据库访问， 消除存 储和计算 瓶颈， 提升系统 处理性能。 背景技术 [0002]在支付领域的风控核心模块， 一般由路由、 规则引擎、 限额限次、 名单等构成。 其中 路由、 规则配置在千条以下， 借助内存缓存定时从RDS库(Relational  Database  Service， 关系型数据库)查询加载 可以轻松应对。 [0003]限额限次需要计算商户、 用户、 代理商等不 同交易主体在各交易场景下的累计金 额、 笔数。 过滤维度组合灵活多变， 面临的挑战和亟需解决的主 要问题是： [0004]一、 敏捷迭代的业 务， 需求变动频繁， 数据模型 无法确定； [0005]二、 业务并发访问量大， 需数千的QP S(Queries ‑per‑second， 每秒查询率)； [0006]三、 系统需支持可弹性扩展数据量， 每天都在增加计算能力和存储容量， 需弹性扩 展； [0007]四、 系统的响应速度必须足够快， 在百毫秒内返回结果。 [0008]基于以上业务特点， 由于主流技术中MongoDB天然支持高可用、 分布式、 高性能、 高 压缩、 schema  free、 完善的客户端访问均衡策略等功能， 因此最终选择MongoDB作为核心存 储。 随着业务发展交易量上升， 热点商户的日累计金额笔数聚合计算处理时长很快达几十 上百毫秒， 数据库负载也急剧升高。 [0009]另一方面， 风控核心模块中的黑名单匹配属于简单的比较。 由于主流技术中 Redis/memcached等高性能的key ‑value数据库， 为了保证效率， 数据都是缓存在内存中， 在 部分场合可以对关系型数据库起到很好的补充作用， 因此采用redis缓存作为名单存储库。 一笔交易中有多种名单类型， 每个名单类型有多个值， 计较次数在几十次以上。 黑名单库数 据量较大， 在百万级别以上， 另外黑名单的命中比例很低， 如直接使用redis则集群tps(系 统吞吐量)很容 易达到万级。 [0010]综上， 如何研发新的技术手段， 来降低数据库的负载， 提高响应时效， 是目前业界 亟待解决的问题。 发明内容 [0011]以下给出一个或多个方面的简要概述以提供对这些方面的基本 理解。 此概述不是 所有构想到的方面的详尽综览， 并且既非旨在指认出所有方面的关键性或决定性要素亦非 试图界定任何或所有方面的范围。 其唯一的目的是要以简化形式给出一个或多个方面的一 些概念以为稍后给 出的更加详细的描述之序。 [0012]本发明的目的在于解决上述问题， 提供了一种软件应用多级缓存及流量过滤的方 法， 能够减少数据库访问， 消除存 储和计算 瓶颈， 提升处 理性能。说　明　书 1/7 页 3 CN 115114335 A 3