大规模CDN中 解决通知实时性的问题

CDN中 如何解决实时性的问题

用户管理 – 添加域名
API通知 内部智能DNS系统 生成一个(1-9 a-z)N位字符串 对比数据库已存储的字符串是否有重复
如果没有重复 返回前台给用户 作为用户域名的CNAME记录 如果有重复 重新生成一个
域名添加成功后 添加到 任务队列系统

需要加速的域名添加成功后
CDN系统内部的动作有
读取队列
1. 以域名 生成一个反向代理加速的配置文件 (nginx/squid)
2. 实时内网同步 至 主 CDN Master 服务器集群
3. 由CDN Master服务器 将配置文件 下发至所有CDN边缘服务器 即提供反代的CDN节点
(这个有个问题, 如果某个服务器大流量DDOS 导致通信失败) 考虑使用异步处理机制 记录执行情况 成功=1 失败=0 如果失败 间隔1分钟 5分钟 再次推送
4. 每次同步完成 且节点回复ok 调用API执行Reload 使配置生效
5. 删除队列中的任务信息

CDN静态分发的实时性处理
====================================================
1. 用户上传文件 test.rar
2. 上传服务器接收文件存储本地
3. 将文件 同步至CDN的Master存储集群
4. 由Master下发至边缘CDN节点 (这个过程中 时间应该在5分钟内完成 1Gbps内网端口)
5. 为实时 边缘节点 使用NGINX NGINX的配置文件中
判断本地文件是否存在
如果存在 直接返回给用户
如果不存在 则反代给Master请求到文件 在转发给终端用户下载或者访问

CDN系统中的集中日志管控系统
====================================================
小型CDN中 一般只是单台日志服务器 过期清理
中大型CDN 这样肯定不行 什么都要考虑意外和容灾的问题
考虑的一些细节
1. 高稳定性的日志集群系统 facebook的 scribe
2. 考虑后续的日志结构扩容问题 日志格式 应该尽量的详细 使用标准记录 不需要精简日志结构
3. 不使用管道通信 日志至少要保证1正本和1个副本 避免出现服务器故障的问题
4. 优化查询性能 要设计良好的数据查询结构层和数据层
例如
以域名查询的情况
test.com 1号到18号的 流量 请求数量 爬虫请求 错误数量

这个结构应该更清晰
不推荐只是简单的 按天 按小时存入数据 然后使用SQL语句来相加 相减 取结果
如果分为
day_bw
day_req
day_bot
更新流量的时候 直接取得数值 存入数据库 然后直接读取
会不会更好些?

不成熟的理论
在续!!!!

最近通过搜索访问本文章的关键词:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注