$ 《快手短视频打造高稳定千亿级别对象存储平台》笔记
$ 业务需求
$ 业务规模
1.3亿日活，70亿库存，日播放150亿，ugc1500万：千亿对象，百PB存储
$ 业务需求与解决思路
海量数据 => 小数据合并，长短视频 => 流式读写，高可扩展 => 扩展集群而非扩展机器（避免数据迁移io对在线业务的影响），高可用 => 快速发现+恢复+Failover，高性能 => 数据缓存，最终一致 => 数据读写模式控制
$ 业务流程
- 上传视频API层
- 生成对象ID
- 写入对象存储BlobStore，同时发送通知事件
- 转码、去重等服务从BlobStore读取
$ 架构与实现
BlobStore层次架构图
| 层次 | 功能 | 备注 |
|---|---|---|
| 数据层 | 对象数据存储 | |
| 索引层 | 对象元信息与索引 | |
| 缓存层 | 热数据cache | 写入饥饿 |
| 逻辑层 | 业务逻辑：数据存储，索引，扩展，failover | gateway |
| 接入层 | http service | gateway |
BlobStore写入流程
- client通过zookeeper服务发现gateway服务
- gateway写数据
- gateway更新索引
- gateway写入数据缓存
BlobStore读取流程
- 服务发现
- 查询缓存
- 查询索引
- 获取对象数据
BlobStore双机房写流程
- gateway数据双机房同步双写
- HBase索引异步复制，回落读实现最终一致性
- 同步更新cache
BlobStore双机房读流程
- 读cache
- 读hbase索引，miss则去另一个机房读
- 读hdfs
$ 问题与解决
高可扩展
- gateway无状态
- HBase扩容机器(容量可控，业务低峰，限速扩容)
- HDFS扩容集群，避免扩容机器时数据迁移对在线业务的影响
高可用
- 故障类型
- 进程异常退出(立即感知)
- 机器宕机（会出现超时）
- 快速发现
- 宕机发现服务
- HDFS/HBase
- 快速恢复
- HDFS/HBase
- 服务熔断
- Gateway单点故障
- HDFS/HBase单点故障
宕机发现服务(Hawk)
- 解决机器宕机问题
- 主从结构
- master:
- 接收node down sniffer关于监听节点的注册请求，将节点通过心跳传递给worker
- 跟worker保持相同的逻辑时钟
- 多数派判定宕机（n-1）
- worker:
- 跟master保持心跳，获取监听节点
- 跟master保持心跳,获取逻辑时钟
- 周期性检查节点宕机情况（ping check）
HDFS服务快速恢复思路
- 服务进程异常退出：fast-fail(1s内)
- 机器宕机：大量时间消耗在超时等待上，解决思路：
- 冗余读（HedgeRead）
- 并行写(ParallelWrite)
HBase服务快速恢复思路
- 服务进程异常退出：fast-fail(快速发现1s内，恢复10s内)
- 大量时间消耗在超时等待上，解决思路：
- hawk接入，快速发现
- 基于ping check规避宕机节点策略
- 调优参数提高并行度
Failover与服务熔断
- 请求异常，快速切换到其他镜像服务
- 权重降权的熔断策略
$ 数据一致性
- 双集群同步双写，单写失败跳过
- 异步实时数据补齐
- 周期性数据一致性校验
$ 参考
← HBase使用