如何灵活高效的接入？
平台化
•搭建平台而不是搭建项目——做一个“淘宝”而不是做只针对某几项业务的网站
•从业务中抽象及通用——如果一种业务有可能在今后重复出现，那就将其模块化，系统化（如批处理系统），发展成为平台能力
动态化
•流程动态化——不同的业务类型对应的流程可以随意调整，无须调整代码
•代码动态化——采用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的原理中阐述了这一点，有兴趣的人可以研究
如何保持系统稳定性?
限流
•大促期间如遇大流量可以针对业务渠道限流开关推送标志以限流
降级
•在高峰期间将一些运营查询相关的需求停止，减小数据系统负担，并调度到半夜12点继续查询
预案
•每次大促前都得准备预案。预案需要准备各种极端失败情况，确保失败时不手忙脚乱
343
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
