如何灵活高效的接入?
平台化
搭建平台而不是搭建项目 -- 做一个 "淘宝" 而不是做只针对某几项业务的网站
从业务中抽象及通用 -- 如果一种业务有可能在今后重复出现, 那就将其模块化, 系统化 (如批处理系统), 发展成为平台能力
动态化
流程动态化 -- 不同的业务类型对应的流程可以随意调整, 无须调整代码
代码动态化 -- 采用 groovy 脚本动态调整线上代码, 无须发版; 规则配置除了使用各种灵活预配置外, 还可以使用 groovy 脚本代码化规则; 指标函数 groovy 化, 不需要每次发版.
配置动态化 -- 配置动态化可以考虑虚拟表的形式, 通过虚拟表将任意表的结构存储到一个统一的表结构中去, 从而完成配置的动态化, 有些类似 NoSQL http://blog.jobbole.com/1344/ 的文档化思想.
如何降低响应时间提高吞吐量?
善用存储及缓存
配置数据加载到本地内存
频繁重复访问的数据放 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 为什么快, 参考之前的文章 disruptor 框架为什么这么强大 http://blog.csdn.net/liweisnake/article/details/9113119 .
单机 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 点继续查询
预案
每次大促前都得准备预案. 预案需要准备各种极端失败情况, 确保失败时不手忙脚乱
来源: http://www.tuicool.com/articles/UFzqYjy