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

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

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

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


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

已有87人预订
预订达标
文章出炉
交流日期
     
08月22日
09月04日
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 会出现精度问题,这个是怎么解决的?
你可能还喜欢
Service Mesh 在华为公有云的实践
田晓亮
从零开始,搭建 AI 音箱 Alexa 语音服务
Mike
Web 安全恩仇录:再谈逻辑漏洞
肖志华
编程和数学基础不佳如何入门人工智能?
赵宁|Neal
如何用 Vue 实现前端权限控制(路由权限 + 视图权限 + 请求权限)
雅X共赏
智能增长:如何用大数据和人工智能实现业务体量的增长
蒋凡
微信扫描登录