2026-06-03 Web开发记录【访问激增 - 性能瓶颈】【uint 代替 哈希 】 - 小管 的网络日记

去年九月份后开始，本站的访问激增，通过分析，大部分是爬虫，根据爬虫的特征做人工筛选，

与路径动态做分析，我做了一个记录IP的列表，根识别IP的来源于对比，区分爬虫并做记录。

一开始，这个IP列表只有几个，到几十个，到上百个，这个过程经历了三四个月。

但是随着用户的访问与爬虫的数量越来越多，爬虫IP与云服务器IP的记录越多越多，从几百到几万。

期间IP列表的数据结构也在半年内做了三次大的数据调整与结构调整。

最终这个数据列表目前的规模接近 四百万条 IP记录。

所以第一个问题，每次用户访问，百万级数据对比。每次访问的对比，从数据库对比查询已经效率不足。

将所有数据读取到内存，再通过内存遍历查询，这个阶段在六万条IP数据的时候，系统出现了延迟响应。开始逐步影响用户体验。

解决方式：将数据转换为哈希列表，通过对比哈希表，进行快速的查询。顺利解决数据量在六万条左右出现的性能问题。

第二个阶段，随着爬虫IP的数据记录越来越多，数量达到两百多万条。虽然哈希表的方式可以实现效率问题，但是对于CPU不友好。

CPU占比持续攀升。速度上虽然勉强过的去，但是CPU持续高占比。

当数据到到接近四百万条的时候，第二个衍生问题也凸显出来。四百万条数据的哈希表占用大量内存，查询的时候，CPU占比越来越高。

解决方式 ：手动解析 IPv4 字符串为网络字节序 uint，零堆分配。 /// 例如 "192.168.1.1" → 3232235777。

这样解决了第一个内存问题，将几百M的内存占用优化到几十M的内存。

第二个速度问题，通过 Array.BinarySearch 方式快速确定是否存在，通过这样的方式，响应比哈希表速度更快，占用内存更少。

通过此方式，半年左右的时间内，这个记录与识别爬虫IP的功能做了三次迭代，数据查询从个位到百万级，目前的设计规模在千万级，

如果没有意外的情况下，满足2026年的全年需求应该是没有问题的。

记录一下，这个识别方式与处理方式，是本站最大的数据级别识别，也是我个人的一个学习经验，后续也将会更好的优化此站的其他功能。

本此访问激增，还带来其他板块的性能问题，之后再独立说明