AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

Golang与高性能DSP竞价系统

发布者 gopher   简介 Gopher
发布于 1430385051245  浏览 7026 关键词 Go 
分享到

第1页

G o l a n g 与 ⾼高 性 能 D S P 竞 价 系 统

By @QLeelulu

专业DSP解决⽅方案供应商



第2页

什么是RTB与DSP

• RTB: Real-time Bidding,实时竞价,允许⼲⼴广告买家根据 活动⺫⽬目标、⺫⽬目标⼈人群以及费⽤用门槛等因素对每⼀一个⼲⼴广告 及每次⼲⼴广告展⽰示的费⽤用进⾏行竞价。

• DSP: Demand Side Platform,需求⽅方平台,允许⼲⼴广告客 户和⼲⼴广告机构更⽅方便地访问,以及更有效地购买⼲⼴广告 库存,因为该平台汇集了各种⼲⼴广告交易平台的库存。



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第3页

什么是RTB与DSP



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第4页

什么是RTB与DSP



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第5页

DSP竞价系统的挑战

• ⾼高并发量请求处理(峰值QPS 20万) • 每天上百亿竞价请求 • 每个竞价请求要在100毫秒内响应(包含⺴⽹网络延迟) • 复杂的出价算法与逻辑



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第6页

100毫秒内要做些什么



• 竞价请求解析(JSON 或 Google Protobuf)



• 根据⼲⼴广告位属性过滤活动



• 根据客户端信息过滤活动(浏览器、操作系统类型等)



• 根据地区过滤活动



• 查询Cookie Mapping得到访客在DSP系统的唯⼀一ID



• 根据⽤用户看过⼲⼴广告的频次过滤活动



• 根据访客的⼈人群属性过滤活动



• 根据活动的出价选择胜出的活动



• 其他更细致的过滤条件

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第7页

为什么选择Golang



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第8页

第⼀一次签⼊入

• 2012-11-29 • 在 Go 1.1 发布之后

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第9页

为什么选择Golang

• http包的HelloWorld性能测试



Via: http://www.cnblogs.com/QLeelulu/archive/2012/08/12/2635261.html



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第10页

为什么选择Golang



• ⾼高性能、天⽣生并发⽀支持 • 性能敏感的模块可以直接使⽤用C编写(当时是这么认为的) • 编译为本地机器码,部署⽅方便 • 快速上⼿手,学习成本低 • 标准库基本够⽤用 • 带GC(当时不了解GC的性能问题) • ⾃自带单元测试、性能测试、性能分析⼯工具 • 开发效率不低



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第11页

备选

• C++ • NodeJS

• Golang ☑

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第12页

竞价接⼝口



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第13页

HTTP竞价接⼝口

• 直接⽤用golang的http包 • 只使⽤用gorilla/mux做简单的请求路由 • 封装简单的HTTPBaseHandler



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第14页

简单的HTTPBaseHandler



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第15页

简单监控接⼝口: GO



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第16页

简单监控接⼝口



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第17页

预警接⼝口: Interface



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第18页

预警接⼝口: Redis



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第19页

Dispatch: 数据、状态同步

etcd

Dispatch

队列

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



Bid Server Bid Server

. . Bid Server Bid Server

专业DSP解决⽅方案



第20页

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第21页

Redis集群

• 重度使⽤用Redis • 存放的数据包括

• CookieMapping • 曝光频次 • DMP⼈人群数据 • 实时费⽤用消耗 • 其他

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第22页

Redis集群

• Server端:等待Redis官⽅方(当时还没有的) • Proxy中间代理:twemproxy,维护⽅方便,有⼀一定的性能消

耗 • Client端:配置、维护⿇麻烦,⼏几乎⽆无性能损耗



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第23页

Redis集群

• 最终在Client端实现 • ⼀一致性hash: github.com/stathat/consistent • 预先开启⾜足够多的Redis实例,预防增加节点带来的数据

迁移⿇麻烦



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第24页

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第25页

Redis集群

• 500个Redis实例 • 占⽤用600G内存 • 峰值QPS在50万

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第26页

Redis跨机房同步

• 直接配置主从同步 • 机房间⺴⽹网络差,⾮非常差(北京<->⾹香港,北京<->北美) • 会触发Redis全量同步(超过repl-backlog-size时)



需要替代⽅方案



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第27页

Redis跨机房同步

• 取消Redis的主从同步 • 写主Redis时,同时写⼀一份到NSQ,异步写⼊入其他机房 • 使⽤用SoftLayer的⾹香港云主机作为中转(why?)



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第28页

Redis运维

• 内存占⽤用过⼤大时,可以切分为多个实例,减少单个实例 的内存占⽤用,减少BgSave和重启时Load数据的时间

• ⼀一致性要求不是⾮非常⾼高的业务,可以把⾃自动的BgSave 关闭,在凌晨或者空闲时候⼿手动调⽤用BgSave



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第29页

CookieMapping

• ⼲⼴广告投放时是⽤用Cookie来定向⽤用户的 • CM保存了DSP与ADX(如百度、淘宝)间CookieId的映

射关系 • 在RTB竞价的时候,DSP可以根据ADX-CookieId从映射

表中获取到DSP-CookieId



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第30页

CookieMapping



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第31页

CookieMapping存储

• 数据量⼤大,单个渠道全量映射达到20亿以上Id • 渠道多达⼏几⼗十个 • 每个竞价请求查⼀一次 • 响应控制在1ms以内



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第32页

CookieMapping 第⼀一版

• 数据存在Redis中 • 占⽤用内存⼤大,达到2T内存 • 内存成本⾼高 • Redis没有集群,维护成本⾼高(嗯,当时是还没的)



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第33页

CookieMapping: Aerospike

• 性能不⽐比Redis差 • SSD优化 • 完备的分布式集群 • ⼆二级索引 • 开源,企业版⽀支持跨机房的集群 • 99%的请求1ms响应 • ⽀支持的数据结构类型偏简单

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第34页

CookieMapping: Aerospike

• 采⽤用SSD来存储(Intel S3500,SATA⼝口) • 数据在SSD中,索引在内存中(1G内存索引16M记录) • 10个节点,replication-factor: 1,写⼀一份到Ardb做备份 • 官⽅方提供Go的Client • 线上半年⽆无故障



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第35页

CookieMapping: Aerospike



====writes_reply==== timespan ops/sec >1ms >8ms >64ms

192.168.3.52:3000 10:25:12-GMT->10:25:22 2378.6 0.06 0.00 192.168.3.53:3000 10:25:04-GMT->10:25:14 2273.1 0.03 0.00

192.168.3.54:3000 10:25:13-GMT->10:25:23 2292.5 0.04 0.00 192.168.3.55:3000 10:25:09-GMT->10:25:19 2481.1 0.03 0.00

192.168.3.56:3000 10:25:12-GMT->10:25:22 2359.8 0.11 0.00



0.00 0.00

0.00 0.00

0.00



====reads====

timespan ops/sec >1ms >8ms >64ms

192.168.3.52:3000 10:25:12-GMT->10:25:22 11974.2 0.18 0.00 192.168.3.53:3000 10:25:04-GMT->10:25:14 11741.3 0.06 0.00

192.168.3.54:3000 10:25:13-GMT->10:25:23 10975.6 0.12 0.00 192.168.3.55:3000 10:25:09-GMT->10:25:19 12223.2 0.09 0.00

192.168.3.60:3000 10:25:13-GMT->10:25:23 11266.2 0.10 0.00



0.00 0.00

0.00 0.00

0.00



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第36页

把服务划分为独⽴立的进程

• 独⽴立部署 • ⽅方便更新与重启

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



./bin ├── adx_mod ├── analysis ├── bid ├── charge ├── convrate_import ├── cookie_map ├── dispatch ├── ip_import ├── kpicharge ├── pdmp └── whisky

专业DSP解决⽅方案



第37页

部署:进程管理

• Go不⽀支持以后台进程的⽅方式启动 • 使⽤用Supervise来管理进程 • 配合parallel-ssh做集群管理



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第38页

部署:web服务器

• Nginx做前端 • 开多个Go进程 • Nginx的upstream做负载均衡 • Nginx的upstream记得开

keepalive

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



Nginx



Go竞价服务 Go竞价服务 Go竞价服务

专业DSP解决⽅方案



第39页

第⼀一版正式上线

• 三个⼈人(Golang部分) • 三个多⽉月

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第40页

线上运⾏行情况

• 30台竞价服务器,CPU为8核16线程 • 每天100多亿竞价请求 • 峰值20万QPS • 98%响应在10ms以内 • 稳定

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第41页

曝光统计服务

• 每天N亿曝光 • 30个维度,40个指标 • 表的数据量和维度的离散程度相关

• 如⼲⼴广告位有5000个,全国500个城市,时间粒度到⼩小时级别,则地区汇总表⼀一个 推⼲⼴广活动⼀一天最多就有 5000*500*24 = 6千万 记录

• 实时统计

• 实时计算、⼊入库 • 实时查询,秒级响应



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第42页

曝光统计服务

HTTP接⼝口, Go服务



SQL 队列



读取SQL 写⼊入MysQL



⽇日志 队列



Transfer, 计算并⽣生成SQL



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



MysQL 实时库

隔天导⼊入

InfoBright 历史库

专业DSP解决⽅方案



第43页

Golang重写原来PHP的Transfer

• 应届毕业⽣生 • ⼀一个⼈人 • 三个星期 • 接近⼀一万⾏行代码 • 性能提升7倍 • 部署、维护更⽅方便

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第44页

曝光统计服务

• 写⼊入做⼀一些合并,减少写⼊入的SQL数量 • MySQL库只保留最近7天的数据 • MySQL使⽤用MyISAM引擎 • MySQL做分库、分表后还可以应付 • InfoBright是列存储 • InfoBright压缩率奇⾼高 • InfoBright使⽤用的是社区版

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第45页

曝光统计服务: 问题

• MySQL 不适合OLAP类应⽤用 • MySQL和InfoBright横向扩展都不⽅方便 • 数据更新⿇麻烦



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第46页

实时统计存储

• Apache Drill • HP Vertica • EMC GreenPlum • Cassandra • InfiniDB • MonetDB • VoltDB • InfluxDB

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



• MemSQL • opentsdb • kairosDB • Kylin • Druid • …



专业DSP解决⽅方案



第47页

曝光统计服务: Druid

• 专为统计分析⽽而⽣生 • 列存储 • shared-nothing的分布式架构,可扩展性、⾼高可⽤用 • 秒级以内对⼗十亿⾏行级别的表进⾏行统计查询 • 对内存要求⾼高,相当于内存数据库 • JAVA系,开源



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第48页

© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第49页

曝光统计服务: Druid

• 没有Go的Client,所以我们写了⼀一个 • github.com/shunfei/godruid



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第50页

回馈社区

• 第三⽅方包会有⼀一些⼩小坑



© ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved



专业DSP解决⽅方案



第51页

Q&A

Thanks! 欢迎加⼊入我们!

⺴⽹网络运营全流程解决⽅方案供应商



支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。