GSLB v2 的评分原则 评分的原则还是依照一些指标进行，基于首播时间，越短越好，得出基础分;播放卡顿或失败罚分，得分加入时间因子，随时间衰减更新而最终得分。 GSLB v2 的节点选择 如下图，是节点的选择流程。节点选择主要通过***确定比较阈值，基于 IPC
GSLB v2 的评分原则
评分的原则还是依照一些指标进行，基于首播时间，越短越好，得出基础分;播放卡顿或失败罚分，得分加入时间因子，随时间衰减更新而最终得分。
GSLB v2 的节点选择
如下图，是节点的选择流程。节点选择主要通过***确定比较阈值，基于 IPC 码获取同区域不同节点得分。
如果区域内节点数据满足阈值要求，进行调度。如果节点得分需要更新，则探测新节点。否则向上反馈回溯节点。
GSLB v2 的吞吐量优化
吞吐量方面，数据源使用了 Memcache 和 Redis、纯异步通信选择 Lua。
如下图，是 GSLB v2 的***阶段。
调度系统的***阶段：配置方面包含 1 个 SLB，2 个 gslb server，redis 存储是从主站同步过来的视频状态数据，memcache 存储的是 CDN 播放质量的历史数据。
如下图，是 GSLB v2 的第二阶段。
调度系统的第二阶段：面对播放量成倍增长的情况，对 server 进行了横向扩展。配置方面，增加了多个 SLB 和 gslb server。
如下图，是 GSLB v2 的第三阶段。
调度系统的第三阶段：由于每个请求都需要对 redis 进行 get 操作获取 channel 的状态数据，导致 redis 性能出现瓶颈。于是，系统替换掉了 redis，把 redis 的存储变为 memcache。
配置方面，增加了多个 SLB 和 gslb server。memcache 存储来自 CDN 播放质量的历史数据，以及从主站同步过来的视频状态数据。由于 openresty 不支持 mc 的 sasl 验证协议，所以没有对 mc 进行横向扩展。
未来展望
目前，秒拍的数据节点还都在北京，后续会调整到包括北京、杭州、广州等全国分区域进行异地多活的部署。
面对云厂商不可依赖，会隐藏很多数据信息，出现问题不好查找源头等情况，秒拍还会考虑混合云的改造。
同时，系统会接入一些基于 P2P 的调度及对自建 CDN 节点的融入、灾备建设和监控统计等方面进行完善。
以上内容由编辑王雪燕根据邓铮老师在 WOTA2017 “高可用架构”专场的演讲内容整理。
邓铮
一下科技高级研发总监，公司创始团队成员
主要负责后端服务整体研发工作，参与了一下科技从创办肇始到成为短视频领域独角兽的全过程。现负责公司研发中心管理工作，他带领后端团队支撑公司每日数十亿以上的 PV，重点支持公司新品研发/大数据部门与预研部门，主要关注高并发/机器学习/智能系统领域。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
