C++如何实现基于协程的轻量级异步DNS解析请求、结果缓存及其过期自动清理-C++-PHP中文网

推荐用Boost.Asio的resolver.async_resolve，它原生支持awaitable且已处理线程安全与事件分发；缓存采用分片哈希+时间轮，64桶unordered_map配steady_clock绝对时间戳；DNS请求须绑定长期executor并用shared_ptr捕获上下文，避免栈变量悬挂。

c++如何实现基于协程的轻量级异步dns解析请求、结果缓存及其过期自动清理

协程怎么发起非阻塞DNS查询（Linux下用getaddrinfo_a）

标准 getaddrinfo 是阻塞的，不能直接扔进协程里；Linux 提供了异步版本 getaddrinfo_a，它把请求提交到内核，再通过信号或轮询获取完成状态——但信号处理在协程里容易出问题，更稳妥的做法是用 io_uring 封装或改用 libuv/Boost.Asio 的 DNS 接口。实际落地时，推荐用 Boost.Asio 的 resolver.async_resolve，它原生支持 awaitable，且底层已处理好线程安全与事件分发。

注意：别自己封装 getaddrinfo_a + sigwait，协程栈和信号上下文不兼容，容易导致 coroutine frame corruption 或静默挂起。

确保编译时链接 -lboost_system -lboost_coroutine -lboost_context
使用 boost::asio::ip::tcp::resolver 而非 udp::resolver，后者不保证解析结果完整性
超时必须显式设置，resolver.async_resolve 默认无超时，协程会永久挂起

缓存结构怎么设计才能支持并发读写和 TTL 自动失效

不能用 std::map + std::mutex 粗暴锁整个表——高并发下成为瓶颈；也不建议用 std::shared_mutex，因为过期清理需要遍历，读多写少但“清理”是写操作，仍会阻塞所有读。

更实用的方案是分片 + 时间轮（timing wheel）：把缓存按哈希分 64 个桶，每个桶配一个 std::unordered_map<:string cache_entry></:string>；TTL 过期不靠定时器逐项检查，而是用单个后台协程每 100ms 推进一次时间轮指针，只清理当前槽位里已过期的条目。

cache_entry 必须包含 expire_at（绝对时间戳，用 std::chrono::steady_clock::time_point）
插入时根据 expire_at 计算所属时间轮槽位（如：(expire_at - now) / 100ms），写入对应桶 + 槽位链表
查询时只查主哈希桶，不查时间轮——过期判断在读取后立即做，命中即返回，否则丢弃并触发重解析

协程等待 DNS 结果时如何避免被过早销毁或重复触发

常见错误是把 resolver.async_resolve 的 awaitable 直接用于局部协程对象，结果 DNS 还没返回，函数栈已退出，await_suspend 拿到的 promise 已 destruct，导致 segmentation fault 或未定义行为。

Adblock Dns

在你的机器上运行DNS服务器，使用Pi-hole黑名单阻止189,000+个广告、追踪器和恶意软件域名，实现全网拦截。

下载

正确做法：所有 DNS 请求必须绑定到一个长期存活的 executor（比如 boost::asio::thread_pool 或 io_context 的 post 队列），且结果回调里不捕获栈变量，只捕获 shared_ptr 包裹的上下文。

不要写 co_await resolver.async_resolve(...) 在普通函数栈里，应封装为返回 boost::asio::awaitable<:vector>></:vector> 的自由函数
缓存未命中时发起解析，需把 shared_ptr<cache_context></cache_context> 传入 lambda，而不是 this 或局部引用
若用 std::jthread 启动清理协程，确保它比所有 DNS 请求生命周期更长，否则清理逻辑可能访问 dangling pointer

为什么不用 std::experimental::coroutine + 自研调度器

从 C++20 开始，std::coroutine_handle 和 promise type 可以手写调度，但 DNS 解析涉及系统调用、文件描述符、信号、线程模型切换，这些和协程挂起/恢复语义天然冲突。例如：getaddrinfo_a 的完成通知依赖 signalfd 或 epoll，而自研调度器很难安全集成这两者而不破坏协程栈一致性。

真实项目中，Boost.Asio 已验证过百万级并发 DNS 场景，它的 awaitable 底层复用 io_context 的 epoll/kqueue 循环，且对 resolver 做了专用优化（如连接池复用、失败退避）。自己造轮子不仅增加 ~3k 行胶水代码，还会在 glibc 升级后因 getaddrinfo_a ABI 变更而崩溃。