从0到1:饿了么风控计数服务是如何炼成的

作者/分享人:饿了么技术社区
向 Ta 提问
在 QCon、ArchSummit、TOP100、SACC、SDCC、GITC 等各大技术大会上常会看到这么一群“技术网红”,现在他们也将会出现在饿了么的技术文化社区,包括现任饿厂北京研发中心负责人的“IT民工”史海峰、写前端的 Sofish、走到哪红到哪的老毕、还有写过代码做过架构,折腾过性能优化,擅长故障定位的饿厂框架总监兰建刚(及众多大神),当然还有一群热爱技术交流分享,视 coding 为乐的技术强人,在等大家交流哦~

从饿了么正式进入多活领域开始,也预示着饿了么业务开始迈入下半场,此时风控团队面临着严峻的挑战,风控需要在事前、事中、事后进行全方位的防御。

而计数器的业务几乎贯穿了整个风控的需求,规则根据计数器拦截用户风险动作,运营系统需要根据计数器分析出商家、用户的刷单行为。首先,各个系统充斥着大量重复相同的计数器代码,其次开发团队对于这样重复劳动除了感觉疲惫,还有点缺乏技术含量,最后这样的开发成本与模式,并不能快速满足风控业务的需求,此时一个通用的计数器服务迫在眉睫。


作者/分享人:伍正云,2016 年 4 月加入饿了么,目前在风控部门,主要负责 faraday 计数服务、gaos 变量引擎、mike、tesla 等风控相关服务。

已有96人预订
预订达标
文章出炉
交流日期
     
17.08.22
17.09.04
17.09.11 20:30
查看文章评论/提问
哈比
09月11日 20:30 会有一次线上交流,大家可以在本篇文章下方「写评论」提问。这篇文章有什么地方不理解的,或者有什么主题相关的问题,都可以提问哦~ 线上交流时,伍正云老师将会按照提问的先后顺序进行回答:)
Quora
中间值是历史的时间窗口计数器计算而来的结果。这句话的意思是记录每一次人为统计某时间段后保存下来的值,还是系统自动统计各种累加值之后的历史值存档?
ecore
“对于这种时间窗口有一个弊端,如果滑动时间窗口粒度很长,计算的复杂度就会越高,例如 统计最近10小时的计数器,就需要累加10个小时账;为了应对这种粒度很长的时间窗口,我们提出了中间值的概念,将历史的时间窗口计数器计算成中间值,那么无论滑动窗口多长,只需要计算一次,即: 计数器 = 当前时间窗口值 + 中间值” uesrid:888 的用户在14:00-14:10下单5次,14:10-15:00下单8次,在15:00-16:00下单3次,在16:00-17:10分下单2次, 在17:15的时候如果获取该用户最近两小时的下单数,值是多少?计算逻辑是什么?
白桦林
饿了么除了这种计数器服务反作弊,有实时规则反作弊系统?实时规则和离线规则如何配合?
志刚
localqueue+getset这种方式 如果是集群部署,需要保证对应同一个key的请求落在同一台服务器上吗? 如果不是,不同server之间对同一个key在各自的localqueue里面值都可能不一样 高并发场景下,这个判断会大量失效吧。 同样,在此流程中getandset能保证的是至少将本机的最新值写入了,但是这个值在集群范围内是否是最新的,就不一定了
Quora
为了降低成本,faraday 的 key 去掉了一些不必要的 33 个 byte 的前缀,可以请您举例说明哪些是属于不必要的吗?这个取舍需要和其他部门的人一起商讨吗,主要需要请教哪些人员的意见?
Quora
时间戳用 yyyymmdd 字符串代替 timestamp 存储的优势是便于阅读,其次是节省内存,那这种方案有没有什么缺点?毕竟 timestamp 也有挺多优势的。
Quora
正如文章中说到的,Redis 的单机性能很不错,但是它是纯内存的,所以成本较高。除了 Redis,饿了么还考虑过别的方案吗,它们相比 Redis 主要有什么优劣势?
Geek
麻烦老师能详细说下中间值这个吗?是等同于历史值,多长时间计算或者通过什么规则计算?
Geek
使用localqueue 的方式集群环境下如何考虑?
Geek
incr 有两种方式,一种是long一种是double ,如果是统计金额,long 肯定不实用, double 会出现精度问题,这个是怎么解决的?
你可能还喜欢
支付平台架构设计评审核心要点与最佳实践
李艳鹏
前端大师炼成记:初中级前端成长指南
差不多先生
软件架构发展历程分享
kimmking
微服务开发中的数据构架设计
陈伟荣
从微信支付宝支付接口设计谈 API 接口产品的设计经验和最佳实践
李艳鹏
如何高效开启你的顾问人生模式
加兴
微信扫描登录