CDN 架构

项目创建流程

文件上传流程

CDN 刷新流程

刷新问题

蓝汛服务质量问题

1. 刷新接口返回内容混乱，难以判断结果；
2. 不能保证所有节点刷新成功；
3. 配额限制比较大；
4. 节点服务质量问题严重；

旧版刷新服务效率问题

1. 数据表设计关系复杂，业务流程复杂；
2. 没有压缩刷新请求，浪费配额；
3. 对错误处理的不友好；

新版刷新服务改进方案

1. 简化数据表设计，使用状态机模型来代替多分支的流程实现；
2. 改成定时任务，每2分钟将队列中缓存的刷新请求做去重合并；
3. 减少刷新任务处理无效等待时间，对于失败任务进行有计划的入队重试；

新版刷新服务每天的刷新量在60多万个，导致蓝汛刷新机器负载过高，侧面反映了蓝汛服务质量问题。

Inotify 问题

源站使用 Inotify Python 封装的 pyinotify 来监控数据目录的文件变更，现在遇到以下几个问题：

1. 目录文件太多，文件更新存在短时间的热点；
2. 前端使用很多小 js 文件来处理动态数据，这类数据频繁变动更新；
3. CDN 用户使用没有约束，导致源站存在很多不必要文件和无主项目：
   
   • http://example.game.com/db.conf
   • http://download.game.com/js/Config_backup
4. Inotify 不支持递归监控，需要动态给新文件加上监控点；
5. Inotify 读取队列的延时较大，在文件更新的热点时间，队列会被塞满；
6. 服务初始化需要90分钟；

源站风险

• 主备同步延时2小时，且使用sata盘；
• 多个 CDN 服务商混用同个源站，存在大量特殊流程和配置需要去适配；
• 用户没有遵循每次推送都分别向主备源站推送一份的要求；

改进方案

• 迁移源站；
• pyinotify 性能优化；
• fanotify 辅助监控文件更新；
• 使用 vm 作为源站将文件存放在 ceph 上；
• 规范用户使用cdn的方式；