商业产品的广告交互架构;百度，商业产品开发
十几年软件开发经验
流程改进 系统架构 分布式系统
微博: 金自翔_Lotus
微信:;; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;传统展示广告;;可扩展
承担比广告检索系统更大的流量
高可用
不能交互的交互广告 = worse; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;;
交互广告靠谱吗?
用游戏试试效果
尽快上线
2人 * 1周
后端 php/半台机器
每秒轮询后台
限制流量
正向反馈，快速改进
;设计要支持的整体吞吐量
所有请求能容忍的最低延迟;消息推送服务;延迟
通过实验，整体延迟不能超过30 ms
后端服务延迟20 ms (99.99%的请求)
吞吐量
总流量 × 接入比例 × 互动时长 × 交互频率 × 高峰系数
超过 500万 消息/秒
; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;如果要求99.99%的可用性
年不可用时间53分钟,可感知停服次数=1次
扩容怎么办?
运维和部署
运维自动化 监控/报警/切换
同构部署 运行时获取个性化配置
Keep Cool
Anything that can go wrong will go wrong
保留冷备份，以备万一
;分层
有针对性的调优和扩容
服务无状态
水平扩展
如何处理全局状态
集中存储，热点拆分 (要避免单点影响可用性)
状态参数化，消除全局状态;路由层和应用层
同构部署
BNS 探活/切流量
推送内容不持久化
路由信息参数化;会话内通信;;安全性
加密传输
预防 DDOS
不考虑重建会话
server 当机导致会话失效
会话延续时间较短，可以接受
GC、锁与吞吐量
;并非所有状态都能参数化; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;同步 or 异步
安全 vs 性能和体验
存储系统的缺省配置能否满足需要（redis/MQ/kafka）?
本机 or 网络
速度 vs 安全和复杂
重建状态
;目标
用户通过弹幕实现跨广告互动
无法直接用消息推送服务实现
保存弹幕 (持久化)
时间长(重建会话状态)
参与者极多 (原数据结构不合适)
;实现额外的弹幕应用
弹幕应用负责持久化
本机异步批量
定时网络备份
用消息推送服务实现通信
消息推送服务升级
数据结构 CopyOnWriteSet - ConcurrentHashSet
单机吞吐量 10万 QPS
支持重建会话状态
;; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;只读状态
复制到内存/机房中
读写比100 缓存
写者更新 vs 读者更新
读写比0.01
可容忍时考虑写归并
;目标
支持单选项每秒几千次投票
是否使用NoSQL?
投票包含两个状态
选项描述信息变化很少
选项投票数是个自增变量;实现投票; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;一致性;目标
每秒大几千次抽奖
中奖概率实时变化
不允许超发奖品
锁定和身份验证;抽奖解决方案;锁定和解锁（锁定奖品的方案）;; 广告交互平台简介
设计之前
可用与扩展
状态持久化与重建
读写比
一致性
保持简单
;保持简单;千淘万漉虽辛苦