：MMDB與高性能實(shí)踐)
1. 為什么要把IP查詢能力攥在自己手里做后端開發(fā)或者運(yùn)維的朋友大概率都遇到過這樣的場(chǎng)景用戶登錄日志里需要記錄歸屬地、風(fēng)控系統(tǒng)要判斷異地登錄、CDN調(diào)度要按地域做分流、甚至運(yùn)營(yíng)后臺(tái)想看看用戶都從哪些城市來。這些需求背后都指向同一個(gè)基礎(chǔ)能力——IP地址查詢。早期圖省事很多人直接調(diào)第三方公開接口傳個(gè)IP過去返回省市區(qū)。但用著用著問題就來了免費(fèi)接口有頻率限制QPS一上來就給你返回429商業(yè)接口按調(diào)用量計(jì)費(fèi)日活稍微漲一漲賬單就跟著漲更麻煩的是數(shù)據(jù)出境合規(guī)問題用戶IP屬于個(gè)人信息每次查詢都往外部服務(wù)發(fā)審計(jì)的時(shí)候說不清楚。還有一個(gè)容易被忽略的點(diǎn)——延遲。第三方接口再快也要走公網(wǎng)一次查詢幾十毫秒高并發(fā)場(chǎng)景下這就是實(shí)打?qū)嵉男阅軗p耗。所以這兩年我經(jīng)手的項(xiàng)目里只要涉及IP歸屬地查詢基本都走私有化部署這條路。所謂私有化部署說白了就是把IP庫(kù)和查詢服務(wù)裝在自己的Linux服務(wù)器上數(shù)據(jù)不出內(nèi)網(wǎng)查詢走本地回環(huán)QPS想拉多高拉多高成本就是一臺(tái)機(jī)器的錢。這篇文章就把我踩過坑、調(diào)過優(yōu)的一套完整方案拆開來講從選庫(kù)、裝環(huán)境、寫服務(wù)到壓測(cè)調(diào)優(yōu)盡量讓不同基礎(chǔ)的朋友都能照著復(fù)現(xiàn)。適合誰(shuí)看如果你是后端開發(fā)、運(yùn)維工程師、SRE或者正在做風(fēng)控、日志分析、用戶畫像相關(guān)的系統(tǒng)這套方案可以直接抄作業(yè)。如果你只是偶爾查幾個(gè)IP那用在線工具就夠了沒必要折騰。但只要你面對(duì)的是日均百萬(wàn)級(jí)以上的查詢量或者對(duì)數(shù)據(jù)合規(guī)有硬性要求私有化部署就是繞不開的選擇。2. 方案整體設(shè)計(jì)與選型思路2.1 私有化部署到底解決了哪些痛點(diǎn)先把賬算清楚。假設(shè)你的系統(tǒng)日均查詢量是500萬(wàn)次用某商業(yè)API按每萬(wàn)次幾毛錢算一個(gè)月下來也是幾百到上千塊一年就是大幾千。而私有化部署呢一臺(tái)2核4G的云服務(wù)器一年成本也就幾百塊IP庫(kù)用開源的查詢服務(wù)自己寫邊際成本幾乎為零。查詢量越大私有化的優(yōu)勢(shì)越明顯。除了成本還有三個(gè)硬指標(biāo)是第三方接口給不了的。第一是延遲可控本地查詢走內(nèi)存或本地文件單次查詢可以壓到微秒級(jí)而公網(wǎng)接口再優(yōu)化也難低于10毫秒。第二是穩(wěn)定性自主不用擔(dān)心對(duì)方接口掛了、限流了、或者突然改計(jì)費(fèi)規(guī)則。第三是數(shù)據(jù)合規(guī)用戶IP不離開自己的服務(wù)器審計(jì)的時(shí)候底氣足。提示私有化部署不是沒有代價(jià)的。你需要自己維護(hù)IP庫(kù)的更新自己處理服務(wù)的高可用自己扛住查詢壓力。如果團(tuán)隊(duì)沒有運(yùn)維能力或者查詢量很小老老實(shí)實(shí)用第三方接口反而更省心。2.2 IP庫(kù)格式怎么選MMDB還是CSVIP庫(kù)的原始數(shù)據(jù)通常有兩種形態(tài)一種是純文本的CSV一行一個(gè)網(wǎng)段加歸屬地信息另一種是二進(jìn)制格式最典型的就是MMDBMaxMind DB格式。這兩種格式的選擇直接決定了你后面查詢服務(wù)的實(shí)現(xiàn)方式。CSV的好處是直觀用文本編輯器就能看方便做數(shù)據(jù)清洗和二次加工。但缺點(diǎn)也很明顯文件體積大全量加載到內(nèi)存占空間查詢的時(shí)候要么全表掃描要么自己建索引性能很難做上去。我試過用CSV加二分查找單次查詢大概在幾十微秒但內(nèi)存占用是MMDB的好幾倍。MMDB是專門為IP查詢?cè)O(shè)計(jì)的二進(jìn)制格式內(nèi)部用了一種叫二叉搜索樹的結(jié)構(gòu)查詢的時(shí)候按IP的二進(jìn)制位逐位比較時(shí)間復(fù)雜度是O(32)或者O(128)跟數(shù)據(jù)量無(wú)關(guān)。文件體積小加載快查詢穩(wěn)定在微秒級(jí)。缺點(diǎn)是格式不透明想改數(shù)據(jù)得用專門的工具。所以我的建議很明確生產(chǎn)環(huán)境用MMDB數(shù)據(jù)加工階段用CSV。具體做法是拿CSV做清洗和合并然后用官方工具轉(zhuǎn)成MMDB部署的時(shí)候只帶MMDB文件。2.3 查詢服務(wù)的三種實(shí)現(xiàn)路線庫(kù)選好了接下來是怎么對(duì)外提供服務(wù)。我總結(jié)下來有三條路線各有適用場(chǎng)景。第一條是嵌入式直接把MMDB解析庫(kù)編譯進(jìn)你的業(yè)務(wù)代碼里。比如Go語(yǔ)言用oschwald/maxminddb-golangPython用maxminddbJava用com.maxmind.db。這種方式?jīng)]有網(wǎng)絡(luò)開銷性能最好但缺點(diǎn)是每個(gè)業(yè)務(wù)服務(wù)都要帶一份庫(kù)文件更新的時(shí)候得挨個(gè)重啟。第二條是本地HTTP服務(wù)單獨(dú)起一個(gè)進(jìn)程加載MMDB對(duì)外暴露REST接口業(yè)務(wù)方通過127.0.0.1調(diào)用。這種方式解耦做得好庫(kù)更新只需要重啟這一個(gè)服務(wù)業(yè)務(wù)方無(wú)感知。代價(jià)是多了一次本地網(wǎng)絡(luò)往返大概增加幾十微秒。第三條是Unix Domain Socket比HTTP更輕量省掉了TCP握手和HTTP頭解析的開銷。適合對(duì)延遲極度敏感的場(chǎng)景但調(diào)試起來沒有HTTP方便curl都不好直接用。我個(gè)人的選擇是中小規(guī)模用嵌入式大規(guī)模用本地HTTP服務(wù)。嵌入式適合查詢量不大、服務(wù)數(shù)量少的場(chǎng)景本地HTTP服務(wù)適合微服務(wù)架構(gòu)一個(gè)查詢服務(wù)給幾十個(gè)業(yè)務(wù)方用維護(hù)成本最低。2.4 為什么是Linux這個(gè)標(biāo)題里專門點(diǎn)了Linux不是沒有道理的。IP查詢服務(wù)對(duì)系統(tǒng)資源的要求很特殊內(nèi)存要夠大MMDB全量加載CPU不用太強(qiáng)查詢是輕量計(jì)算網(wǎng)絡(luò)IO要低延遲本地調(diào)用。Linux在這三點(diǎn)上都有天然優(yōu)勢(shì)。具體來說Linux的mmap系統(tǒng)調(diào)用可以把MMDB文件直接映射到內(nèi)存多個(gè)進(jìn)程共享同一份物理內(nèi)存不用每個(gè)進(jìn)程都拷貝一份。文件更新的時(shí)候只要原子替換文件再重新mmap就能做到熱更新。這些特性在Windows上要么沒有要么用起來很別扭。另外Linux的systemd管理服務(wù)、cgroup限制資源、perf做性能分析這一整套工具鏈對(duì)運(yùn)維非常友好。我試過在Windows Server上部署類似的服務(wù)光是處理文件鎖和內(nèi)存映射就折騰了半天最后還是換回Linux。3. 環(huán)境準(zhǔn)備與IP庫(kù)處理實(shí)操3.1 服務(wù)器配置與系統(tǒng)調(diào)優(yōu)先說說機(jī)器怎么選。MMDB文件的大小取決于IP庫(kù)的精細(xì)程度城市級(jí)庫(kù)大概幾十MB如果帶經(jīng)緯度、ISP、ASN信息可能到一百多MB。全量加載到內(nèi)存加上服務(wù)本身的開銷2GB內(nèi)存是起步4GB比較從容。CPU方面查詢是純計(jì)算2核足夠撐起每秒幾萬(wàn)次的查詢。磁盤用普通的SSD就行因?yàn)椴樵冏邇?nèi)存磁盤只在加載和更新的時(shí)候用。系統(tǒng)層面有幾個(gè)參數(shù)建議調(diào)一下。首先是文件描述符限制HTTP服務(wù)并發(fā)高的時(shí)候默認(rèn)的1024可能不夠# 查看當(dāng)前限制 ulimit -n # 臨時(shí)調(diào)整 ulimit -n 65535 # 永久調(diào)整編輯 /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535然后是vm.swappiness這個(gè)參數(shù)控制內(nèi)存換出到磁盤的傾向。IP查詢服務(wù)希望MMDB常駐內(nèi)存所以建議調(diào)低# 查看當(dāng)前值 cat /proc/sys/vm/swappiness # 臨時(shí)設(shè)為10 sysctl vm.swappiness10 # 永久生效寫入 /etc/sysctl.conf vm.swappiness10注意不要設(shè)成0。設(shè)成0在內(nèi)存緊張的時(shí)候可能觸發(fā)OOM Killer把服務(wù)殺掉。設(shè)成10是個(gè)比較穩(wěn)妥的折中。3.2 IP庫(kù)的獲取與格式轉(zhuǎn)換IP庫(kù)的數(shù)據(jù)來源開源社區(qū)有幾個(gè)選擇。最常用的是MaxMind的GeoLite2免費(fèi)版提供國(guó)家、城市、ASN三個(gè)維度的數(shù)據(jù)精度對(duì)大部分場(chǎng)景夠用。下載下來是.mmdb格式可以直接用。如果你需要更細(xì)的街道級(jí)數(shù)據(jù)那就得考慮商業(yè)庫(kù)了這里不展開。拿到MMDB之后建議先做個(gè)校驗(yàn)確認(rèn)文件完整、能正常解析。用官方提供的mmdblookup工具# 安裝工具 apt-get install mmdb-bin # 查詢一個(gè)IP試試 mmdblookup --file GeoLite2-City.mmdb --ip 8.8.8.8如果輸出了一堆嵌套的JSON結(jié)構(gòu)說明文件沒問題。接下來是數(shù)據(jù)加工。開源庫(kù)有時(shí)候會(huì)有網(wǎng)段重疊或者缺失的情況如果你對(duì)精度要求高可以拿CSV版本做一次合并清洗。思路是把所有網(wǎng)段按起始IP排序然后逐個(gè)合并相鄰或重疊的段最后用mmdbwriter工具重新生成MMDB。# 偽代碼示意實(shí)際用Python或Go寫 # 1. 讀取CSV解析成 (start_ip, end_ip, country, city) 的列表 # 2. 按start_ip排序 # 3. 遍歷合并如果當(dāng)前段的start 上一段的end 1就合并 # 4. 輸出清洗后的CSV # 5. 用mmdbwriter轉(zhuǎn)成MMDB這一步不是必須的但做過之后查詢準(zhǔn)確率會(huì)有肉眼可見的提升尤其是那些跨國(guó)企業(yè)內(nèi)網(wǎng)或者云服務(wù)商的IP段。3.3 目錄規(guī)劃與文件權(quán)限部署之前先把目錄結(jié)構(gòu)定好后面維護(hù)起來省心。我習(xí)慣這樣規(guī)劃/opt/ipdb/ ├── bin/ # 可執(zhí)行文件 ├── data/ # MMDB文件 │ ├── current/ # 當(dāng)前使用的庫(kù) │ └── backup/ # 歷史版本備份 ├── conf/ # 配置文件 ├── logs/ # 日志 └── scripts/ # 更新腳本權(quán)限方面MMDB文件建議設(shè)為640屬主是服務(wù)運(yùn)行用戶屬組是運(yùn)維組。這樣既能保證服務(wù)讀取又不會(huì)讓其他用戶隨便看到數(shù)據(jù)。服務(wù)進(jìn)程用獨(dú)立的低權(quán)限用戶跑別用root# 創(chuàng)建專用用戶 useradd -r -s /sbin/nologin ipdb # 設(shè)置目錄權(quán)限 chown -R ipdb:ipdb /opt/ipdb chmod 750 /opt/ipdb chmod 640 /opt/ipdb/data/current/*.mmdb提示如果你的服務(wù)器上有多個(gè)業(yè)務(wù)方需要查詢不要給他們直接讀MMDB的權(quán)限而是通過HTTP服務(wù)統(tǒng)一出口。這樣既能控制訪問又方便做審計(jì)。4. 查詢服務(wù)的實(shí)現(xiàn)與部署4.1 用Go寫一個(gè)高性能查詢服務(wù)Go語(yǔ)言是我做這類服務(wù)的首選編譯出來是靜態(tài)二進(jìn)制部署的時(shí)候拷貝一個(gè)文件就行沒有依賴問題。下面是一個(gè)完整的HTTP查詢服務(wù)示例核心邏輯就是加載MMDB然后對(duì)外提供/lookup接口。package main import ( encoding/json flag log net net/http github.com/oschwald/maxminddb-golang ) var db *maxminddb.Reader type Record struct { Country struct { ISOCode string maxminddb:iso_code } maxminddb:country City struct { Names map[string]string maxminddb:names } maxminddb:city } func lookupHandler(w http.ResponseWriter, r *http.Request) { ipStr : r.URL.Query().Get(ip) if ipStr { http.Error(w, missing ip, http.StatusBadRequest) return } ip : net.ParseIP(ipStr) if ip nil { http.Error(w, invalid ip, http.StatusBadRequest) return } var rec Record err : db.Lookup(ip, rec) if err ! nil { http.Error(w, lookup failed, http.StatusInternalServerError) return } w.Header().Set(Content-Type, application/json) json.NewEncoder(w).Encode(rec) } func main() { dbPath : flag.String(db, /opt/ipdb/data/current/GeoLite2-City.mmdb, path to mmdb) addr : flag.String(addr, 127.0.0.1:8080, listen address) flag.Parse() var err error db, err maxminddb.Open(*dbPath) if err ! nil { log.Fatalf(open db failed: %v, err) } defer db.Close() http.HandleFunc(/lookup, lookupHandler) log.Printf(listening on %s, *addr) log.Fatal(http.ListenAndServe(*addr, nil)) }編譯命令很簡(jiǎn)單go mod init ipdb-service go get github.com/oschwald/maxminddb-golang go build -o /opt/ipdb/bin/ipdb-service main.go這個(gè)服務(wù)監(jiān)聽在127.0.0.1:8080只允許本機(jī)訪問。業(yè)務(wù)方通過http://127.0.0.1:8080/lookup?ip8.8.8.8就能拿到歸屬地。實(shí)測(cè)下來單次查詢?cè)?0微秒左右QPS輕松過萬(wàn)。4.2 用systemd托管服務(wù)手動(dòng)跑進(jìn)程不是長(zhǎng)久之計(jì)用systemd托管才能做到開機(jī)自啟、崩潰重啟、日志歸集。寫一個(gè)unit文件[Unit] DescriptionIP Lookup Service Afternetwork.target [Service] Typesimple Useripdb Groupipdb ExecStart/opt/ipdb/bin/ipdb-service -db /opt/ipdb/data/current/GeoLite2-City.mmdb -addr 127.0.0.1:8080 Restartalways RestartSec3 LimitNOFILE65535 # 安全加固 NoNewPrivilegestrue PrivateTmptrue ProtectSystemstrict ReadOnlyPaths/opt/ipdb/data [Install] WantedBymulti-user.target保存到/etc/systemd/system/ipdb.service然后systemctl daemon-reload systemctl enable ipdb systemctl start ipdb systemctl status ipdbRestartalways保證進(jìn)程掛了自動(dòng)拉起來ProtectSystemstrict把文件系統(tǒng)設(shè)為只讀只有/opt/ipdb/data可讀這樣即使服務(wù)被攻破攻擊者也改不了系統(tǒng)文件。4.3 庫(kù)更新的熱加載方案IP庫(kù)不是一成不變的每個(gè)月都有新的網(wǎng)段分配和變更。更新的時(shí)候不能停服務(wù)得做熱加載。思路是新庫(kù)下載到臨時(shí)目錄校驗(yàn)通過后原子替換current目錄下的文件然后給服務(wù)發(fā)個(gè)信號(hào)讓它重新打開文件。Go服務(wù)這邊加一個(gè)信號(hào)處理import ( os os/signal syscall ) func main() { // ... 前面的代碼 sigCh : make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGHUP) go func() { for range sigCh { newDB, err : maxminddb.Open(*dbPath) if err ! nil { log.Printf(reload failed: %v, err) continue } oldDB : db db newDB oldDB.Close() log.Println(db reloaded) } }() // ... 啟動(dòng)HTTP服務(wù) }更新腳本大概長(zhǎng)這樣#!/bin/bash set -e NEW_DB/tmp/GeoLite2-City.mmdb CURRENT/opt/ipdb/data/current/GeoLite2-City.mmdb BACKUP/opt/ipdb/data/backup/GeoLite2-City-$(date %Y%m%d).mmdb # 下載新庫(kù)這里用wget示意實(shí)際按你的源來 wget -O $NEW_DB https://example.com/GeoLite2-City.mmdb # 校驗(yàn) mmdblookup --file $NEW_DB --ip 8.8.8.8 /dev/null # 備份舊庫(kù) cp $CURRENT $BACKUP # 原子替換 mv $NEW_DB $CURRENT chown ipdb:ipdb $CURRENT chmod 640 $CURRENT # 通知服務(wù)重載 systemctl reload ipdb注意mv在同一文件系統(tǒng)內(nèi)是原子操作所以/tmp和/opt如果在不同分區(qū)要先cp再mv否則替換過程中可能出現(xiàn)文件不完整的情況。5. 性能壓測(cè)與調(diào)優(yōu)實(shí)錄5.1 壓測(cè)工具與基準(zhǔn)數(shù)據(jù)服務(wù)跑起來之后得知道它能扛多少。壓測(cè)工具我用wrk比ab更輕量支持多線程。先裝一下apt-get install wrk然后寫個(gè)壓測(cè)腳本隨機(jī)生成IP去查# 生成測(cè)試IP列表 for i in $(seq 1 10000); do echo 8.8.$((RANDOM % 256)).$((RANDOM % 256)) done /tmp/ips.txt # 用wrk壓測(cè)需要配合lua腳本讀取IP wrk -t4 -c100 -d30s --latency -s lookup.lua http://127.0.0.1:8080lookup.lua的內(nèi)容local ips {} for line in io.lines(/tmp/ips.txt) do table.insert(ips, line) end request function() local ip ips[math.random(#ips)] return wrk.format(GET, /lookup?ip .. ip) end我實(shí)測(cè)的數(shù)據(jù)2核4G的機(jī)器100并發(fā)下QPS穩(wěn)定在35000左右P99延遲不到1毫秒。這個(gè)性能對(duì)絕大多數(shù)業(yè)務(wù)來說都綽綽有余了。5.2 瓶頸定位與優(yōu)化手段如果壓測(cè)數(shù)據(jù)不理想先別急著加機(jī)器按下面的順序排查。第一看CPU。用top -H看是不是某個(gè)核跑滿了。如果是說明查詢邏輯本身有優(yōu)化空間。MMDB查詢是純內(nèi)存操作理論上不應(yīng)該成為瓶頸。檢查一下是不是每次查詢都重新解析了IP字符串這個(gè)可以提前緩存。第二看內(nèi)存。用free -h看MMDB有沒有被換出。如果swap使用量在漲說明vm.swappiness沒調(diào)好或者內(nèi)存真的不夠。MMDB文件多大常駐內(nèi)存就至少多大。第三看網(wǎng)絡(luò)。雖然走的是回環(huán)但HTTP協(xié)議本身有開銷。如果QPS上不去可以試試換成Unix Domain Socket能省掉TCP握手和HTTP頭解析大概能提升20%到30%的吞吐。第四看文件描述符。ss -s看連接數(shù)如果接近ulimit -n就得往上調(diào)。提示壓測(cè)的時(shí)候別用127.0.0.1以外的地址否則測(cè)出來的是網(wǎng)卡性能不是服務(wù)性能。另外壓測(cè)機(jī)和被測(cè)服務(wù)別放同一臺(tái)機(jī)器會(huì)互相搶CPU。5.3 高可用與橫向擴(kuò)展單機(jī)服務(wù)總有掛的時(shí)候生產(chǎn)環(huán)境得考慮高可用。最簡(jiǎn)單的方案是雙機(jī)熱備兩臺(tái)機(jī)器都跑查詢服務(wù)前面掛一個(gè)本地的負(fù)載均衡比如nginx或者h(yuǎn)aproxy。業(yè)務(wù)方調(diào)127.0.0.1:80由負(fù)載均衡轉(zhuǎn)發(fā)到兩個(gè)后端。upstream ipdb { server 127.0.0.1:8080; server 127.0.0.1:8081; keepalive 64; } server { listen 127.0.0.1:80; location /lookup { proxy_pass http://ipdb; proxy_http_version 1.1; proxy_set_header Connection ; } }如果查詢量特別大單機(jī)扛不住那就得分片。按IP的第一段做哈希比如1.x.x.x走機(jī)器A2.x.x.x走機(jī)器B業(yè)務(wù)方根據(jù)IP自己路由。這種方式?jīng)]有中心節(jié)點(diǎn)擴(kuò)展性最好但業(yè)務(wù)方要改代碼。還有一種偷懶的做法是多進(jìn)程。Go服務(wù)本身是單進(jìn)程的但你可以起多個(gè)實(shí)例監(jiān)聽不同端口然后用SO_REUSEPORT讓內(nèi)核做負(fù)載均衡。Linux 3.9以上支持這個(gè)特性配置起來也簡(jiǎn)單import golang.org/x/sys/unix lc : net.ListenConfig{ Control: func(network, address string, c syscall.RawConn) error { return c.Control(func(fd uintptr) { unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1) }) }, } ln, _ : lc.Listen(context.Background(), tcp, 127.0.0.1:8080)這樣起4個(gè)進(jìn)程監(jiān)聽同一個(gè)端口內(nèi)核會(huì)自動(dòng)把連接分給不同的進(jìn)程充分利用多核。6. 常見問題與排查技巧6.1 查詢結(jié)果不準(zhǔn)怎么辦這是被問得最多的問題。IP歸屬地查詢本身就不是100%準(zhǔn)確的原因有幾個(gè)一是IP庫(kù)更新有延遲新分配的網(wǎng)段可能還沒收錄二是運(yùn)營(yíng)商動(dòng)態(tài)分配IP同一個(gè)IP在不同時(shí)間可能屬于不同地區(qū)三是企業(yè)專線和云服務(wù)商的IP注冊(cè)地和實(shí)際使用地經(jīng)常對(duì)不上。排查思路是這樣的先確認(rèn)你用的庫(kù)是不是最新的mmdblookup查一下這個(gè)IP在庫(kù)里有沒有記錄。如果沒有記錄那就是庫(kù)沒覆蓋到等更新或者換更全的庫(kù)。如果有記錄但結(jié)果不對(duì)那就是數(shù)據(jù)源本身的問題換商業(yè)庫(kù)可能能解決但也不保證100%。提示對(duì)于風(fēng)控場(chǎng)景別把IP歸屬地當(dāng)成唯一判斷依據(jù)。它只是一個(gè)弱信號(hào)要結(jié)合設(shè)備指紋、行為特征一起看。我見過太多因?yàn)镮P庫(kù)不準(zhǔn)導(dǎo)致誤殺的案例了。6.2 服務(wù)啟動(dòng)報(bào)錯(cuò)排查表報(bào)錯(cuò)信息可能原因解決方法open db failed: no such file路徑寫錯(cuò)或文件不存在檢查-db參數(shù)確認(rèn)文件在/opt/ipdb/data/current/下permission denied服務(wù)用戶沒有讀權(quán)限chown ipdb:ipdb并chmod 640address already in use端口被占用ss -tlnptoo many open files文件描述符不夠調(diào)大LimitNOFILE重啟服務(wù)lookup failed: invalid databaseMMDB文件損壞重新下載用mmdblookup校驗(yàn)6.3 內(nèi)存占用異常增長(zhǎng)正常情況下MMDB加載后內(nèi)存占用是穩(wěn)定的不會(huì)持續(xù)增長(zhǎng)。如果發(fā)現(xiàn)內(nèi)存一直漲大概率是內(nèi)存泄漏。Go服務(wù)雖然自帶GC但如果代碼里不斷創(chuàng)建大對(duì)象又不釋放也會(huì)出問題。排查方法是用pprofimport _ net/http/pprof // 在main里加 go func() { log.Println(http.ListenAndServe(127.0.0.1:6060, nil)) }()然后go tool pprof http://127.0.0.1:6060/debug/pprof/heap進(jìn)去之后用top命令看哪個(gè)函數(shù)占內(nèi)存最多。我遇到過一種情況是每次查詢都json.Marshal一個(gè)大的結(jié)構(gòu)體導(dǎo)致大量臨時(shí)對(duì)象。解決辦法是復(fù)用bytes.Buffer或者直接用json.Encoder寫到ResponseWriter。6.4 更新庫(kù)之后服務(wù)沒生效這個(gè)坑我踩過。更新腳本里mv替換了文件systemctl reload也發(fā)了信號(hào)但查詢結(jié)果還是舊的。原因有兩個(gè)一是systemd的reload默認(rèn)發(fā)的是SIGTERM不是SIGHUP需要在unit文件里指定[Service] ExecReload/bin/kill -HUP $MAINPID二是Go服務(wù)里db變量是全局的信號(hào)處理協(xié)程里改了db但HTTP處理函數(shù)讀的可能是舊的引用。解決辦法是用atomic.Value包一層var db atomic.Value // 加載 db.Store(newDB) // 查詢 reader : db.Load().(*maxminddb.Reader) reader.Lookup(ip, rec)這樣就能保證讀寫安全更新立即生效。6.5 日志太多把磁盤寫滿查詢服務(wù)如果每個(gè)請(qǐng)求都打日志一天下來幾個(gè)GB就沒了。生產(chǎn)環(huán)境建議只記錄錯(cuò)誤日志正常查詢不打。如果確實(shí)需要審計(jì)可以采樣記錄比如每1000次記一條。用logrotate做日志切割/opt/ipdb/logs/*.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate很重要因?yàn)镚o服務(wù)可能一直持有文件句柄直接mv會(huì)導(dǎo)致日志寫到舊文件里。7. 幾個(gè)容易被忽略的細(xì)節(jié)7.1 IPv6的支持現(xiàn)在IPv6越來越普及查詢服務(wù)必須支持。MMDB格式本身是支持IPv6的maxminddb-golang也能直接查。但要注意IPv6的查詢樹深度是128比IPv4的32深單次查詢會(huì)稍微慢一點(diǎn)不過還是在微秒級(jí)。如果你的業(yè)務(wù)暫時(shí)只處理IPv4可以在入口處把IPv6地址轉(zhuǎn)成IPv4映射地址但這不是長(zhǎng)久之計(jì)。建議直接支持反正代碼上沒什么額外成本。7.2 內(nèi)網(wǎng)IP的處理MMDB庫(kù)里通常不包含內(nèi)網(wǎng)網(wǎng)段10.0.0.0/8、172.16.0.0/12、192.168.0.0/16查詢這些IP會(huì)返回空。業(yè)務(wù)方拿到空結(jié)果可能會(huì)報(bào)錯(cuò)。解決辦法是在查詢服務(wù)里加一層判斷遇到內(nèi)網(wǎng)IP直接返回一個(gè)固定的標(biāo)記if ip.IsPrivate() { json.NewEncoder(w).Encode(map[string]string{type: private}) return }這樣業(yè)務(wù)方就能區(qū)分“查不到”和“內(nèi)網(wǎng)IP”兩種情況。7.3 時(shí)區(qū)與編碼問題城市名稱在MMDB里是多語(yǔ)言的names字段是個(gè)map鍵是語(yǔ)言代碼。默認(rèn)可能返回英文如果你需要中文得在查詢的時(shí)候指定type Record struct { City struct { Names map[string]string maxminddb:names } maxminddb:city } // 取中文 cityName : rec.City.Names[zh-CN] if cityName { cityName rec.City.Names[en] }注意不是所有城市都有中文翻譯取不到的時(shí)候要有個(gè)兜底。7.4 監(jiān)控指標(biāo)怎么埋生產(chǎn)服務(wù)沒有監(jiān)控就是裸奔。至少埋這幾個(gè)指標(biāo)QPS、P99延遲、錯(cuò)誤率、MMDB加載時(shí)間。用Prometheus的話加一個(gè)/metrics接口import github.com/prometheus/client_golang/prometheus/promhttp http.Handle(/metrics, promhttp.Handler())然后在查詢函數(shù)里打點(diǎn)var ( queryCount prometheus.NewCounter(prometheus.CounterOpts{ Name: ipdb_query_total, Help: Total queries, }) queryDuration prometheus.NewHistogram(prometheus.HistogramOpts{ Name: ipdb_query_duration_seconds, Buckets: []float64{0.0001, 0.0005, 0.001, 0.005, 0.01}, }) ) func init() { prometheus.MustRegister(queryCount, queryDuration) }這樣在Grafana上就能看到實(shí)時(shí)的查詢量和延遲分布出問題的時(shí)候一眼就能定位。7.5 庫(kù)更新的自動(dòng)化手動(dòng)更新庫(kù)容易忘建議做成定時(shí)任務(wù)。用cron每天凌晨跑一次更新腳本# 編輯 crontab crontab -e # 每天凌晨3點(diǎn)更新 0 3 * * * /opt/ipdb/scripts/update.sh /opt/ipdb/logs/update.log 21更新腳本里加上失敗重試和告警。如果連續(xù)三天更新失敗發(fā)個(gè)郵件或者釘釘通知。別等到庫(kù)過期半年了才發(fā)現(xiàn)。8. 寫在最后的一些個(gè)人體會(huì)這套方案我在三個(gè)項(xiàng)目里落地過最大的感受是私有化部署的門檻比想象中低但維護(hù)的細(xì)節(jié)比想象中多。裝個(gè)服務(wù)、跑個(gè)查詢半天就能搞定但要讓它穩(wěn)定跑一年不出問題得在監(jiān)控、更新、容災(zāi)上花不少心思。如果讓我給剛上手的朋友一個(gè)建議那就是先把單機(jī)跑通再考慮高可用。很多人一上來就搞集群、搞分片結(jié)果基礎(chǔ)服務(wù)都沒調(diào)穩(wěn)出了問題排查半天。先用一臺(tái)機(jī)器把查詢服務(wù)跑起來壓測(cè)看看性能確認(rèn)能滿足業(yè)務(wù)需求然后再逐步加監(jiān)控、加備份、加負(fù)載均衡。還有一個(gè)心得是別過度設(shè)計(jì)。IP查詢本身是個(gè)很簡(jiǎn)單的需求MMDB加一個(gè)HTTP服務(wù)就夠了。我見過有人用Elasticsearch存IP段做范圍查詢性能差不說維護(hù)成本還高。工具選型要匹配需求殺雞別用牛刀。最后說個(gè)實(shí)際的數(shù)據(jù)我這套方案在2核4G的機(jī)器上支撐了日均800萬(wàn)次查詢P99延遲0.8毫秒運(yùn)行半年零故障。成本是一年幾百塊的服務(wù)器費(fèi)用相比商業(yè)API省了90%以上。如果你也在為IP查詢的成本和合規(guī)發(fā)愁不妨試試這條路。 Linux私有化部署IP歸屬地查詢服務(wù)：MMDB與高性能實(shí)踐
1. 為什么要把IP查詢能力攥在自己手里做后端開發(fā)或者運(yùn)維的朋友大概率都遇到過這樣的場(chǎng)景用戶登錄日志里需要記錄歸屬地、風(fēng)控系統(tǒng)要判斷異地登錄、CDN調(diào)度要按地域做分流、甚至運(yùn)營(yíng)后臺(tái)想看看用戶都從哪些城市來。這些需求背后都指向同一個(gè)基礎(chǔ)能力——IP地址查詢。早期圖省事很多人直接調(diào)第三方公開接口傳個(gè)IP過去返回省市區(qū)。但用著用著問題就來了免費(fèi)接口有頻率限制QPS一上來就給你返回429商業(yè)接口按調(diào)用量計(jì)費(fèi)日活稍微漲一漲賬單就跟著漲更麻煩的是數(shù)據(jù)出境合規(guī)問題用戶IP屬于個(gè)人信息每次查詢都往外部服務(wù)發(fā)審計(jì)的時(shí)候說不清楚。還有一個(gè)容易被忽略的點(diǎn)——延遲。第三方接口再快也要走公網(wǎng)一次查詢幾十毫秒高并發(fā)場(chǎng)景下這就是實(shí)打?qū)嵉男阅軗p耗。所以這兩年我經(jīng)手的項(xiàng)目里只要涉及IP歸屬地查詢基本都走私有化部署這條路。所謂私有化部署說白了就是把IP庫(kù)和查詢服務(wù)裝在自己的Linux服務(wù)器上數(shù)據(jù)不出內(nèi)網(wǎng)查詢走本地回環(huán)QPS想拉多高拉多高成本就是一臺(tái)機(jī)器的錢。這篇文章就把我踩過坑、調(diào)過優(yōu)的一套完整方案拆開來講從選庫(kù)、裝環(huán)境、寫服務(wù)到壓測(cè)調(diào)優(yōu)盡量讓不同基礎(chǔ)的朋友都能照著復(fù)現(xiàn)。適合誰(shuí)看如果你是后端開發(fā)、運(yùn)維工程師、SRE或者正在做風(fēng)控、日志分析、用戶畫像相關(guān)的系統(tǒng)這套方案可以直接抄作業(yè)。如果你只是偶爾查幾個(gè)IP那用在線工具就夠了沒必要折騰。但只要你面對(duì)的是日均百萬(wàn)級(jí)以上的查詢量或者對(duì)數(shù)據(jù)合規(guī)有硬性要求私有化部署就是繞不開的選擇。2. 方案整體設(shè)計(jì)與選型思路2.1 私有化部署到底解決了哪些痛點(diǎn)先把賬算清楚。假設(shè)你的系統(tǒng)日均查詢量是500萬(wàn)次用某商業(yè)API按每萬(wàn)次幾毛錢算一個(gè)月下來也是幾百到上千塊一年就是大幾千。而私有化部署呢一臺(tái)2核4G的云服務(wù)器一年成本也就幾百塊IP庫(kù)用開源的查詢服務(wù)自己寫邊際成本幾乎為零。查詢量越大私有化的優(yōu)勢(shì)越明顯。除了成本還有三個(gè)硬指標(biāo)是第三方接口給不了的。第一是延遲可控本地查詢走內(nèi)存或本地文件單次查詢可以壓到微秒級(jí)而公網(wǎng)接口再優(yōu)化也難低于10毫秒。第二是穩(wěn)定性自主不用擔(dān)心對(duì)方接口掛了、限流了、或者突然改計(jì)費(fèi)規(guī)則。第三是數(shù)據(jù)合規(guī)用戶IP不離開自己的服務(wù)器審計(jì)的時(shí)候底氣足。提示私有化部署不是沒有代價(jià)的。你需要自己維護(hù)IP庫(kù)的更新自己處理服務(wù)的高可用自己扛住查詢壓力。如果團(tuán)隊(duì)沒有運(yùn)維能力或者查詢量很小老老實(shí)實(shí)用第三方接口反而更省心。2.2 IP庫(kù)格式怎么選MMDB還是CSVIP庫(kù)的原始數(shù)據(jù)通常有兩種形態(tài)一種是純文本的CSV一行一個(gè)網(wǎng)段加歸屬地信息另一種是二進(jìn)制格式最典型的就是MMDBMaxMind DB格式。這兩種格式的選擇直接決定了你后面查詢服務(wù)的實(shí)現(xiàn)方式。CSV的好處是直觀用文本編輯器就能看方便做數(shù)據(jù)清洗和二次加工。但缺點(diǎn)也很明顯文件體積大全量加載到內(nèi)存占空間查詢的時(shí)候要么全表掃描要么自己建索引性能很難做上去。我試過用CSV加二分查找單次查詢大概在幾十微秒但內(nèi)存占用是MMDB的好幾倍。MMDB是專門為IP查詢?cè)O(shè)計(jì)的二進(jìn)制格式內(nèi)部用了一種叫二叉搜索樹的結(jié)構(gòu)查詢的時(shí)候按IP的二進(jìn)制位逐位比較時(shí)間復(fù)雜度是O(32)或者O(128)跟數(shù)據(jù)量無(wú)關(guān)。文件體積小加載快查詢穩(wěn)定在微秒級(jí)。缺點(diǎn)是格式不透明想改數(shù)據(jù)得用專門的工具。所以我的建議很明確生產(chǎn)環(huán)境用MMDB數(shù)據(jù)加工階段用CSV。具體做法是拿CSV做清洗和合并然后用官方工具轉(zhuǎn)成MMDB部署的時(shí)候只帶MMDB文件。2.3 查詢服務(wù)的三種實(shí)現(xiàn)路線庫(kù)選好了接下來是怎么對(duì)外提供服務(wù)。我總結(jié)下來有三條路線各有適用場(chǎng)景。第一條是嵌入式直接把MMDB解析庫(kù)編譯進(jìn)你的業(yè)務(wù)代碼里。比如Go語(yǔ)言用oschwald/maxminddb-golangPython用maxminddbJava用com.maxmind.db。這種方式?jīng)]有網(wǎng)絡(luò)開銷性能最好但缺點(diǎn)是每個(gè)業(yè)務(wù)服務(wù)都要帶一份庫(kù)文件更新的時(shí)候得挨個(gè)重啟。第二條是本地HTTP服務(wù)單獨(dú)起一個(gè)進(jìn)程加載MMDB對(duì)外暴露REST接口業(yè)務(wù)方通過127.0.0.1調(diào)用。這種方式解耦做得好庫(kù)更新只需要重啟這一個(gè)服務(wù)業(yè)務(wù)方無(wú)感知。代價(jià)是多了一次本地網(wǎng)絡(luò)往返大概增加幾十微秒。第三條是Unix Domain Socket比HTTP更輕量省掉了TCP握手和HTTP頭解析的開銷。適合對(duì)延遲極度敏感的場(chǎng)景但調(diào)試起來沒有HTTP方便curl都不好直接用。我個(gè)人的選擇是中小規(guī)模用嵌入式大規(guī)模用本地HTTP服務(wù)。嵌入式適合查詢量不大、服務(wù)數(shù)量少的場(chǎng)景本地HTTP服務(wù)適合微服務(wù)架構(gòu)一個(gè)查詢服務(wù)給幾十個(gè)業(yè)務(wù)方用維護(hù)成本最低。2.4 為什么是Linux這個(gè)標(biāo)題里專門點(diǎn)了Linux不是沒有道理的。IP查詢服務(wù)對(duì)系統(tǒng)資源的要求很特殊內(nèi)存要夠大MMDB全量加載CPU不用太強(qiáng)查詢是輕量計(jì)算網(wǎng)絡(luò)IO要低延遲本地調(diào)用。Linux在這三點(diǎn)上都有天然優(yōu)勢(shì)。具體來說Linux的mmap系統(tǒng)調(diào)用可以把MMDB文件直接映射到內(nèi)存多個(gè)進(jìn)程共享同一份物理內(nèi)存不用每個(gè)進(jìn)程都拷貝一份。文件更新的時(shí)候只要原子替換文件再重新mmap就能做到熱更新。這些特性在Windows上要么沒有要么用起來很別扭。另外Linux的systemd管理服務(wù)、cgroup限制資源、perf做性能分析這一整套工具鏈對(duì)運(yùn)維非常友好。我試過在Windows Server上部署類似的服務(wù)光是處理文件鎖和內(nèi)存映射就折騰了半天最后還是換回Linux。3. 環(huán)境準(zhǔn)備與IP庫(kù)處理實(shí)操3.1 服務(wù)器配置與系統(tǒng)調(diào)優(yōu)先說說機(jī)器怎么選。MMDB文件的大小取決于IP庫(kù)的精細(xì)程度城市級(jí)庫(kù)大概幾十MB如果帶經(jīng)緯度、ISP、ASN信息可能到一百多MB。全量加載到內(nèi)存加上服務(wù)本身的開銷2GB內(nèi)存是起步4GB比較從容。CPU方面查詢是純計(jì)算2核足夠撐起每秒幾萬(wàn)次的查詢。磁盤用普通的SSD就行因?yàn)椴樵冏邇?nèi)存磁盤只在加載和更新的時(shí)候用。系統(tǒng)層面有幾個(gè)參數(shù)建議調(diào)一下。首先是文件描述符限制HTTP服務(wù)并發(fā)高的時(shí)候默認(rèn)的1024可能不夠# 查看當(dāng)前限制 ulimit -n # 臨時(shí)調(diào)整 ulimit -n 65535 # 永久調(diào)整編輯 /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535然后是vm.swappiness這個(gè)參數(shù)控制內(nèi)存換出到磁盤的傾向。IP查詢服務(wù)希望MMDB常駐內(nèi)存所以建議調(diào)低# 查看當(dāng)前值 cat /proc/sys/vm/swappiness # 臨時(shí)設(shè)為10 sysctl vm.swappiness10 # 永久生效寫入 /etc/sysctl.conf vm.swappiness10注意不要設(shè)成0。設(shè)成0在內(nèi)存緊張的時(shí)候可能觸發(fā)OOM Killer把服務(wù)殺掉。設(shè)成10是個(gè)比較穩(wěn)妥的折中。3.2 IP庫(kù)的獲取與格式轉(zhuǎn)換IP庫(kù)的數(shù)據(jù)來源開源社區(qū)有幾個(gè)選擇。最常用的是MaxMind的GeoLite2免費(fèi)版提供國(guó)家、城市、ASN三個(gè)維度的數(shù)據(jù)精度對(duì)大部分場(chǎng)景夠用。下載下來是.mmdb格式可以直接用。如果你需要更細(xì)的街道級(jí)數(shù)據(jù)那就得考慮商業(yè)庫(kù)了這里不展開。拿到MMDB之后建議先做個(gè)校驗(yàn)確認(rèn)文件完整、能正常解析。用官方提供的mmdblookup工具# 安裝工具 apt-get install mmdb-bin # 查詢一個(gè)IP試試 mmdblookup --file GeoLite2-City.mmdb --ip 8.8.8.8如果輸出了一堆嵌套的JSON結(jié)構(gòu)說明文件沒問題。接下來是數(shù)據(jù)加工。開源庫(kù)有時(shí)候會(huì)有網(wǎng)段重疊或者缺失的情況如果你對(duì)精度要求高可以拿CSV版本做一次合并清洗。思路是把所有網(wǎng)段按起始IP排序然后逐個(gè)合并相鄰或重疊的段最后用mmdbwriter工具重新生成MMDB。# 偽代碼示意實(shí)際用Python或Go寫 # 1. 讀取CSV解析成 (start_ip, end_ip, country, city) 的列表 # 2. 按start_ip排序 # 3. 遍歷合并如果當(dāng)前段的start 上一段的end 1就合并 # 4. 輸出清洗后的CSV # 5. 用mmdbwriter轉(zhuǎn)成MMDB這一步不是必須的但做過之后查詢準(zhǔn)確率會(huì)有肉眼可見的提升尤其是那些跨國(guó)企業(yè)內(nèi)網(wǎng)或者云服務(wù)商的IP段。3.3 目錄規(guī)劃與文件權(quán)限部署之前先把目錄結(jié)構(gòu)定好后面維護(hù)起來省心。我習(xí)慣這樣規(guī)劃/opt/ipdb/ ├── bin/ # 可執(zhí)行文件 ├── data/ # MMDB文件 │ ├── current/ # 當(dāng)前使用的庫(kù) │ └── backup/ # 歷史版本備份 ├── conf/ # 配置文件 ├── logs/ # 日志 └── scripts/ # 更新腳本權(quán)限方面MMDB文件建議設(shè)為640屬主是服務(wù)運(yùn)行用戶屬組是運(yùn)維組。這樣既能保證服務(wù)讀取又不會(huì)讓其他用戶隨便看到數(shù)據(jù)。服務(wù)進(jìn)程用獨(dú)立的低權(quán)限用戶跑別用root# 創(chuàng)建專用用戶 useradd -r -s /sbin/nologin ipdb # 設(shè)置目錄權(quán)限 chown -R ipdb:ipdb /opt/ipdb chmod 750 /opt/ipdb chmod 640 /opt/ipdb/data/current/*.mmdb提示如果你的服務(wù)器上有多個(gè)業(yè)務(wù)方需要查詢不要給他們直接讀MMDB的權(quán)限而是通過HTTP服務(wù)統(tǒng)一出口。這樣既能控制訪問又方便做審計(jì)。4. 查詢服務(wù)的實(shí)現(xiàn)與部署4.1 用Go寫一個(gè)高性能查詢服務(wù)Go語(yǔ)言是我做這類服務(wù)的首選編譯出來是靜態(tài)二進(jìn)制部署的時(shí)候拷貝一個(gè)文件就行沒有依賴問題。下面是一個(gè)完整的HTTP查詢服務(wù)示例核心邏輯就是加載MMDB然后對(duì)外提供/lookup接口。package main import ( encoding/json flag log net net/http github.com/oschwald/maxminddb-golang ) var db *maxminddb.Reader type Record struct { Country struct { ISOCode string maxminddb:iso_code } maxminddb:country City struct { Names map[string]string maxminddb:names } maxminddb:city } func lookupHandler(w http.ResponseWriter, r *http.Request) { ipStr : r.URL.Query().Get(ip) if ipStr { http.Error(w, missing ip, http.StatusBadRequest) return } ip : net.ParseIP(ipStr) if ip nil { http.Error(w, invalid ip, http.StatusBadRequest) return } var rec Record err : db.Lookup(ip, rec) if err ! nil { http.Error(w, lookup failed, http.StatusInternalServerError) return } w.Header().Set(Content-Type, application/json) json.NewEncoder(w).Encode(rec) } func main() { dbPath : flag.String(db, /opt/ipdb/data/current/GeoLite2-City.mmdb, path to mmdb) addr : flag.String(addr, 127.0.0.1:8080, listen address) flag.Parse() var err error db, err maxminddb.Open(*dbPath) if err ! nil { log.Fatalf(open db failed: %v, err) } defer db.Close() http.HandleFunc(/lookup, lookupHandler) log.Printf(listening on %s, *addr) log.Fatal(http.ListenAndServe(*addr, nil)) }編譯命令很簡(jiǎn)單go mod init ipdb-service go get github.com/oschwald/maxminddb-golang go build -o /opt/ipdb/bin/ipdb-service main.go這個(gè)服務(wù)監(jiān)聽在127.0.0.1:8080只允許本機(jī)訪問。業(yè)務(wù)方通過http://127.0.0.1:8080/lookup?ip8.8.8.8就能拿到歸屬地。實(shí)測(cè)下來單次查詢?cè)?0微秒左右QPS輕松過萬(wàn)。4.2 用systemd托管服務(wù)手動(dòng)跑進(jìn)程不是長(zhǎng)久之計(jì)用systemd托管才能做到開機(jī)自啟、崩潰重啟、日志歸集。寫一個(gè)unit文件[Unit] DescriptionIP Lookup Service Afternetwork.target [Service] Typesimple Useripdb Groupipdb ExecStart/opt/ipdb/bin/ipdb-service -db /opt/ipdb/data/current/GeoLite2-City.mmdb -addr 127.0.0.1:8080 Restartalways RestartSec3 LimitNOFILE65535 # 安全加固 NoNewPrivilegestrue PrivateTmptrue ProtectSystemstrict ReadOnlyPaths/opt/ipdb/data [Install] WantedBymulti-user.target保存到/etc/systemd/system/ipdb.service然后systemctl daemon-reload systemctl enable ipdb systemctl start ipdb systemctl status ipdbRestartalways保證進(jìn)程掛了自動(dòng)拉起來ProtectSystemstrict把文件系統(tǒng)設(shè)為只讀只有/opt/ipdb/data可讀這樣即使服務(wù)被攻破攻擊者也改不了系統(tǒng)文件。4.3 庫(kù)更新的熱加載方案IP庫(kù)不是一成不變的每個(gè)月都有新的網(wǎng)段分配和變更。更新的時(shí)候不能停服務(wù)得做熱加載。思路是新庫(kù)下載到臨時(shí)目錄校驗(yàn)通過后原子替換current目錄下的文件然后給服務(wù)發(fā)個(gè)信號(hào)讓它重新打開文件。Go服務(wù)這邊加一個(gè)信號(hào)處理import ( os os/signal syscall ) func main() { // ... 前面的代碼 sigCh : make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGHUP) go func() { for range sigCh { newDB, err : maxminddb.Open(*dbPath) if err ! nil { log.Printf(reload failed: %v, err) continue } oldDB : db db newDB oldDB.Close() log.Println(db reloaded) } }() // ... 啟動(dòng)HTTP服務(wù) }更新腳本大概長(zhǎng)這樣#!/bin/bash set -e NEW_DB/tmp/GeoLite2-City.mmdb CURRENT/opt/ipdb/data/current/GeoLite2-City.mmdb BACKUP/opt/ipdb/data/backup/GeoLite2-City-$(date %Y%m%d).mmdb # 下載新庫(kù)這里用wget示意實(shí)際按你的源來 wget -O $NEW_DB https://example.com/GeoLite2-City.mmdb # 校驗(yàn) mmdblookup --file $NEW_DB --ip 8.8.8.8 /dev/null # 備份舊庫(kù) cp $CURRENT $BACKUP # 原子替換 mv $NEW_DB $CURRENT chown ipdb:ipdb $CURRENT chmod 640 $CURRENT # 通知服務(wù)重載 systemctl reload ipdb注意mv在同一文件系統(tǒng)內(nèi)是原子操作所以/tmp和/opt如果在不同分區(qū)要先cp再mv否則替換過程中可能出現(xiàn)文件不完整的情況。5. 性能壓測(cè)與調(diào)優(yōu)實(shí)錄5.1 壓測(cè)工具與基準(zhǔn)數(shù)據(jù)服務(wù)跑起來之后得知道它能扛多少。壓測(cè)工具我用wrk比ab更輕量支持多線程。先裝一下apt-get install wrk然后寫個(gè)壓測(cè)腳本隨機(jī)生成IP去查# 生成測(cè)試IP列表 for i in $(seq 1 10000); do echo 8.8.$((RANDOM % 256)).$((RANDOM % 256)) done /tmp/ips.txt # 用wrk壓測(cè)需要配合lua腳本讀取IP wrk -t4 -c100 -d30s --latency -s lookup.lua http://127.0.0.1:8080lookup.lua的內(nèi)容local ips {} for line in io.lines(/tmp/ips.txt) do table.insert(ips, line) end request function() local ip ips[math.random(#ips)] return wrk.format(GET, /lookup?ip .. ip) end我實(shí)測(cè)的數(shù)據(jù)2核4G的機(jī)器100并發(fā)下QPS穩(wěn)定在35000左右P99延遲不到1毫秒。這個(gè)性能對(duì)絕大多數(shù)業(yè)務(wù)來說都綽綽有余了。5.2 瓶頸定位與優(yōu)化手段如果壓測(cè)數(shù)據(jù)不理想先別急著加機(jī)器按下面的順序排查。第一看CPU。用top -H看是不是某個(gè)核跑滿了。如果是說明查詢邏輯本身有優(yōu)化空間。MMDB查詢是純內(nèi)存操作理論上不應(yīng)該成為瓶頸。檢查一下是不是每次查詢都重新解析了IP字符串這個(gè)可以提前緩存。第二看內(nèi)存。用free -h看MMDB有沒有被換出。如果swap使用量在漲說明vm.swappiness沒調(diào)好或者內(nèi)存真的不夠。MMDB文件多大常駐內(nèi)存就至少多大。第三看網(wǎng)絡(luò)。雖然走的是回環(huán)但HTTP協(xié)議本身有開銷。如果QPS上不去可以試試換成Unix Domain Socket能省掉TCP握手和HTTP頭解析大概能提升20%到30%的吞吐。第四看文件描述符。ss -s看連接數(shù)如果接近ulimit -n就得往上調(diào)。提示壓測(cè)的時(shí)候別用127.0.0.1以外的地址否則測(cè)出來的是網(wǎng)卡性能不是服務(wù)性能。另外壓測(cè)機(jī)和被測(cè)服務(wù)別放同一臺(tái)機(jī)器會(huì)互相搶CPU。5.3 高可用與橫向擴(kuò)展單機(jī)服務(wù)總有掛的時(shí)候生產(chǎn)環(huán)境得考慮高可用。最簡(jiǎn)單的方案是雙機(jī)熱備兩臺(tái)機(jī)器都跑查詢服務(wù)前面掛一個(gè)本地的負(fù)載均衡比如nginx或者h(yuǎn)aproxy。業(yè)務(wù)方調(diào)127.0.0.1:80由負(fù)載均衡轉(zhuǎn)發(fā)到兩個(gè)后端。upstream ipdb { server 127.0.0.1:8080; server 127.0.0.1:8081; keepalive 64; } server { listen 127.0.0.1:80; location /lookup { proxy_pass http://ipdb; proxy_http_version 1.1; proxy_set_header Connection ; } }如果查詢量特別大單機(jī)扛不住那就得分片。按IP的第一段做哈希比如1.x.x.x走機(jī)器A2.x.x.x走機(jī)器B業(yè)務(wù)方根據(jù)IP自己路由。這種方式?jīng)]有中心節(jié)點(diǎn)擴(kuò)展性最好但業(yè)務(wù)方要改代碼。還有一種偷懶的做法是多進(jìn)程。Go服務(wù)本身是單進(jìn)程的但你可以起多個(gè)實(shí)例監(jiān)聽不同端口然后用SO_REUSEPORT讓內(nèi)核做負(fù)載均衡。Linux 3.9以上支持這個(gè)特性配置起來也簡(jiǎn)單import golang.org/x/sys/unix lc : net.ListenConfig{ Control: func(network, address string, c syscall.RawConn) error { return c.Control(func(fd uintptr) { unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1) }) }, } ln, _ : lc.Listen(context.Background(), tcp, 127.0.0.1:8080)這樣起4個(gè)進(jìn)程監(jiān)聽同一個(gè)端口內(nèi)核會(huì)自動(dòng)把連接分給不同的進(jìn)程充分利用多核。6. 常見問題與排查技巧6.1 查詢結(jié)果不準(zhǔn)怎么辦這是被問得最多的問題。IP歸屬地查詢本身就不是100%準(zhǔn)確的原因有幾個(gè)一是IP庫(kù)更新有延遲新分配的網(wǎng)段可能還沒收錄二是運(yùn)營(yíng)商動(dòng)態(tài)分配IP同一個(gè)IP在不同時(shí)間可能屬于不同地區(qū)三是企業(yè)專線和云服務(wù)商的IP注冊(cè)地和實(shí)際使用地經(jīng)常對(duì)不上。排查思路是這樣的先確認(rèn)你用的庫(kù)是不是最新的mmdblookup查一下這個(gè)IP在庫(kù)里有沒有記錄。如果沒有記錄那就是庫(kù)沒覆蓋到等更新或者換更全的庫(kù)。如果有記錄但結(jié)果不對(duì)那就是數(shù)據(jù)源本身的問題換商業(yè)庫(kù)可能能解決但也不保證100%。提示對(duì)于風(fēng)控場(chǎng)景別把IP歸屬地當(dāng)成唯一判斷依據(jù)。它只是一個(gè)弱信號(hào)要結(jié)合設(shè)備指紋、行為特征一起看。我見過太多因?yàn)镮P庫(kù)不準(zhǔn)導(dǎo)致誤殺的案例了。6.2 服務(wù)啟動(dòng)報(bào)錯(cuò)排查表報(bào)錯(cuò)信息可能原因解決方法open db failed: no such file路徑寫錯(cuò)或文件不存在檢查-db參數(shù)確認(rèn)文件在/opt/ipdb/data/current/下permission denied服務(wù)用戶沒有讀權(quán)限chown ipdb:ipdb并chmod 640address already in use端口被占用ss -tlnptoo many open files文件描述符不夠調(diào)大LimitNOFILE重啟服務(wù)lookup failed: invalid databaseMMDB文件損壞重新下載用mmdblookup校驗(yàn)6.3 內(nèi)存占用異常增長(zhǎng)正常情況下MMDB加載后內(nèi)存占用是穩(wěn)定的不會(huì)持續(xù)增長(zhǎng)。如果發(fā)現(xiàn)內(nèi)存一直漲大概率是內(nèi)存泄漏。Go服務(wù)雖然自帶GC但如果代碼里不斷創(chuàng)建大對(duì)象又不釋放也會(huì)出問題。排查方法是用pprofimport _ net/http/pprof // 在main里加 go func() { log.Println(http.ListenAndServe(127.0.0.1:6060, nil)) }()然后go tool pprof http://127.0.0.1:6060/debug/pprof/heap進(jìn)去之后用top命令看哪個(gè)函數(shù)占內(nèi)存最多。我遇到過一種情況是每次查詢都json.Marshal一個(gè)大的結(jié)構(gòu)體導(dǎo)致大量臨時(shí)對(duì)象。解決辦法是復(fù)用bytes.Buffer或者直接用json.Encoder寫到ResponseWriter。6.4 更新庫(kù)之后服務(wù)沒生效這個(gè)坑我踩過。更新腳本里mv替換了文件systemctl reload也發(fā)了信號(hào)但查詢結(jié)果還是舊的。原因有兩個(gè)一是systemd的reload默認(rèn)發(fā)的是SIGTERM不是SIGHUP需要在unit文件里指定[Service] ExecReload/bin/kill -HUP $MAINPID二是Go服務(wù)里db變量是全局的信號(hào)處理協(xié)程里改了db但HTTP處理函數(shù)讀的可能是舊的引用。解決辦法是用atomic.Value包一層var db atomic.Value // 加載 db.Store(newDB) // 查詢 reader : db.Load().(*maxminddb.Reader) reader.Lookup(ip, rec)這樣就能保證讀寫安全更新立即生效。6.5 日志太多把磁盤寫滿查詢服務(wù)如果每個(gè)請(qǐng)求都打日志一天下來幾個(gè)GB就沒了。生產(chǎn)環(huán)境建議只記錄錯(cuò)誤日志正常查詢不打。如果確實(shí)需要審計(jì)可以采樣記錄比如每1000次記一條。用logrotate做日志切割/opt/ipdb/logs/*.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate很重要因?yàn)镚o服務(wù)可能一直持有文件句柄直接mv會(huì)導(dǎo)致日志寫到舊文件里。7. 幾個(gè)容易被忽略的細(xì)節(jié)7.1 IPv6的支持現(xiàn)在IPv6越來越普及查詢服務(wù)必須支持。MMDB格式本身是支持IPv6的maxminddb-golang也能直接查。但要注意IPv6的查詢樹深度是128比IPv4的32深單次查詢會(huì)稍微慢一點(diǎn)不過還是在微秒級(jí)。如果你的業(yè)務(wù)暫時(shí)只處理IPv4可以在入口處把IPv6地址轉(zhuǎn)成IPv4映射地址但這不是長(zhǎng)久之計(jì)。建議直接支持反正代碼上沒什么額外成本。7.2 內(nèi)網(wǎng)IP的處理MMDB庫(kù)里通常不包含內(nèi)網(wǎng)網(wǎng)段10.0.0.0/8、172.16.0.0/12、192.168.0.0/16查詢這些IP會(huì)返回空。業(yè)務(wù)方拿到空結(jié)果可能會(huì)報(bào)錯(cuò)。解決辦法是在查詢服務(wù)里加一層判斷遇到內(nèi)網(wǎng)IP直接返回一個(gè)固定的標(biāo)記if ip.IsPrivate() { json.NewEncoder(w).Encode(map[string]string{type: private}) return }這樣業(yè)務(wù)方就能區(qū)分“查不到”和“內(nèi)網(wǎng)IP”兩種情況。7.3 時(shí)區(qū)與編碼問題城市名稱在MMDB里是多語(yǔ)言的names字段是個(gè)map鍵是語(yǔ)言代碼。默認(rèn)可能返回英文如果你需要中文得在查詢的時(shí)候指定type Record struct { City struct { Names map[string]string maxminddb:names } maxminddb:city } // 取中文 cityName : rec.City.Names[zh-CN] if cityName { cityName rec.City.Names[en] }注意不是所有城市都有中文翻譯取不到的時(shí)候要有個(gè)兜底。7.4 監(jiān)控指標(biāo)怎么埋生產(chǎn)服務(wù)沒有監(jiān)控就是裸奔。至少埋這幾個(gè)指標(biāo)QPS、P99延遲、錯(cuò)誤率、MMDB加載時(shí)間。用Prometheus的話加一個(gè)/metrics接口import github.com/prometheus/client_golang/prometheus/promhttp http.Handle(/metrics, promhttp.Handler())然后在查詢函數(shù)里打點(diǎn)var ( queryCount prometheus.NewCounter(prometheus.CounterOpts{ Name: ipdb_query_total, Help: Total queries, }) queryDuration prometheus.NewHistogram(prometheus.HistogramOpts{ Name: ipdb_query_duration_seconds, Buckets: []float64{0.0001, 0.0005, 0.001, 0.005, 0.01}, }) ) func init() { prometheus.MustRegister(queryCount, queryDuration) }這樣在Grafana上就能看到實(shí)時(shí)的查詢量和延遲分布出問題的時(shí)候一眼就能定位。7.5 庫(kù)更新的自動(dòng)化手動(dòng)更新庫(kù)容易忘建議做成定時(shí)任務(wù)。用cron每天凌晨跑一次更新腳本# 編輯 crontab crontab -e # 每天凌晨3點(diǎn)更新 0 3 * * * /opt/ipdb/scripts/update.sh /opt/ipdb/logs/update.log 21更新腳本里加上失敗重試和告警。如果連續(xù)三天更新失敗發(fā)個(gè)郵件或者釘釘通知。別等到庫(kù)過期半年了才發(fā)現(xiàn)。8. 寫在最后的一些個(gè)人體會(huì)這套方案我在三個(gè)項(xiàng)目里落地過最大的感受是私有化部署的門檻比想象中低但維護(hù)的細(xì)節(jié)比想象中多。裝個(gè)服務(wù)、跑個(gè)查詢半天就能搞定但要讓它穩(wěn)定跑一年不出問題得在監(jiān)控、更新、容災(zāi)上花不少心思。如果讓我給剛上手的朋友一個(gè)建議那就是先把單機(jī)跑通再考慮高可用。很多人一上來就搞集群、搞分片結(jié)果基礎(chǔ)服務(wù)都沒調(diào)穩(wěn)出了問題排查半天。先用一臺(tái)機(jī)器把查詢服務(wù)跑起來壓測(cè)看看性能確認(rèn)能滿足業(yè)務(wù)需求然后再逐步加監(jiān)控、加備份、加負(fù)載均衡。還有一個(gè)心得是別過度設(shè)計(jì)。IP查詢本身是個(gè)很簡(jiǎn)單的需求MMDB加一個(gè)HTTP服務(wù)就夠了。我見過有人用Elasticsearch存IP段做范圍查詢性能差不說維護(hù)成本還高。工具選型要匹配需求殺雞別用牛刀。最后說個(gè)實(shí)際的數(shù)據(jù)我這套方案在2核4G的機(jī)器上支撐了日均800萬(wàn)次查詢P99延遲0.8毫秒運(yùn)行半年零故障。成本是一年幾百塊的服務(wù)器費(fèi)用相比商業(yè)API省了90%以上。如果你也在為IP查詢的成本和合規(guī)發(fā)愁不妨試試這條路。