我们是怎么支撑双11万亿流量的—— 阿里分布式缓存(Tair)技术分享 姜志锋@阿里巴巴

2020-03-01 563浏览

  • 1.0 2 8 1 我们是怎么支撑双11万亿流量的 —— 阿里分布式缓存(Tair)技术分享 T D C C 姜志峰
  • 2.Agent • 阿里自研大规模分布式缓存 — TAIR 8 1 • 技术挑战 0 2 • 性能与成本 • 单机能力提升 • 客户端吞吐 • 业务方案 • 热点问题 T D C C
  • 3.大规模分布式缓存 — TAIR 高可用 业务覆盖 自动failover 单元化机房内 电商，蚂蚁，优土合一，阿里妈 以及机房间容灾 T D 高吞吐，低延迟，阿里集团 内调用量最大系统之一 2012.06 LDB持久化产品，满足持久化存储需求 2012.10 RDB缓存产品，满足复杂数据结构的存储需求 2013.03 Fastdump产品， 应对全量导入场景，大幅度降低导入时间和访问延时 2014.07 专注于性能提升 2016.11 智能运维，单元弹性，千亿流量 2017.11 性能飞跃，热点散列，资源调度，支持万亿流量 8 1 0 2 C C 高性能 2010.04 诞生，MDB内存存储产品，满足缓存需求 妈，高德，盒马，paytm，lazada 规模化 分布全球各个数据 中心 等
  • 4.TAIR在阿里的应用 • • • 离线数据导入，在线访问 • 读取低延迟，不能有毛刺 缓存，降低对后端数据库的访问压力， 会员，session，库存，购物车，优惠等 数据存储，允许部分数据丢失 内存型 临时存储 M SSD 持久化需求 L T D C C • 通用kv存储，交易快照，安全风控等 • 存储黑白单数据，读qps很高 • 计数器功能，更新非常频繁，数据不可丢失 0 2 8 1 F R SSD 快速导入 极速查询 内存型 丰富数据结构 • 复杂的数据结构的缓存与存储 • exhash，vers-string，bloom， 增强的GIS/GEO • 更灵活的异地多活
  • 5.阿里体系下缓存的技术挑战 增长：缓存TAIR峰值 >> 交易峰值 >> 总GMV GMV(亿) 1800 1600 1400 1200 1000 800 600 400 200 0 峰值QPS 创建峰值 8 1 350000 600,000,000 300000 500,000,000 250000 400,000,000 200000 GMV(亿) 0 2 150000 创建峰值 100000 50000 C C 0 T D • 更强的容灾能力  异地多活与单元化 • 持续服务能力  24*365的稳定性 • 极致的RT需求  为了更好的体验 • 成本上的要求 • 性能提升 • 弹性扩展与资源调度 300,000,000 200,000,000 100,000,000 0 峰值QPS
  • 6.异地多活与单元化 单元A 机房 机房 统一接入层 应用层 应用层 中间件 中间件 DB 8 1 机房 统一接入层 TAIR 单元B 中心机房 统一接入层 统一接入层 应用层 应用层 0 2 C C 机房 中间件 中间件 TAIR TAIR TAIR DB DB DB T D
  • 7.跨单元同步和多活(LDB/RDB) Write App@IDC1 App@IDC2 8 1 Ins@IDC1 T D C C Ins@IDC2 0 2 Ins@IDC3 App@IDC3 Read Sync
  • 8.分析服务端性能瓶颈 C C 0 2 T D 锁是阻止系统性能提升的绊脚石 8 1
  • 9.服务端去锁优化 3% 2% 1% 8% Network 30% 14% 42% Stat 0 2 Memory Management 13% Other 15% C C Locking 20% 优化前 • • • • 8 1 14% Data Search T D 38% 优化后 细粒度锁（fine-grained locks） 无锁数据结构（lock-free data structures） CPU本地数据结构（per-CPU data structures） 读拷贝更新（RCU） Network Data Search Other Stat Memory Management Locking
  • 10.优化后 T D C C 0 2 8 1
  • 11.用户态协议栈(Tair + Alisocket) Tair Application Application Application 450 8 1 400 350 250 200 C C 150 DPDK DPDK DPDK DPDK Userspace Userspace Userspace Userspace 100 T D Kernel (not Kernel (not Kernel (not involved) Kernel (not NIC involved) CPU NIC involved) involved) CPU Queue NIC NIC Queue CPU CPU Queue Queue 0 2 300 queue TCP/IP Stack queue queue queue queue queue queue queue TCP/IP Stack （alisocket） queue queue queue queue msg queue queue queue TCP/IP Stack queue queue queue TCP/IP Stack msg queue queue queue queue msg queue msg queue 50 0 1 2 4 Memcached Memcached with seastar Tair with alisocket 8 16 CPU核数
  • 12.内存碎片合并提升使用率 T D C C 0 2 8 1
  • 13.提升客户端的吞吐 0 2 C C T D • 网络框架替换，适配ajdk协程 • • mina ⇒netty 吞吐量提升40%+ 8 1 • 序列化优化 • • 集成kryo和hessian 吞吐量提升16%+
  • 14.业务解决方案—内存网格 中心 中心 Application Application • 场景 • 读写量超大 • 大量本地计算 • 高性能计算快速IO on-heap C C tair storage T D • 效果 • 50%以上的计算在本地 8 1 Tair Application on-heap on-heap off-heap off-heap tair storage tair storage 0 2 off-heap • 方案 • 数据本地性 • 读穿透 • Write Through • Write Behind/merge • 多单元replication 单元 单元 Tair
  • 15.热点导致集群能力短板 • 突发流量 • 热门商品，店铺 • 时事新闻 • 各类压测 • … • 缓存 • 数据分片仍是单点 • 单机单key能力是有限的 • 被击穿 • 结局 • 全系统崩溃 T D C C • 根源 • 突增的访问热点 0 2 8 1
  • 16.往年 – 热点预测 • 方案 • 预测热点 • Localcache • 热点拆分 • 效果 • 如果能未卜先知还是可以的 • 突发热点，就死扛吧 T D C C 0 2 8 1
  • 17.2016 – localcache + 热点识别 • 方案 App Server • 识别->localcache加 速 • localcache命中 APP 0 2 T D C C DataServer App Server 8 1 APP LocalCache • 效果 • 解决了大部分场景下的 热点问题 • 带来了额外的客户端资 源消耗 • 应用机器能力总归是很 赢弱的 • prefix热点场合下的频 繁置换 • 并不完美的热点算法 App Server APP LocalCache DataServer DataServer ControlNode DataServer ControlNode LocalCache
  • 18.2017 – 热点散列 • 方案 App Server • 识别->散列(读)/合并 （写） • HotZone缓存 APP 服务端能力来支撑 不消耗客户端额外资源 无额外运维成本 热点秒级识别 热点能力水平扩展 T D HotZone APP LocalCache 0 2 C C DataServer App Server 8 1 APP LocalCache • 效果 • • • • • App Server LocalCache DataServer DataServer ControlNode HotZone DataServer ControlNode HotZone
  • 19.热点的识别 • 做到全样统计 • 流量热点的识别 T D C C 0 2 8 1
  • 20.读热点的处理 • 客户端选择HotZone还是本地Off-heap Cache • 如何散列 0 2 C C T D 8 1 • 通过短暂的过期时间来确保数据一致性 • “数据不存在”时的处理 — 防止回源
  • 21.写热点的处理 • 方案的选择 • 本地合并还是远端合并 T D C C 0 2 8 1
  • 22.2017双11时的热点保护 T D C C 0 2 8 1
  • 23.TAIR发展和愿景 • 从阿里体系走向世界 • 标准化和理论创新 • 贡献开源 T D C C • 专注于超大流量的在线访问 • 秒级数亿次的访问 0 2 • 提供极低延迟的服务响应 8 1
  • 24.T D C C 0 2 8 1
  • 25.