做这行七年，见过太多人在 Nginx 和 Lua 的坑里扑腾。特别是搞 ngx lua geo 这块，很多人以为装个模块就能跑，结果上线就是 CPU 飙红，请求延迟高得让人想砸键盘。今天不整那些虚头巴脑的理论，就聊聊我在生产环境里踩过的雷，以及怎么把 ngx lua geo 玩明白。

先说个最常见的误区。很多人觉得 GeoIP 模块就是查个库，简单得很。其实不然。在 Lua 里调用 GeoIP，如果每次请求都去读磁盘上的 mmdb 文件，那简直就是自杀。磁盘 IO 是瓶颈中的瓶颈。我见过一个案例，业务量刚过万 QPS，Nginx 直接卡死。为什么？因为每次 Lua 脚本执行都要去读取外部文件。正确的做法，必须是把 Geo 数据加载到内存里。ngx lua geo 的核心优势就在于此，利用 shared dict 或者直接在 Lua 初始化阶段加载数据到内存数组。

记得有个项目，我们要根据用户 IP 返回不同的静态资源。一开始用的是标准的 ngx_http_geoip_module，配置简单，但性能太差。后来换成了基于 Lua 的方案，利用 lua_shared_dict 来缓存 IP 段映射。这里有个细节，很多人不知道，Lua 的 table 查找虽然快，但如果数据量太大，比如几百万条 IP 段，线性查找也会慢。所以，得用二分查找或者前缀树（Trie）结构来优化查询效率。我在代码里写了一个简单的二分查找函数，把 IP 转换成整数，然后在内存数组里找区间，这样查询速度能提升好几个数量级。

还有一个坑，就是并发问题。Lua 在 Nginx 里是单线程执行的，但 Nginx 是多进程的。如果你用了 lua_shared_dict，要注意锁机制。虽然 ngx.shared.DICT 是线程安全的，但在高并发下，频繁加锁解锁也会消耗性能。我的经验是，尽量减少对 shared dict 的读写次数。比如，可以在 Lua 的 init_by_lua 阶段就把数据加载到全局变量里，这样每个 worker 进程都有自己的内存副本，完全避免了共享内存的竞争。当然，这会导致数据更新不及时，但对于 Geo 数据这种变化频率极低的场景，完全够用。

再说说数据源的问题。MaxMind 的 GeoIP2 数据库是免费的，但精度有限。如果需要更精准的城市级定位，得买付费版。不过，对于大多数国内业务，结合淘宝 IP 库或者纯真 IP 库可能更实用。我在项目里混合使用了两种数据源，先用 ngx lua geo 快速判断大区，再根据大区调用内部接口获取更细粒度的信息。这种分层策略，既保证了速度，又兼顾了精度。

配置上，别嫌麻烦。nginx.conf 里的 lua_package_path 一定要配对，不然加载模块会报错，而且很难排查。我习惯把 Lua 脚本独立出来，放在专门的目录下，通过 require 引入。这样代码结构清晰，也方便调试。记得开启 lua_code_cache on，否则每次请求都会重新解析 Lua 代码，性能损失巨大。

最后，监控不能少。上了 ngx lua geo 之后，一定要监控 Lua 脚本的执行时间。如果发现某个请求耗时超过 10ms，大概率是 Geo 查询出了问题。可以用 lua-resty-logger 或者 Prometheus exporter 来收集指标。我见过一个案例，就是因为没监控，导致某个 IP 段数据异常，影响了整个地区的用户访问，直到老板投诉才发现。

总之，ngx lua geo 不是银弹，它需要细致的调优和合理的架构设计。别指望装个模块就万事大吉。从内存加载、数据结构优化、并发控制到监控告警，每一步都得踩实。只有把这些细节都做到位，才能真正发挥它的高并发优势。希望这些经验能帮你在生产环境里少掉几根头发。毕竟，做技术，稳字当头。

本文关键词：ngx lua geo