高并发风控技术解密(下)

如何灵活高效的接入?

平台化

  •搭建平台而不是搭建项目——做一个“淘宝”而不是做只针对某几项业务的网站

  •从业务中抽象及通用——如果一种业务有可能在今后重复出现,那就将其模块化,系统化(如批处理系统),发展成为平台能力

动态化

  •流程动态化——不同的业务类型对应的流程可以随意调整,无须调整代码

  •代码动态化——采用groovy脚本动态调整线上代码,无须发版;规则配置除了使用各种灵活预配置外,还可以使用groovy脚本代码化规则;指标函数groovy化,不需要每次发版。

  •配置动态化——配置动态化可以考虑虚拟表的形式,通过虚拟表将任意表的结构存储到一个统一的表结构中去,从而完成配置的动态化,有些类似nosql的文档化思想。

如何降低响应时间提高吞吐量?

善用存储及缓存

  •配置数据加载到本地内存

  •频繁重复访问的数据放redis

  •数量较大稳定性要求较高的放hbase

  •需要快速搜索的明细数据放es

•需要解耦削峰的数据放kafka

如下图,不同的存储读取时间是有很大差别的,应当利用好各种存储,尽可能的用耗时小的存储

下图是hbase的一个基准性能测试,千万不要忽略hbase哦,它既能存取海量数据,又能以极短的时间响应,实在是风控系统性能提升的利器。目前的风控系统最重要的累积数据,就是基于hbase存取的

异步化

  •从系统架构层面,将可异步的代码尽量异步,但忌滥用异步

  下面是一个实际的例子,在压测过程中,发现CPU的sy和wa很高,大体可以判断是线程过多,并且浪费在线程切换,据观察,启用异步线程调用3个外部调用的耗时并不低,于是该分支线程等待时间过长,导致占用大量线程在等待IO,线程也频繁切换。

基于动态流程配置,将主系统中3个外部调用合并为一个之后,sy和wa大大降低,不再出现被压垮的情况,而被合并的剩下两个调用,放到kafka解耦之后继续调用。

  单机TPS 2,644.6->3,079

    单机平均响应时间149.3->126.03

  •日志打印异步化--log4j2 all async,大大提高吞吐

  日志对于TPS的影响绝对无法忽视,曾试过禁止打印所有日志,系统TPS直接从3000飙升到4200。

如果不打印日志,线上系统就没法运维。在风控系统里,日志是很重要的排查工具和手段。log4j2的出现,就是为了大吞吐打印日志的,其中all async实现全异步打印,中间用到了disruptor来提速,至于disruptor为什么快,参考之前的文章高并发风控技术解密(上)

  单机TPS 3,079 ->3,686.1

    单机平均响应时间126.03->79.35

  •降低线程数量,从而降低系统cpu时间,异步网络调用--netty的客户端应用

  为保障主线程的吞吐和执行时间,经常需要把网络调用异步化,一些重要的异步化网络调用也需要占用线程池中大量线程,线程数量一多,sy就居高不下,既浪费cpu,又会导致整个tps全线崩溃。

采用nio的netty客户端无疑是解决这个问题的利器。如下图,左边是每个线程一个连接等待,耗费大量线程在等待,会导致sy和wa提升,采用基于netty框架的客户端之后,将连接线程限制到一个很小的数目,而回调的业务线程也会保持在一个较小范围并且保持忙的状态,而不是把时间耗费在sy和wa上

  •用好线程池,保持系统稳定

线程池实际上是保持系统稳定的重要方式,保持资源在一个可控的范围内而不是无限制的增加资源压垮机器,这点尤为重要。

如何应对大数据?

增量化思维

  •问题:需要从原始表计算到结果表,由于增量的结果表无法被复用,只能每天计算全量的结果表,计算任务看似巨大(计算任务为182小时)

  •解决:将每次需要全量计算转化为:每次增量计算到明细表,再从明细表全量计算到结果表(实际计算第一次跑得较慢,后续每次跑只需要几小时)

海量关联关系查询

•问题:在关联关系查询中,经常从几个简单的关联查到大量数据,如何处理大量数据,将其排序,分页,供人工调查?

  •解决:利用es多次查询,redis缓存分页信息。算法很简单,实际过程会遇到很多问题,比如ip关联出来经常是海量数据,数据查询会超时,后续查询更加庞大。一些小技巧是:数据尽早剪枝;业务查询限制,如限制查询时间;ES的多重查询,可以一次性将数据作为查询条件输入。分布式的TOPK问题比较有意思,ES的原理中阐述了这一点,有兴趣的人可以研究

另一种方式是将关系直接存储为图,即顶点和边关系,查询时将极其简单,这方便的代表是图数据库neo4j,由于存储需要再导入,因此并未做深入研究,同样供有兴趣的同学参考

如何保持系统稳定性?

限流

  •大促期间如遇大流量可以针对业务渠道限流开关推送标志以限流

降级

  •在高峰期间将一些运营查询相关的需求停止,减小数据系统负担,并调度到半夜12点继续查询

预案

  •每次大促前都得准备预案。预案需要准备各种极端失败情况,确保失败时不手忙脚乱

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序人生

想让服务器跑得快,并不是换个编程语言那么简单

最近一个读者问我:程序君,我是一个经常被你黑的phper,我想学一门新的语言,做服务器开发,看你好像用过好多语言,能推荐一个么?最好是开发效率高,支持并发,性能...

42280
来自专栏更流畅、简洁的软件开发方式

【角色】——分离开代码和权限需求,即实现代码和权限需求的解耦。

今天突然来了一个灵感,记录一下。以前总觉得说不清楚,看看这种表达方式是否可以说清。 两个原则:依赖接口编程,不要依赖实现编程;最小获知原则。 面向对象最重要的是...

24950
来自专栏京东技术

京东价格保护高并发 | 七步走保证用户体验

2014年加入京东,负责京东财务退款及价格保护研发建设,擅长京东逆向流程场景、金额拆分计算、高并发下网站优化。

15530
来自专栏华章科技

从 Python 转到 Go 语言的五大理由

“ Python 是非常强大的,特别是 Python3 有了异步功能,但是 GO 将完全取代它在大企业中的存在…”如果你真正理解了引号中的话,你可能会去尝试 G...

20930
来自专栏韩伟的专栏

GCloud的设计目的

提高游戏服务器端逻辑的开发效率 ? 游戏服务器端有三个常用的典型功能,几乎每个游戏都要反复实现的。而这几个功能,都会符合一些最佳建模和最佳实践: 客户端拉取服...

72260
来自专栏极客猴

高并发的那些事

"高并发"对后台开发同学来说,既熟悉又陌生。熟悉是因为面试和工作经常会提及它。陌生的原由是服务器因高并发导致出现各位问题的情况少之又少。同时,想收获这方面的经验...

63830
来自专栏SDNLAB

ODL Lithium SR2版本Entity Ownership Service分析及OFplugin规模部署可用预测

家好,我是盛科网络负责sdn研发的张东亚,作为sdn设备的提供商,业余非常关注sdn生态圈的发展,最近抽时间研究了li版本of plugin的代码,记录了一些心...

33150
来自专栏Brian

Effective Debugging-高效调试

概述 最近在看《Effective Debugging》,作者(Diomidis Spinellis)将30多年的系统开发和调试的经验融入到书中,从策略、方法以...

37280
来自专栏后端技术探索

58同城高性能移动Push推送平台架构演进之路

关于作者:孙玄,58赶集集团系统架构师,技术负责人,技术委员会架构组主任,也是58同城即时通讯、C2C技术负责人,负责58核心系统的架构以及优化工作。分布式系统...

29220
来自专栏Golang语言社区

为Go语言GC正名-2秒到1毫秒的演变史

下面我们会介绍https://www.twitch.tv视频直播网站在使用Go过程中的GC耗时演变史。 我们是视频直播系统且拥有数百万的在线用户,消息和聊天...

55550

扫码关注云+社区

领取腾讯云代金券