b站上无法缓存怎么缓存（为什么B站不能缓存）

本期作者

卫智雄-基础架构部高级运维工程师

01 引言

域名系统(DNS)就像是互联网的地址簿，通过将一个或多个复杂难记的IP地址映射到容易识别和记忆的域名上，便于人们通过简单的域名比如 bilibili.com 访问互联网资源。在此基础上，DNS 还提供了负载均衡等重要服务。是极为关键的互联网基础设施。

以 DNS 为基础的内网 DNS 服务则提供了一些额外的好处：

1. 私有域名

• 方便内网服务互联互通
• 外界无法感知和探测到，满足了安全性和隐私方面的需求

2. DNS 劫持

• 拦截特定公网域名到内网 ip，降低公网带宽和访问延迟。如某核心服务 A 早期只有公网域名，随着业务发展，内部非常多其他服务调用 A 服务，此时内部调用产生的公网带宽成本已非常高。而推动其他服务更换内网域名成本不低，DNS 劫持则能轻松帮我们解决问题。
• 拦截恶意公网域名，降低安全隐患

3. 特定业务逻辑支持

• 内部调用 API，方便管理与运维
• 主机名管理和私有ip反向解析支持
• 支持特定域转发

4. 极低的解析延迟以及极高的吞吐量

因此本文将分享 B 站内网 DNS 服务建设相关实践。

02 架构演进

考虑到基础设施的稳定性，我们选择了知名度最高、普及范围最广的 DNS 实现 BIND9 作为 DNS Server。

在介绍架构之前，我们简单了解一下内网 DNS Server 中最常用的两种角色：

• 权威 Name Server

权威 Name Server 是实际持有并负责特定域资源记录的服务器，通常是解析器查找 IP 地址过程中的最后一步，拥有这些域的最终解释权。

权威 Name Server 在软件层的实现又可以分为主权威和从权威。对 DNS 查询来说主从权威完成是对等的，但是它在软件架构上提供了必要的故障灾备和横向扩容能力。

• 解析器（Caching Name Servers）

解析器通常是 DNS 查询中的第一站，处理用户的递归查询，并提供完整的答案。当收到请求时，解析器向DNS层次结构发出一个或多个迭代查询。在获得一个完整的答案（或一个错误）后，解析器将答案传递给用户，并将记录放入其缓存。用户对同一查询的后续请求将从解析器的缓存中得到回答，直到缓存记录的TTL过期，那时它将从缓存中被刷新；请求相同信息的下一个用户查询将导致对DNS层次结构的一系列新的查询。

解析器在不同的使用场景下常被称为各种令人困惑的名字，如缓存名称服务器、递归名称服务器、转发解析器、区域解析器和全面服务解析器等。

典型域名解析过程图：

NS 实践” onerror=”javascript:errorimg.call(this);”>

1. 第一代 DNS 架构

NS 实践” onerror=”javascript:errorimg.call(this);”>

B 站内网 DNS 服务早期第一代架构相对比较简单，核心关注高可用和稳定性，采用了主从模式，保障每个核心 IDC 有独立的从权威集群，通过 VIP 提供负载均衡，并通过 VIP 健康检查机制自动踢掉故障节点。同时各 IDC 机房内网互通，互为备份。

随着业务的发展，在高 QPS 场景中，主从权威 Zone 配置同步时存在解析时长突增，响应时延不稳定的问题。其次从权威的可扩展性也相对较弱。因此我们衍生出第二代 DNS 架构。

2. 第二代 DNS 架构

第二代 DNS 架构主要引入了多级缓存。

首先是引入了 Caching Name Servers，可扩展性得到了非常大的提升。同时也避免了权威节点配置/Zone变更带来的抖动。

其次是针对大数据、AI 等 QPS 极高的业务，引入 NSCD 作为 Client 缓存服务。既降低了响应延迟也提高了整体服务吞吐。

在此基础上，第二代架构还对 BIND9 Server 进行了升级和优化。BIND9 虽然支持多线程，但是在我们早期使用的 9.11 版本中，最高只能利用 400% 的 CPU，单实例 QPS 峰值在 10 万左右，为了提高服务器利用率，我们进行了单机多实例部署，但这也给运维带来了复杂度。在新的版本中，因为支持 reuseport、日志写缓存等新特性，对性能有非常大提升，单实例可以充分利用多核 CPU，在生产环境压测中单机 QPS 超过 150 万，因此我们也在线上进行了升级。

03 DNS 服务监控建设

DNS 服务监控告警主要分为三个层面：

1. 主机层

2. 业务层

3. Client 端

1. 主机层

主机层通常都会有 CPU、内存、网络、磁盘等资源的使用率、饱和度、错误监控告警。这里主要强调两点容易忽略或者对 DNS 服务比较重要的监控告警。

• 单核CPU/单网卡的使用率告警
• 现代 IT 服务架构中，从交换机到服务器网卡到服务器CPU，各个路径几乎都是多 Pipeline 负载均衡，因为错误配置或使用不当，可能会出现单核CPU/单网卡负载不均衡，引发服务异常的情况。
• 网络层面
• 1. 网卡收发包异常告警
• 2. TCP、UDP errors 告警

2. 业务层

• BIND 内部指标采集
• BIND 通过 statistics-channels 暴露了丰富的内部监控指标。早期我们通过 bind_exporter 采集，但是遇到两个比较明显的问题：一是 bind_exporter 默认会采集 /xml/v3/tasks 数据，这个路径下的数据即无用，又会严重影响解析时延；二是部分比较重要的指标 bind_exporter 没有采集。因此我们重新开发了采集程序。
• Zone 记录值变化率/变化量告警
• 监测每个 Zone 的记录值变化量，防止内部 API 等异常变更导致大量记录值被删除。
• BIND 错误日志监控告警
• 错误日志能更详细的反应 BIND 内部的异常情况，帮助我们及时排障。

3. Client 端探测告警

服务内部的监控并不总能真实反映用户到服务端的访问质量，因此我们在各个机房部署多个探针，模拟真实用户请求，多Zone多域名高频率监测每个 Server 的可用性、内容正确性和响应时延。Client 探针多次帮助我们及时发现网络设备小概率BUG、网络拥塞等业务方还感知不到的异常。

同时增加 Client 到 Server 的网络 Ping 时延和丢包率监控，在异常时做辅助判断。

这里补充一点，公网公共 DNS 也并不是稳定的，需要对其进行监测和告警。目前我们的实践经验是阿里云公共 DNS 稳定性相对更好一些。

04 踩坑经验

一个复杂系统总会有很多细节是我们在使用初期没能了解或掌握的，因此这里分享一些我们踩过的坑帮助你走好自己的路。同时推荐阅读《常见DNS操作和配置错误》[3]。

1. 保障 UDP 和 TCP 端口用户皆可访问

通常 DNS 默认使用 UDP 传输，同时在 rfc 中约定 DNS 使用 UDP 传输时，包体需小于等于 512 字节(不包括 IP 或 UDP 包头)。512 字节的限制在大部分场景都能满足需求，但当记录值过长超过限制时，Server 端需置 TC 位为 1，告知 Client 响应被截断。Client 在收到 TC 位为 1 的响应时，需用 TCP 重新发起请求。这就要求 TCP 端口也必须可达。

根据以上信息，也额外提醒大家，在选域名时应尽量短小，记录值尽量简单，以便提高解析速度。

2. Zone 配置变更后必须增大序列号

主从权威的同步过程如下：

① 主节点 Zone 配置变更，向从节点发送 NOTIFY 通知

② 从节点返回 NOTIFY Respons，并向主节点发起 SOA 查询

③ 主节点返回 SOA Respons

④ 从节点对比 SOA Respons 中的序列号是否比自身序列号大，仅当 SOA Respons 序列号大于自身序列号时才发起 Zone transfer request，并利用 TCP 53 端口进行数据传输

因此 Zone 配置变更后必须增大序列号，否则会导致主从节点数据不一致。

3. 慎用 rndc flush 刷新全量缓存

线上难免会遇到刷新缓存的需求，如果直接用 rndc flush 刷新全量缓存，在有客户端缓存如 NSCD 的情况下，在每一次客户端缓存过期的时间都可能会产生极高的 QPS 。

因此，尽量使用 flushname 或 flushtree 来刷新指定域名或 Zone。

4. 慎用泛域名解析

泛域名解析是指利用通配符 * 将所有的子域名都指向相同的解析记录，实现灵活配置。然而当某个子域名需要独立配置时，容易忽略泛域名的配置，引发故障。

举个例子(以真实故障为蓝本)，方便大家理解：

① 业务上线初期为了方便配置使用泛域名解析: *.example.com CNAME xxxcdn.com

② 发展一段时间后 a.example.com 有了新需求，需要加个 TXT 做验证

③ 运维同学添加解析 a.example.com TXT xxx

④ 此时因为 a.example.com 只有 TXT 记录，没有 A/AAAA 或 CNAME，直接导致 a 站点无法访问

05 结语

基础设施服务具有杠杆作用，良好的基础设施服务可以帮助业务提高效率，降低开发运维成本。作为基础设施的一部分内网 DNS 亦是如此。我们始终以业务需求为基础，不断演进与迭代，致力于提供稳定、可靠、易用、好用的服务。

参考文献：

[1] BIND 9 管理员参考手册（https://bind9.readthedocs.io/en/latest/index.html）

[2] 域名——实施和规范（https://www.ietf.org/rfc/rfc1035.txt）

[3] 常见DNS操作和配置错误（https://www.ietf.org/rfc/rfc1912.txt）

[4] ISC 知识库中关于 BIND 及 DNS 的一系列文章（https://kb.isc.org/docs/monitoring-recommendations-for-bind-9）

作者:卫智雄

来源:微信公众号:哔哩哔哩技术

出处:https://mp.weixin.qq.com/s/iAPjhBlbusFLlFVUN4OLaA