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

By @QLeelulu

专业DSP解决⽅方案供应商

什么是RTB与DSP

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

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



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



专业DSP解决⽅方案

什么是RTB与DSP



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



专业DSP解决⽅方案

什么是RTB与DSP



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



专业DSP解决⽅方案

DSP竞价系统的挑战

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



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



专业DSP解决⽅方案

100毫秒内要做些什么



• 竞价请求解析（JSON 或 Google Protobuf）



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



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



• 根据地区过滤活动



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



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



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



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



• 其他更细致的过滤条件

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



专业DSP解决⽅方案

为什么选择Golang



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



专业DSP解决⽅方案

第⼀一次签⼊入

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

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



专业DSP解决⽅方案

为什么选择Golang

• http包的HelloWorld性能测试



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



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



专业DSP解决⽅方案

为什么选择Golang



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



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



专业DSP解决⽅方案

备选

• C++ • NodeJS

• Golang ☑

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



专业DSP解决⽅方案

竞价接⼝口



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



专业DSP解决⽅方案

HTTP竞价接⼝口

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



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



专业DSP解决⽅方案

简单的HTTPBaseHandler



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



专业DSP解决⽅方案

简单监控接⼝口: GO



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



专业DSP解决⽅方案

简单监控接⼝口



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



专业DSP解决⽅方案

预警接⼝口: Interface



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



专业DSP解决⽅方案

预警接⼝口: Redis



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



专业DSP解决⽅方案

Dispatch: 数据、状态同步

etcd

Dispatch

队列

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



Bid Server Bid Server

. . Bid Server Bid Server

专业DSP解决⽅方案

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



专业DSP解决⽅方案

Redis集群

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

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

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



专业DSP解决⽅方案

Redis集群

• Server端：等待Redis官⽅方（当时还没有的） • Proxy中间代理：twemproxy，维护⽅方便，有⼀一定的性能消

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



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



专业DSP解决⽅方案

Redis集群

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

迁移⿇麻烦



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



专业DSP解决⽅方案

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



专业DSP解决⽅方案

Redis集群

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

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



专业DSP解决⽅方案

Redis跨机房同步

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



需要替代⽅方案



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



专业DSP解决⽅方案

Redis跨机房同步

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



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



专业DSP解决⽅方案

Redis运维

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

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



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



专业DSP解决⽅方案

CookieMapping

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

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

表中获取到DSP-CookieId



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



专业DSP解决⽅方案

CookieMapping



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



专业DSP解决⽅方案

CookieMapping存储

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



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



专业DSP解决⽅方案

CookieMapping 第⼀一版

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



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



专业DSP解决⽅方案

CookieMapping: Aerospike

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

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



专业DSP解决⽅方案

CookieMapping: Aerospike

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



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



专业DSP解决⽅方案

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解决⽅方案

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

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

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



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

专业DSP解决⽅方案

部署：进程管理

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



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



专业DSP解决⽅方案

部署：web服务器

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

keepalive

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



Nginx



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

专业DSP解决⽅方案

第⼀一版正式上线

• 三个⼈人（Golang部分） • 三个多⽉月

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



专业DSP解决⽅方案

线上运⾏行情况

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

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



专业DSP解决⽅方案

曝光统计服务

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

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

• 实时统计

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



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



专业DSP解决⽅方案

曝光统计服务

HTTP接⼝口， Go服务



SQL 队列



读取SQL 写⼊入MysQL



⽇日志 队列



Transfer， 计算并⽣生成SQL



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



MysQL 实时库

隔天导⼊入

InfoBright 历史库

专业DSP解决⽅方案

Golang重写原来PHP的Transfer

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

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



专业DSP解决⽅方案

曝光统计服务

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

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



专业DSP解决⽅方案

曝光统计服务： 问题

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



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



专业DSP解决⽅方案

实时统计存储

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

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



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



专业DSP解决⽅方案

曝光统计服务: Druid

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



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



专业DSP解决⽅方案

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



专业DSP解决⽅方案

曝光统计服务: Druid

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



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



专业DSP解决⽅方案

回馈社区

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



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



专业DSP解决⽅方案

Q&A

Thanks! 欢迎加⼊入我们！

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