CDP服务可用性保障
如果无法正常显示,请先停止浏览器的去广告插件。
1. CDP 服务可用性保障
贺阳 | 机票目的地事业群 /技术中心/技术运营中心
2. 离线
3. 目 录
CONTENTS
A CDP简介
B 面临的问题
C 可用性问题分而治之
D 未来计划
4. 01
CDP 简介
5. 数据平台整体架构
酒店报价 酒店营销 会员权益
代理商数据平台 机票辅营 信息流推荐
API CDP
业务应用
数据应用
BI
数据标准
数据开发
数据仓库
数据治理
离线数仓
数据质量
实时数仓
数据同步
调度系统
基础平台
数据资产 Hive Trino Flink 开发平台
数据安全 Hadoop Hbase Kafka 埋点系统
6. CDP简介
标签系统 用户分群 营销推送
融合多方数据,通过对人货场的
画像,对人货场进行应用场景打
标,摆脱数据孤岛,助推业务分
析与运营 精准快捷地圈出人群包,满足多
样化的分析与运营需求 联动营销平台,将任务推送给目
标群体,实现精细化运营
7. CDP简介
标签系统
用户分群
离线标签 实时标签 Id-
mapping
标签地图 组合标签 人群圈选
对外服务
人群洞察
营销推送
push推送 小程序推送
短信推送 公众号推送
效果分析
8. 什么是标签
黄牛用户 老人 优享会酒店 浏览未下单 航班飞行时间
VIP用户 学生 酒店新客 下单目的地 航班恶意订单率
黑名单用户 儿童 城市等级
9. 标签用在哪
活动促销
主流程hsdbo
场景
广告推送
恶意订单拦截
10. 标签现状
70+
重要服务接入 20W
高QPS 5ms
高响应P99 99.9998%
业务视角成功率
70+重要的业务服务
接入
直接影响线上产品的
决策 最高达20w qps 的
请求量
无负载压力
无异常增长 快速返回业务结果
为业务节省更多的
决策时间 月平均业务视角成
功率高达99.9998%
为业务决策提供保
障
11. 02
面临的问题
12. 面临的问题
机票业务反馈,标签服务影响90%的机票业务
酒店业务反馈,1%的接口异常影响酒店0.5%的订单
• 接入重要系统70+,包括
• 机票:首页、搜索、报价计算、booking、核
心交易、航线推荐
• 酒店:报价计算、优享会、酒店打标、促销平
台
• 呼叫中心
• 响应p99达80+ms
• 业务超时异常量高(机票、酒店)
13. 03
可用性问题分而治之
14. 六西格玛
1
定义
SLA协议
2
测量
监控
3
4
5
分析 改进 控制
日志+监
控 改进策略 压测
自动发现
15. 定义+测量
Dubbo接口
Http接口
权限校验
其它渠道标签
查询
查缓存
Hbase 查询
hbase
存缓存
赋默认值
返回结果
Dubbo接口
Dubbo接口
16. 定义+测量
监控设计
大盘监控
阶段处理过程
细化appcode
响应时间 响应时间
整体监控
细化处理过程
QPS QPS 响应时间 响应时间
异常情况 异常情况 QPS QPS
异常情况 异常情况
17. 定义+测量
18. 分析+改进
日志分析
监控分析
19. 问题分析
流量分析
缓存分析
存储分析
长尾分析
20. 问题分析
流量分析
缓存分析
存储分析
长尾分析
21. 流量分析
Dubbo接口
Http接口
权限校验
其它渠道标签
查询
查缓存
Hbase 查询
hbase
存缓存
赋默认值
返回结果
Dubbo接口
Dubbo接口
22. 流量分析
QPS 响应时间
6000 1ms
5000 2ms
3000 40ms
查询hbase的QPS越少,响应越快,失败请求越少
23. 问题分析
流量分析
缓存分析
存储分析
长尾分析
24. 缓存分析
如何分析缓存?
请求参数
缓存数据
25. 缓存分析
6000
全天
每小时
每分钟
85%+
80%+
60%
40%-50%命中率?
5000
3000
26. 缓存分析
key value
key HashMap<tagCode,value>
Key没有命中的情况下,30min缓存不会存储
27. 缓存分析
key value
request response
key HashMap<tagCode,value>
key HashMap<tagCode,value>
28. 缓存分析
效果:
接口P99降低10ms
dubbo接口的P99降到了30ms下
结果缓存命中了60%的请求
29. 缓存分析
6000 入口
6000 结果缓存
2000 30min缓存
1700 hbase
130
0 击穿
查询hbase击穿率76%!!
30. 缓存分析
接口
结果缓存
特殊值缓存
30min缓存
否
是
查询hbase
是否查询到
value
否
31. 缓存分析
效果:
请求hbase的qps与前一日比较由1700降低了600qps左右,接口P99较上策略前降低7ms
32. 问题分析
流量分析
缓存分析
存储分析
长尾分析
33. 存储分析
现象:
Hbase响应慢
Hbase内存占用持续增长,超过1T
解决:
定时任务合并清理hbase数据
userA:{"vip会员":true""}
userB:{"vip会员":true""} version=1
version=1
userA:{"vip会员":true""} version=2,keytype=Delete
34. 存储分析
结论:
第一次清理后接口P99与前一日同时刻对比降低了17ms,恢复了30ms内。Hbase表清理200G+
35. 存储分析
• Hbase日常运维会导致接口不稳定,业务无法接受
• 响应时间无法满足主流程需求 P99 30ms内
• 数据量大:近20亿标签key,hbase占用近1T存储
分析原因:
hbase大部分数据存储在内存中
36. 存储分析
方案
双hbase
Redis
优点
对当前架构改动最小,最方便实现 需自行维护主从表切换
1.
2. 占用内存资源
响应最快
Redis内有主从保证稳定性
Mysql分库分表 DBA对mysql支持较好
rocksDB(携程)
Tair(阿里)
TiDB
缺点
1.
2.
支持Kv存储,符合标签系统使用
场景
内存+SSD相结合,节省资源
1.
2.
3. 扩缩容复杂,有丢数据风险
不支持kv存储
对系统改造过大,相当于整体重构
建
1.
2. 公司目前没有相关组件
从调研到正式投入生产周期较长
37. 存储分析
预估所需空间
• 没有足够大的redis来存储真实标签数据
预估占比
1:10
Hive容量 预估redis
200G
2T
• 标签风格迥异,无法真实测算redis
解决:
• Key缩减长度
• 在redis存入200G数据的情况下降低存储20%
预估占比
1:8.6
Hive容量 预估redis
200G
1.6T
38. 存储分析
接口请求
调度发起
查询结果缓存
HIVE
标签构建
是否新方案
结果缓存
线程池并发写
入线上库
全量存储
redis
HBASE
结束
查询30min缓存
是
查询redis
生成hive表
否
否
Key是否查
询hbase
是
查询hbase
查询hbase
部分流量查询
hbase
校验一致性
返回结果
校验一致性
39. 存储分析
hive
T-1
hbase
实时
redis
40. 存储分析
41. 存储分析
42. 问题分析
流量分析
缓存分析
存储分析
长尾分析
43. 长尾分析
业务侧监控
0.77%
44. 长尾分析
阿里开源工具:Arthas
45. 长尾排查
长尾耗时较长大部分在查询redis
46. 长尾排查
针对这种问题系统内部是否可以有预防机制呢?
请求redis抖动消除
为防止单次请求失败
只要有1个缓存结果返回即返回
47. 长尾排查
48. 其它保护措施
49. 其它保护措施
服务限流+日常压测:
50. 其它保护措施
推进调用方增加重试
case:
A服务设置接口超时时间200ms,请求服务的响应时间P99为10ms内
51. 04
未来计划
52. 现状
QPS
响应时间P99
最高20w 平均5ms
调用方 业务视角成功率
最多79个 99.9998%
53. 未来计划
稳定性是一场持久战!
随着业务发展不断的进行技术的
改进和提升才能持续的保证高稳
定高可用
54. Q&A
55. 分享完毕,谢谢观看!