據(jù)服務(wù)從零搭建：四層架構(gòu)、冪等處理與存儲選型實(shí)戰(zhàn))
1. 金融數(shù)據(jù)服務(wù)從零搭建的完整思路1.1 這個(gè)項(xiàng)目到底在做什么第一次看到financial-services這個(gè)命名的時(shí)候我腦子里冒出來的第一個(gè)念頭是這又是一個(gè)什么都想裝進(jìn)去的大雜燴倉庫。但真正把這類項(xiàng)目拆開來看你會發(fā)現(xiàn)它其實(shí)解決的是一個(gè)非常具體、非常痛的問題——金融數(shù)據(jù)的獲取、清洗、存儲和對外服務(wù)這條鏈路在大多數(shù)團(tuán)隊(duì)里都是重復(fù)造輪子。我做過好幾個(gè)跟行情、賬戶、交易流水相關(guān)的系統(tǒng)每次最耗時(shí)的從來不是業(yè)務(wù)邏輯本身而是數(shù)據(jù)從哪來、格式怎么統(tǒng)一、接口怎么穩(wěn)定輸出這三件事。financial-services這類項(xiàng)目的核心價(jià)值就是把這套東西沉淀成一個(gè)可復(fù)用的服務(wù)層上游對接不同的數(shù)據(jù)源行情接口、數(shù)據(jù)庫、第三方文件中間做標(biāo)準(zhǔn)化處理下游以統(tǒng)一的 API 或 SDK 形式提供給業(yè)務(wù)方調(diào)用。它適合誰我的判斷是三類人一是中小團(tuán)隊(duì)里負(fù)責(zé)搭數(shù)據(jù)中臺的后端工程師二是做量化研究、需要穩(wěn)定數(shù)據(jù)管道的數(shù)據(jù)分析師三是想學(xué)習(xí)生產(chǎn)級金融系統(tǒng)怎么分層的進(jìn)階開發(fā)者。如果你只是寫個(gè)腳本拉兩天行情跑個(gè)回測那沒必要上這套但只要你開始面對多個(gè)策略共用同一份數(shù)據(jù)數(shù)據(jù)要保證一致性接口要被好幾個(gè)服務(wù)調(diào)用這些場景這套架構(gòu)的價(jià)值就出來了。1.2 為什么金融場景對架構(gòu)格外挑剔普通業(yè)務(wù)系統(tǒng)掛了用戶刷新一下頁面就過去了。金融系統(tǒng)掛了可能是真金白銀的損失或者更糟——數(shù)據(jù)錯(cuò)亂導(dǎo)致決策失誤。這就決定了financial-services這類項(xiàng)目在設(shè)計(jì)上有幾個(gè)繞不開的硬約束。第一是數(shù)據(jù)一致性。行情數(shù)據(jù)、賬戶余額、成交記錄這些數(shù)據(jù)之間存在強(qiáng)關(guān)聯(lián)。你不能出現(xiàn)成交記錄寫進(jìn)去了但賬戶余額沒扣這種中間狀態(tài)。所以這類項(xiàng)目幾乎必然要引入事務(wù)管理或者最終一致性補(bǔ)償機(jī)制而不是簡單地寫庫就完事。第二是時(shí)間敏感性。金融數(shù)據(jù)是有時(shí)效的一條延遲 5 秒的行情和一條實(shí)時(shí)的行情價(jià)值天差地別。這就要求整個(gè)鏈路從采集到輸出都要考慮延遲預(yù)算哪些環(huán)節(jié)可以異步、哪些必須同步得算清楚。第三是可追溯性。出了任何問題你得能回答這條數(shù)據(jù)是什么時(shí)候、從哪個(gè)源、經(jīng)過哪些處理變成現(xiàn)在這樣的。所以日志、審計(jì)、數(shù)據(jù)血緣這些東西不是可選項(xiàng)是必需品。我踩過最深的坑就是早期圖省事把行情采集和業(yè)務(wù)處理塞在同一個(gè)進(jìn)程里結(jié)果行情源一抖動整個(gè)業(yè)務(wù)接口全跟著超時(shí)。后來拆成獨(dú)立服務(wù)、加了緩沖隊(duì)列才穩(wěn)住。這個(gè)教訓(xùn)直接影響了后面我對financial-services這類項(xiàng)目的分層理解。1.3 整體分層設(shè)計(jì)四層結(jié)構(gòu)怎么切基于上面的約束我通常會把這類項(xiàng)目切成四層這也是我看過的大多數(shù)成熟實(shí)現(xiàn)共有的骨架。層級職責(zé)典型技術(shù)選型關(guān)鍵考量接入層對接外部數(shù)據(jù)源HTTP 客戶端、消息訂閱、文件解析容錯(cuò)、重試、限流處理層清洗、標(biāo)準(zhǔn)化、計(jì)算流處理框架、任務(wù)調(diào)度冪等、可重放存儲層持久化與緩存關(guān)系庫、時(shí)序庫、緩存一致性、查詢性能服務(wù)層對外提供 API/SDKWeb 框架、RPC穩(wěn)定、可觀測這四層不是拍腦袋分的每一層的邊界都對應(yīng)一個(gè)明確的變化原因。數(shù)據(jù)源變了只動接入層業(yè)務(wù)規(guī)則變了只動處理層查詢模式變了只動存儲層。這種單一變化原因的劃分是讓項(xiàng)目能長期維護(hù)的關(guān)鍵。提示分層不是越細(xì)越好。我見過把處理層再拆成五六個(gè)微服務(wù)的項(xiàng)目結(jié)果一個(gè)簡單的數(shù)據(jù)清洗要跨三個(gè)服務(wù)調(diào)用延遲翻倍、排查困難。分層的第一原則是夠用第二原則才是解耦。2. 核心模塊拆解與實(shí)操要點(diǎn)2.1 數(shù)據(jù)接入層把不穩(wěn)定的外部世界擋在門外接入層是整個(gè)系統(tǒng)的免疫系統(tǒng)它的核心任務(wù)不是把數(shù)據(jù)拿進(jìn)來而是在數(shù)據(jù)源各種抽風(fēng)的情況下依然把數(shù)據(jù)穩(wěn)定地拿進(jìn)來。這兩者的差別就是業(yè)余和專業(yè)的分水嶺。我處理接入層的標(biāo)準(zhǔn)動作有這么幾個(gè)。首先是連接池和超時(shí)控制任何外部調(diào)用都必須設(shè)超時(shí)而且超時(shí)時(shí)間要分層設(shè)置——連接超時(shí)短一點(diǎn)比如 2 秒讀取超時(shí)長一點(diǎn)比如 10 秒因?yàn)檫B接建立失敗通常意味著對方掛了而讀取慢可能只是數(shù)據(jù)量大。其次是重試策略但不是無腦重試要區(qū)分錯(cuò)誤類型網(wǎng)絡(luò)抖動可以重試參數(shù)錯(cuò)誤重試一萬次也沒用。# 接入層重試邏輯的典型寫法示意 import time import requests def fetch_with_retry(url, params, max_retries3, backoff_base0.5): last_error None for attempt in range(max_retries): try: resp requests.get(url, paramsparams, timeout(2, 10)) resp.raise_for_status() return resp.json() except requests.exceptions.Timeout as e: last_error e # 超時(shí)屬于可重試錯(cuò)誤指數(shù)退避 time.sleep(backoff_base * (2 ** attempt)) except requests.exceptions.HTTPError as e: # 4xx 是客戶端錯(cuò)誤重試無意義直接拋出 if 400 e.response.status_code 500: raise last_error e time.sleep(backoff_base * (2 ** attempt)) raise last_error這段代碼里有個(gè)細(xì)節(jié)值得說指數(shù)退避。為什么不用固定間隔重試因?yàn)槿绻麑Ψ椒?wù)過載了你固定間隔猛沖只會雪上加霜指數(shù)退避給了對方恢復(fù)的時(shí)間窗口。這個(gè)思路在分布式系統(tǒng)里是通用的。還有一個(gè)容易被忽略的點(diǎn)是數(shù)據(jù)源降級。當(dāng)主數(shù)據(jù)源不可用時(shí)能不能切到備用源備用源的數(shù)據(jù)格式可能不一樣這就需要接入層做一層適配。我一般會定義一個(gè)統(tǒng)一的內(nèi)部數(shù)據(jù)模型每個(gè)數(shù)據(jù)源寫一個(gè) adapter 把原始數(shù)據(jù)轉(zhuǎn)成這個(gè)模型這樣上層完全不用關(guān)心數(shù)據(jù)從哪來。2.2 數(shù)據(jù)處理層冪等是生命線處理層最容易出問題的地方不是邏輯寫錯(cuò)而是重復(fù)處理。消息隊(duì)列可能重復(fù)投遞任務(wù)調(diào)度可能重復(fù)觸發(fā)網(wǎng)絡(luò)重試可能導(dǎo)致同一批數(shù)據(jù)被處理兩次。如果處理邏輯不是冪等的結(jié)果就是數(shù)據(jù)翻倍、余額算錯(cuò)。冪等的實(shí)現(xiàn)方式有好幾種我按可靠性從低到高排一下。最簡單的是唯一鍵去重給每條數(shù)據(jù)算一個(gè)業(yè)務(wù)唯一 ID處理前先查有沒有處理過。這種方式實(shí)現(xiàn)簡單但每次都要查庫性能一般。進(jìn)階一點(diǎn)的是狀態(tài)機(jī)數(shù)據(jù)有明確的狀態(tài)流轉(zhuǎn)只有特定狀態(tài)才能觸發(fā)處理處理完?duì)顟B(tài)就變了重復(fù)消息自然被忽略。最穩(wěn)的是版本號或序列號每條數(shù)據(jù)帶一個(gè)單調(diào)遞增的版本處理時(shí)只接受比當(dāng)前版本大的數(shù)據(jù)。-- 用唯一約束實(shí)現(xiàn)冪等的典型表結(jié)構(gòu) CREATE TABLE processed_records ( record_id VARCHAR(64) PRIMARY KEY, processed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, payload_hash VARCHAR(64) ); -- 插入時(shí)如果沖突就忽略天然冪等 INSERT INTO processed_records (record_id, payload_hash) VALUES (?, ?) ON CONFLICT (record_id) DO NOTHING;注意冪等鍵的選擇很關(guān)鍵。用自增 ID 做冪等鍵基本沒用因?yàn)橹貜?fù)投遞的消息 ID 是一樣的但如果你用業(yè)務(wù)字段組合做鍵又可能誤傷合法的重復(fù)數(shù)據(jù)。我的經(jīng)驗(yàn)是優(yōu)先用數(shù)據(jù)源自帶的唯一標(biāo)識實(shí)在沒有再用業(yè)務(wù)字段的哈希。處理層還有一個(gè)繞不開的話題是批處理還是流處理。這個(gè)選擇取決于你的延遲要求。如果業(yè)務(wù)能接受分鐘級延遲批處理簡單可靠如果要秒級甚至毫秒級就得上流處理。我個(gè)人的建議是除非有明確的低延遲需求否則優(yōu)先批處理。流處理的復(fù)雜度、運(yùn)維成本、調(diào)試難度都高一個(gè)量級很多團(tuán)隊(duì)是被實(shí)時(shí)這個(gè)詞忽悠上去的結(jié)果發(fā)現(xiàn)業(yè)務(wù)根本用不到那么快。2.3 存儲層選型決定了一半的成敗存儲選型是financial-services這類項(xiàng)目里最需要想清楚的事因?yàn)橐坏┻x錯(cuò)后期遷移成本極高。我把常見的幾類數(shù)據(jù)和對應(yīng)用法整理一下。行情類時(shí)序數(shù)據(jù)特點(diǎn)是寫入量大、按時(shí)間查詢、很少更新。這類數(shù)據(jù)用專門的時(shí)序數(shù)據(jù)庫最合適壓縮率高、時(shí)間范圍查詢快。如果量不大用普通關(guān)系庫加時(shí)間索引也能扛。賬戶和交易類數(shù)據(jù)特點(diǎn)是強(qiáng)一致性要求、需要事務(wù)、數(shù)據(jù)量相對可控。這類必須用支持 ACID 的關(guān)系庫別想著用 NoSQL 圖省事后面一致性出問題會讓你懷疑人生。配置和元數(shù)據(jù)特點(diǎn)是讀多寫少、要求低延遲。放緩存里最合適配合持久化存儲做兜底。數(shù)據(jù)類型寫入特征查詢特征推薦存儲行情時(shí)序高頻寫入時(shí)間范圍查詢時(shí)序庫/關(guān)系庫分區(qū)賬戶交易中頻、需事務(wù)點(diǎn)查范圍查關(guān)系庫配置元數(shù)據(jù)低頻寫入高頻點(diǎn)查緩存關(guān)系庫日志審計(jì)高頻追加按條件檢索日志系統(tǒng)/列存這里有個(gè)實(shí)操經(jīng)驗(yàn)不要過早引入多種存儲。我見過一個(gè)項(xiàng)目同時(shí)用了關(guān)系庫、時(shí)序庫、緩存、搜索引擎四套存儲結(jié)果數(shù)據(jù)同步邏輯寫了一堆運(yùn)維復(fù)雜度爆炸。正確的做法是先用一套關(guān)系庫扛住等真的遇到性能瓶頸了再針對性地引入專用存儲。過早優(yōu)化是萬惡之源這話在存儲選型上尤其成立。2.4 服務(wù)層接口設(shè)計(jì)要面向被依賴服務(wù)層是別人直接接觸的部分它的設(shè)計(jì)質(zhì)量直接決定了這個(gè)項(xiàng)目好不好用。我評判一個(gè)金融數(shù)據(jù)服務(wù)接口好不好就看三點(diǎn)語義清晰、錯(cuò)誤可辨、版本可控。語義清晰指的是接口名和參數(shù)名要能自解釋。getData這種名字就是災(zāi)難getDailyClosingPrice才合格。錯(cuò)誤可辨指的是錯(cuò)誤碼要分類客戶端能根據(jù)錯(cuò)誤碼判斷是該重試、該改參數(shù)、還是該報(bào)警。版本可控指的是接口要有版本機(jī)制不能今天改個(gè)字段明天刪個(gè)參數(shù)把調(diào)用方搞崩潰。// 一個(gè)設(shè)計(jì)得比較規(guī)范的響應(yīng)結(jié)構(gòu) { code: OK, data: { symbol: EXAMPLE, closing_price: 123.45, trade_date: 2024-01-15 }, meta: { source: primary, latency_ms: 12, version: v2 } }注意meta里的source字段它告訴調(diào)用方這條數(shù)據(jù)來自主源還是降級源。這個(gè)信息在排查問題時(shí)極其有用——當(dāng)用戶反饋數(shù)據(jù)不對你第一眼就能看出是不是降級導(dǎo)致的。3. 完整實(shí)操流程與關(guān)鍵環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與依賴梳理動手之前先把環(huán)境理清楚。我一般會列一個(gè)清單避免做到一半發(fā)現(xiàn)缺東西。基礎(chǔ)環(huán)境方面需要一個(gè)運(yùn)行環(huán)境Python 3.10 或 Node 18 或 JDK 17看你的技術(shù)棧、一個(gè)關(guān)系數(shù)據(jù)庫PostgreSQL 是我的首選功能全、生態(tài)好、一個(gè)緩存Redis 夠用。如果要做流處理再加一個(gè)消息隊(duì)列。依賴管理上我強(qiáng)烈建議用鎖定版本的方式。金融系統(tǒng)最怕的就是昨天還好好的今天依賴自動升級就崩了。Python 用pip-tools或poetry鎖定Node 用package-lock.jsonJava 用dependencyManagement。這個(gè)習(xí)慣能幫你省掉無數(shù)個(gè)深夜排查的夜晚。# 以 Python 為例用 poetry 管理依賴 poetry init poetry add fastapi uvicorn sqlalchemy psycopg2-binary redis poetry add --group dev pytest pytest-asyncio poetry lockpoetry lock這一步生成的鎖文件一定要提交到版本庫這是保證任何機(jī)器上裝出來的依賴都一樣的關(guān)鍵。3.2 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)表結(jié)構(gòu)設(shè)計(jì)我遵循一個(gè)原則先想清楚查詢再設(shè)計(jì)表。因?yàn)榻鹑跀?shù)據(jù)的查詢模式相對固定圍繞查詢來設(shè)計(jì)能避免后期加索引加到手軟。以行情數(shù)據(jù)為例最常見的查詢是某標(biāo)的某時(shí)間段的收盤價(jià)。那么表結(jié)構(gòu)就應(yīng)該圍繞(symbol, trade_date)這個(gè)組合來組織。CREATE TABLE daily_quotes ( id BIGSERIAL PRIMARY KEY, symbol VARCHAR(32) NOT NULL, trade_date DATE NOT NULL, open_price NUMERIC(18, 6), high_price NUMERIC(18, 6), low_price NUMERIC(18, 6), close_price NUMERIC(18, 6), volume BIGINT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE (symbol, trade_date) ); CREATE INDEX idx_quotes_symbol_date ON daily_quotes (symbol, trade_date DESC);幾個(gè)細(xì)節(jié)說明一下。價(jià)格字段用NUMERIC(18, 6)而不是FLOAT因?yàn)楦↑c(diǎn)數(shù)有精度問題金融計(jì)算里這是大忌。UNIQUE (symbol, trade_date)約束保證了同一標(biāo)的同一天只有一條記錄天然防重復(fù)。索引按(symbol, trade_date DESC)建因?yàn)樽畛Ｒ姷牟樵兪悄硺?biāo)的最近的行情倒序索引能直接命中。提示金額字段的精度要根據(jù)業(yè)務(wù)定。股票價(jià)格 6 位小數(shù)夠用但如果是加密貨幣或者外匯可能需要 8 位甚至更多。定少了后期改表很痛苦定多了浪費(fèi)空間但問題不大所以寧可多留一點(diǎn)。3.3 數(shù)據(jù)采集任務(wù)的實(shí)現(xiàn)采集任務(wù)我通常做成可配置、可重入的形式?？膳渲弥傅氖遣杉男?biāo)的、什么頻率、從哪個(gè)源都通過配置控制而不是寫死在代碼里?？芍厝胫傅氖侨蝿?wù)中斷后能從中斷點(diǎn)繼續(xù)而不是從頭再來。# 采集任務(wù)的核心結(jié)構(gòu)示意 class QuoteCollector: def __init__(self, source_adapter, storage, config): self.source source_adapter self.storage storage self.config config def run(self, symbols, start_date, end_date): for symbol in symbols: # 查詢已采集的日期跳過已完成部分實(shí)現(xiàn)可重入 done_dates self.storage.get_collected_dates(symbol, start_date, end_date) pending_dates self._get_pending_dates(start_date, end_date, done_dates) for date in pending_dates: try: raw self.source.fetch(symbol, date) normalized self._normalize(raw) self.storage.upsert_quote(normalized) except Exception as e: self._log_failure(symbol, date, e) continue這里upsert_quote用的是插入或更新語義配合前面的唯一約束重復(fù)采集也不會產(chǎn)生臟數(shù)據(jù)。_log_failure把失敗記錄下來但不中斷整個(gè)任務(wù)因?yàn)橐粋€(gè)標(biāo)的某天數(shù)據(jù)缺失不應(yīng)該影響其他標(biāo)的的采集。3.4 對外接口的實(shí)現(xiàn)與限流接口實(shí)現(xiàn)本身不難難的是保護(hù)自己不被調(diào)用方打垮。金融數(shù)據(jù)接口經(jīng)常被多個(gè)下游高頻調(diào)用沒有限流的話一個(gè)寫錯(cuò)循環(huán)的下游就能把你的服務(wù)打掛。限流我一般用令牌桶算法實(shí)現(xiàn)簡單、效果穩(wěn)定。按調(diào)用方維度限流每個(gè)調(diào)用方分配一個(gè)獨(dú)立的桶。import time from threading import Lock class TokenBucket: def __init__(self, rate, capacity): self.rate rate # 每秒補(bǔ)充的令牌數(shù) self.capacity capacity # 桶容量 self.tokens capacity self.last_refill time.time() self.lock Lock() def allow(self, n1): with self.lock: now time.time() # 按經(jīng)過的時(shí)間補(bǔ)充令牌 elapsed now - self.last_refill self.tokens min(self.capacity, self.tokens elapsed * self.rate) self.last_refill now if self.tokens n: self.tokens - n return True return False參數(shù)怎么定rate根據(jù)調(diào)用方的正常用量上浮 20% 左右capacity設(shè)為rate的 2 到 3 倍允許一定的突發(fā)流量。這個(gè)配置不是拍腦袋而是基于正常用量 合理突發(fā)來算的。定太緊會誤傷正常調(diào)用定太松起不到保護(hù)作用。4. 常見問題與排查技巧實(shí)錄4.1 數(shù)據(jù)不一致的排查思路數(shù)據(jù)不一致是金融系統(tǒng)最頭疼的問題因?yàn)樗皇菆?bào)錯(cuò)而是悄悄錯(cuò)了。我排查這類問題的順序是這樣的。先確認(rèn)是不是真的不一致。有時(shí)候是緩存沒更新導(dǎo)致的看起來不一致清一下緩存就正常了。所以第一步永遠(yuǎn)是繞過緩存直接查庫。再確認(rèn)不一致的范圍。是個(gè)別記錄還是批量是某個(gè)時(shí)間段還是全量范圍能極大縮小排查方向。如果是個(gè)別記錄大概率是并發(fā)問題如果是批量可能是某個(gè)任務(wù)邏輯錯(cuò)了。最后回溯數(shù)據(jù)血緣。這條數(shù)據(jù)從哪個(gè)源來、經(jīng)過哪些處理、什么時(shí)候?qū)懭氲?。如果系統(tǒng)有完善的日志和審計(jì)這一步很快如果沒有那就只能靠復(fù)現(xiàn)了。這也是為什么我前面強(qiáng)調(diào)可追溯性——它平時(shí)看不出價(jià)值出問題時(shí)就是救命稻草?，F(xiàn)象可能原因排查動作個(gè)別記錄金額偏差并發(fā)更新丟失檢查是否有樂觀鎖/悲觀鎖批量數(shù)據(jù)缺失采集任務(wù)中斷查任務(wù)日志和失敗記錄數(shù)據(jù)延遲隊(duì)列積壓查隊(duì)列深度和處理速率重復(fù)數(shù)據(jù)冪等失效檢查唯一約束和冪等鍵4.2 性能瓶頸的定位方法性能問題我一般用從外到內(nèi)的方式定位。先看接口響應(yīng)時(shí)間如果接口慢再看是數(shù)據(jù)庫慢還是應(yīng)用邏輯慢。數(shù)據(jù)庫慢就查慢查詢?nèi)罩緫?yīng)用慢就做 profiling。有個(gè)經(jīng)驗(yàn)值得分享大部分性能問題不在代碼在數(shù)據(jù)庫。我遇到過太多次優(yōu)化了半天代碼最后發(fā)現(xiàn)是少了個(gè)索引。所以定位性能問題時(shí)先看數(shù)據(jù)庫的慢查詢往往能一擊命中。-- PostgreSQL 查慢查詢的常用方式 SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY mean_time DESC LIMIT 20;這個(gè)查詢能直接告訴你哪些 SQL 平均耗時(shí)最長比盲目猜測高效得多。前提是要先啟用pg_stat_statements擴(kuò)展。4.3 我踩過的幾個(gè)典型坑坑一時(shí)區(qū)問題。金融數(shù)據(jù)對時(shí)間極其敏感而時(shí)區(qū)是最容易被忽略的。我早期一個(gè)項(xiàng)目服務(wù)器用 UTC業(yè)務(wù)方以為是本地時(shí)間結(jié)果行情日期整體偏了一天。后來統(tǒng)一規(guī)定存儲一律用 UTC展示時(shí)再轉(zhuǎn)本地時(shí)區(qū)并且所有時(shí)間字段都帶時(shí)區(qū)信息?？佣↑c(diǎn)數(shù)精度。前面提過金額要用NUMERIC但我還是見過用FLOAT存價(jià)格的。結(jié)果就是 0.1 0.2 不等于 0.3 這種經(jīng)典問題在對賬時(shí)暴露出來。這個(gè)坑的教訓(xùn)是涉及金額和價(jià)格永遠(yuǎn)不要用浮點(diǎn)數(shù)?？尤卦囷L(fēng)暴。有次下游服務(wù)抖動我們的重試邏輯同時(shí)觸發(fā)瞬間把下游打得更掛。后來加了重試抖動jitter在退避時(shí)間上加一個(gè)隨機(jī)量避免所有請求同時(shí)重試。import random def backoff_with_jitter(attempt, base0.5, cap30): # 指數(shù)退避 隨機(jī)抖動避免重試風(fēng)暴 exp min(cap, base * (2 ** attempt)) return random.uniform(0, exp)這個(gè)小小的隨機(jī)量在分布式系統(tǒng)里能救命。它的原理是如果所有客戶端都按同樣的退避時(shí)間重試它們會在同一時(shí)刻再次涌向服務(wù)端形成周期性的沖擊。加抖動后重試時(shí)間被打散服務(wù)端壓力就平滑了。4.4 監(jiān)控與告警的落地建議監(jiān)控不是裝個(gè)工具就完事關(guān)鍵是監(jiān)控什么。金融數(shù)據(jù)服務(wù)我必監(jiān)控的指標(biāo)有這么幾類數(shù)據(jù)新鮮度最新數(shù)據(jù)的時(shí)間戳距今多久、采集成功率、接口延遲分位數(shù)、錯(cuò)誤率。其中數(shù)據(jù)新鮮度是最重要的因?yàn)樗艿谝粫r(shí)間發(fā)現(xiàn)數(shù)據(jù)斷了。我一般會設(shè)一個(gè)閾值比如行情數(shù)據(jù)超過 5 分鐘沒更新就告警。這個(gè)指標(biāo)比單純的服務(wù)存活有用得多——服務(wù)活著但數(shù)據(jù)不更新對業(yè)務(wù)來說和掛了沒區(qū)別。告警的粒度也要控制。我見過告警配得太細(xì)一天幾百條最后大家都麻木了真出問題反而沒人看。我的做法是分級告警P0 直接打電話P1 發(fā)消息P2 只記錄。只有真正需要立刻處理的問題才走 P0保證告警的含金量。5. 項(xiàng)目擴(kuò)展與長期維護(hù)的思考5.1 從單機(jī)到分布式的演進(jìn)路徑financial-services這類項(xiàng)目很少一上來就是分布式的通常是單機(jī)跑通了業(yè)務(wù)量上來了再演進(jìn)。我把演進(jìn)路徑分成三個(gè)階段每個(gè)階段解決不同的瓶頸。第一階段是單機(jī) 數(shù)據(jù)庫所有模塊跑在一個(gè)進(jìn)程里數(shù)據(jù)存一個(gè)庫。這個(gè)階段的目標(biāo)是跑通別想太多架構(gòu)。第二階段是讀寫分離 緩存當(dāng)查詢壓力大了加只讀副本和緩存扛讀流量。第三階段才是服務(wù)拆分把采集、處理、服務(wù)拆成獨(dú)立部署的單元。這個(gè)順序不能亂。我見過一上來就搞微服務(wù)的團(tuán)隊(duì)結(jié)果業(yè)務(wù)還沒跑通光運(yùn)維微服務(wù)就耗盡了精力。架構(gòu)要跟著瓶頸走而不是跟著潮流走。5.2 數(shù)據(jù)質(zhì)量的長效保障數(shù)據(jù)質(zhì)量不是靠一次性的清洗而是靠長效機(jī)制。我的做法是建立數(shù)據(jù)質(zhì)量規(guī)則庫把常見的校驗(yàn)規(guī)則沉淀下來每次數(shù)據(jù)入庫前自動跑一遍。常見的規(guī)則包括價(jià)格必須為正、最高價(jià)不低于最低價(jià)、成交量非負(fù)、日期不能是未來。這些規(guī)則看起來簡單但能攔住絕大多數(shù)明顯的錯(cuò)誤數(shù)據(jù)。規(guī)則庫的好處是新接入一個(gè)數(shù)據(jù)源時(shí)直接復(fù)用已有規(guī)則不用重新想。# 數(shù)據(jù)質(zhì)量校驗(yàn)的規(guī)則示例 def validate_quote(quote): errors [] if quote[close_price] 0: errors.append(close_price must be positive) if quote[high_price] quote[low_price]: errors.append(high_price cannot be lower than low_price) if quote[volume] 0: errors.append(volume cannot be negative) if quote[trade_date] date.today(): errors.append(trade_date cannot be in the future) return errors校驗(yàn)失敗的數(shù)據(jù)不是直接丟棄而是進(jìn)隔離區(qū)等人工確認(rèn)后再決定是修正還是丟棄。直接丟棄太粗暴可能丟掉的是數(shù)據(jù)源格式變化導(dǎo)致的批量問題。5.3 我個(gè)人在實(shí)際操作中的體會做了這么多金融數(shù)據(jù)相關(guān)的項(xiàng)目我最大的體會是這類系統(tǒng)的難點(diǎn)從來不在技術(shù)而在對業(yè)務(wù)的理解。技術(shù)方案網(wǎng)上都能查到但這個(gè)字段到底代表什么這個(gè)時(shí)間戳是交易所時(shí)間還是本地時(shí)間這個(gè)價(jià)格含不含手續(xù)費(fèi)這些只有深入業(yè)務(wù)才能搞清楚。我見過太多技術(shù)很漂亮但業(yè)務(wù)理解錯(cuò)位的系統(tǒng)最后都推倒重來了。所以我的建議是動手寫代碼之前先花時(shí)間把數(shù)據(jù)字典、業(yè)務(wù)規(guī)則、邊界情況搞清楚。這份前期投入會在后期以十倍百倍的方式回報(bào)你。另外一個(gè)小技巧給每個(gè)數(shù)據(jù)字段都寫清楚注釋和來源。這看起來是小事但當(dāng)項(xiàng)目交接或者半年后你自己回頭看時(shí)這些注釋就是救命的東西。金融數(shù)據(jù)的語義往往很微妙一個(gè)字段的含義搞錯(cuò)整個(gè)分析結(jié)果就全錯(cuò)了。最后再分享一個(gè)習(xí)慣定期做數(shù)據(jù)對賬。拿系統(tǒng)里的數(shù)據(jù)和權(quán)威來源對一遍看看有沒有偏差。這個(gè)動作能發(fā)現(xiàn)很多平時(shí)監(jiān)控發(fā)現(xiàn)不了的問題比如某個(gè)數(shù)據(jù)源悄悄改了格式、某個(gè)計(jì)算邏輯有累積誤差。對賬不需要很頻繁一周一次就夠但要堅(jiān)持。 金融數(shù)據(jù)服務(wù)從零搭建：四層架構(gòu)、冪等處理與存儲選型實(shí)戰(zhàn)
1. 金融數(shù)據(jù)服務(wù)從零搭建的完整思路1.1 這個(gè)項(xiàng)目到底在做什么第一次看到financial-services這個(gè)命名的時(shí)候我腦子里冒出來的第一個(gè)念頭是這又是一個(gè)什么都想裝進(jìn)去的大雜燴倉庫。但真正把這類項(xiàng)目拆開來看你會發(fā)現(xiàn)它其實(shí)解決的是一個(gè)非常具體、非常痛的問題——金融數(shù)據(jù)的獲取、清洗、存儲和對外服務(wù)這條鏈路在大多數(shù)團(tuán)隊(duì)里都是重復(fù)造輪子。我做過好幾個(gè)跟行情、賬戶、交易流水相關(guān)的系統(tǒng)每次最耗時(shí)的從來不是業(yè)務(wù)邏輯本身而是數(shù)據(jù)從哪來、格式怎么統(tǒng)一、接口怎么穩(wěn)定輸出這三件事。financial-services這類項(xiàng)目的核心價(jià)值就是把這套東西沉淀成一個(gè)可復(fù)用的服務(wù)層上游對接不同的數(shù)據(jù)源行情接口、數(shù)據(jù)庫、第三方文件中間做標(biāo)準(zhǔn)化處理下游以統(tǒng)一的 API 或 SDK 形式提供給業(yè)務(wù)方調(diào)用。它適合誰我的判斷是三類人一是中小團(tuán)隊(duì)里負(fù)責(zé)搭數(shù)據(jù)中臺的后端工程師二是做量化研究、需要穩(wěn)定數(shù)據(jù)管道的數(shù)據(jù)分析師三是想學(xué)習(xí)生產(chǎn)級金融系統(tǒng)怎么分層的進(jìn)階開發(fā)者。如果你只是寫個(gè)腳本拉兩天行情跑個(gè)回測那沒必要上這套但只要你開始面對多個(gè)策略共用同一份數(shù)據(jù)數(shù)據(jù)要保證一致性接口要被好幾個(gè)服務(wù)調(diào)用這些場景這套架構(gòu)的價(jià)值就出來了。1.2 為什么金融場景對架構(gòu)格外挑剔普通業(yè)務(wù)系統(tǒng)掛了用戶刷新一下頁面就過去了。金融系統(tǒng)掛了可能是真金白銀的損失或者更糟——數(shù)據(jù)錯(cuò)亂導(dǎo)致決策失誤。這就決定了financial-services這類項(xiàng)目在設(shè)計(jì)上有幾個(gè)繞不開的硬約束。第一是數(shù)據(jù)一致性。行情數(shù)據(jù)、賬戶余額、成交記錄這些數(shù)據(jù)之間存在強(qiáng)關(guān)聯(lián)。你不能出現(xiàn)成交記錄寫進(jìn)去了但賬戶余額沒扣這種中間狀態(tài)。所以這類項(xiàng)目幾乎必然要引入事務(wù)管理或者最終一致性補(bǔ)償機(jī)制而不是簡單地寫庫就完事。第二是時(shí)間敏感性。金融數(shù)據(jù)是有時(shí)效的一條延遲 5 秒的行情和一條實(shí)時(shí)的行情價(jià)值天差地別。這就要求整個(gè)鏈路從采集到輸出都要考慮延遲預(yù)算哪些環(huán)節(jié)可以異步、哪些必須同步得算清楚。第三是可追溯性。出了任何問題你得能回答這條數(shù)據(jù)是什么時(shí)候、從哪個(gè)源、經(jīng)過哪些處理變成現(xiàn)在這樣的。所以日志、審計(jì)、數(shù)據(jù)血緣這些東西不是可選項(xiàng)是必需品。我踩過最深的坑就是早期圖省事把行情采集和業(yè)務(wù)處理塞在同一個(gè)進(jìn)程里結(jié)果行情源一抖動整個(gè)業(yè)務(wù)接口全跟著超時(shí)。后來拆成獨(dú)立服務(wù)、加了緩沖隊(duì)列才穩(wěn)住。這個(gè)教訓(xùn)直接影響了后面我對financial-services這類項(xiàng)目的分層理解。1.3 整體分層設(shè)計(jì)四層結(jié)構(gòu)怎么切基于上面的約束我通常會把這類項(xiàng)目切成四層這也是我看過的大多數(shù)成熟實(shí)現(xiàn)共有的骨架。層級職責(zé)典型技術(shù)選型關(guān)鍵考量接入層對接外部數(shù)據(jù)源HTTP 客戶端、消息訂閱、文件解析容錯(cuò)、重試、限流處理層清洗、標(biāo)準(zhǔn)化、計(jì)算流處理框架、任務(wù)調(diào)度冪等、可重放存儲層持久化與緩存關(guān)系庫、時(shí)序庫、緩存一致性、查詢性能服務(wù)層對外提供 API/SDKWeb 框架、RPC穩(wěn)定、可觀測這四層不是拍腦袋分的每一層的邊界都對應(yīng)一個(gè)明確的變化原因。數(shù)據(jù)源變了只動接入層業(yè)務(wù)規(guī)則變了只動處理層查詢模式變了只動存儲層。這種單一變化原因的劃分是讓項(xiàng)目能長期維護(hù)的關(guān)鍵。提示分層不是越細(xì)越好。我見過把處理層再拆成五六個(gè)微服務(wù)的項(xiàng)目結(jié)果一個(gè)簡單的數(shù)據(jù)清洗要跨三個(gè)服務(wù)調(diào)用延遲翻倍、排查困難。分層的第一原則是夠用第二原則才是解耦。2. 核心模塊拆解與實(shí)操要點(diǎn)2.1 數(shù)據(jù)接入層把不穩(wěn)定的外部世界擋在門外接入層是整個(gè)系統(tǒng)的免疫系統(tǒng)它的核心任務(wù)不是把數(shù)據(jù)拿進(jìn)來而是在數(shù)據(jù)源各種抽風(fēng)的情況下依然把數(shù)據(jù)穩(wěn)定地拿進(jìn)來。這兩者的差別就是業(yè)余和專業(yè)的分水嶺。我處理接入層的標(biāo)準(zhǔn)動作有這么幾個(gè)。首先是連接池和超時(shí)控制任何外部調(diào)用都必須設(shè)超時(shí)而且超時(shí)時(shí)間要分層設(shè)置——連接超時(shí)短一點(diǎn)比如 2 秒讀取超時(shí)長一點(diǎn)比如 10 秒因?yàn)檫B接建立失敗通常意味著對方掛了而讀取慢可能只是數(shù)據(jù)量大。其次是重試策略但不是無腦重試要區(qū)分錯(cuò)誤類型網(wǎng)絡(luò)抖動可以重試參數(shù)錯(cuò)誤重試一萬次也沒用。# 接入層重試邏輯的典型寫法示意 import time import requests def fetch_with_retry(url, params, max_retries3, backoff_base0.5): last_error None for attempt in range(max_retries): try: resp requests.get(url, paramsparams, timeout(2, 10)) resp.raise_for_status() return resp.json() except requests.exceptions.Timeout as e: last_error e # 超時(shí)屬于可重試錯(cuò)誤指數(shù)退避 time.sleep(backoff_base * (2 ** attempt)) except requests.exceptions.HTTPError as e: # 4xx 是客戶端錯(cuò)誤重試無意義直接拋出 if 400 e.response.status_code 500: raise last_error e time.sleep(backoff_base * (2 ** attempt)) raise last_error這段代碼里有個(gè)細(xì)節(jié)值得說指數(shù)退避。為什么不用固定間隔重試因?yàn)槿绻麑Ψ椒?wù)過載了你固定間隔猛沖只會雪上加霜指數(shù)退避給了對方恢復(fù)的時(shí)間窗口。這個(gè)思路在分布式系統(tǒng)里是通用的。還有一個(gè)容易被忽略的點(diǎn)是數(shù)據(jù)源降級。當(dāng)主數(shù)據(jù)源不可用時(shí)能不能切到備用源備用源的數(shù)據(jù)格式可能不一樣這就需要接入層做一層適配。我一般會定義一個(gè)統(tǒng)一的內(nèi)部數(shù)據(jù)模型每個(gè)數(shù)據(jù)源寫一個(gè) adapter 把原始數(shù)據(jù)轉(zhuǎn)成這個(gè)模型這樣上層完全不用關(guān)心數(shù)據(jù)從哪來。2.2 數(shù)據(jù)處理層冪等是生命線處理層最容易出問題的地方不是邏輯寫錯(cuò)而是重復(fù)處理。消息隊(duì)列可能重復(fù)投遞任務(wù)調(diào)度可能重復(fù)觸發(fā)網(wǎng)絡(luò)重試可能導(dǎo)致同一批數(shù)據(jù)被處理兩次。如果處理邏輯不是冪等的結(jié)果就是數(shù)據(jù)翻倍、余額算錯(cuò)。冪等的實(shí)現(xiàn)方式有好幾種我按可靠性從低到高排一下。最簡單的是唯一鍵去重給每條數(shù)據(jù)算一個(gè)業(yè)務(wù)唯一 ID處理前先查有沒有處理過。這種方式實(shí)現(xiàn)簡單但每次都要查庫性能一般。進(jìn)階一點(diǎn)的是狀態(tài)機(jī)數(shù)據(jù)有明確的狀態(tài)流轉(zhuǎn)只有特定狀態(tài)才能觸發(fā)處理處理完?duì)顟B(tài)就變了重復(fù)消息自然被忽略。最穩(wěn)的是版本號或序列號每條數(shù)據(jù)帶一個(gè)單調(diào)遞增的版本處理時(shí)只接受比當(dāng)前版本大的數(shù)據(jù)。-- 用唯一約束實(shí)現(xiàn)冪等的典型表結(jié)構(gòu) CREATE TABLE processed_records ( record_id VARCHAR(64) PRIMARY KEY, processed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, payload_hash VARCHAR(64) ); -- 插入時(shí)如果沖突就忽略天然冪等 INSERT INTO processed_records (record_id, payload_hash) VALUES (?, ?) ON CONFLICT (record_id) DO NOTHING;注意冪等鍵的選擇很關(guān)鍵。用自增 ID 做冪等鍵基本沒用因?yàn)橹貜?fù)投遞的消息 ID 是一樣的但如果你用業(yè)務(wù)字段組合做鍵又可能誤傷合法的重復(fù)數(shù)據(jù)。我的經(jīng)驗(yàn)是優(yōu)先用數(shù)據(jù)源自帶的唯一標(biāo)識實(shí)在沒有再用業(yè)務(wù)字段的哈希。處理層還有一個(gè)繞不開的話題是批處理還是流處理。這個(gè)選擇取決于你的延遲要求。如果業(yè)務(wù)能接受分鐘級延遲批處理簡單可靠如果要秒級甚至毫秒級就得上流處理。我個(gè)人的建議是除非有明確的低延遲需求否則優(yōu)先批處理。流處理的復(fù)雜度、運(yùn)維成本、調(diào)試難度都高一個(gè)量級很多團(tuán)隊(duì)是被實(shí)時(shí)這個(gè)詞忽悠上去的結(jié)果發(fā)現(xiàn)業(yè)務(wù)根本用不到那么快。2.3 存儲層選型決定了一半的成敗存儲選型是financial-services這類項(xiàng)目里最需要想清楚的事因?yàn)橐坏┻x錯(cuò)后期遷移成本極高。我把常見的幾類數(shù)據(jù)和對應(yīng)用法整理一下。行情類時(shí)序數(shù)據(jù)特點(diǎn)是寫入量大、按時(shí)間查詢、很少更新。這類數(shù)據(jù)用專門的時(shí)序數(shù)據(jù)庫最合適壓縮率高、時(shí)間范圍查詢快。如果量不大用普通關(guān)系庫加時(shí)間索引也能扛。賬戶和交易類數(shù)據(jù)特點(diǎn)是強(qiáng)一致性要求、需要事務(wù)、數(shù)據(jù)量相對可控。這類必須用支持 ACID 的關(guān)系庫別想著用 NoSQL 圖省事后面一致性出問題會讓你懷疑人生。配置和元數(shù)據(jù)特點(diǎn)是讀多寫少、要求低延遲。放緩存里最合適配合持久化存儲做兜底。數(shù)據(jù)類型寫入特征查詢特征推薦存儲行情時(shí)序高頻寫入時(shí)間范圍查詢時(shí)序庫/關(guān)系庫分區(qū)賬戶交易中頻、需事務(wù)點(diǎn)查范圍查關(guān)系庫配置元數(shù)據(jù)低頻寫入高頻點(diǎn)查緩存關(guān)系庫日志審計(jì)高頻追加按條件檢索日志系統(tǒng)/列存這里有個(gè)實(shí)操經(jīng)驗(yàn)不要過早引入多種存儲。我見過一個(gè)項(xiàng)目同時(shí)用了關(guān)系庫、時(shí)序庫、緩存、搜索引擎四套存儲結(jié)果數(shù)據(jù)同步邏輯寫了一堆運(yùn)維復(fù)雜度爆炸。正確的做法是先用一套關(guān)系庫扛住等真的遇到性能瓶頸了再針對性地引入專用存儲。過早優(yōu)化是萬惡之源這話在存儲選型上尤其成立。2.4 服務(wù)層接口設(shè)計(jì)要面向被依賴服務(wù)層是別人直接接觸的部分它的設(shè)計(jì)質(zhì)量直接決定了這個(gè)項(xiàng)目好不好用。我評判一個(gè)金融數(shù)據(jù)服務(wù)接口好不好就看三點(diǎn)語義清晰、錯(cuò)誤可辨、版本可控。語義清晰指的是接口名和參數(shù)名要能自解釋。getData這種名字就是災(zāi)難getDailyClosingPrice才合格。錯(cuò)誤可辨指的是錯(cuò)誤碼要分類客戶端能根據(jù)錯(cuò)誤碼判斷是該重試、該改參數(shù)、還是該報(bào)警。版本可控指的是接口要有版本機(jī)制不能今天改個(gè)字段明天刪個(gè)參數(shù)把調(diào)用方搞崩潰。// 一個(gè)設(shè)計(jì)得比較規(guī)范的響應(yīng)結(jié)構(gòu) { code: OK, data: { symbol: EXAMPLE, closing_price: 123.45, trade_date: 2024-01-15 }, meta: { source: primary, latency_ms: 12, version: v2 } }注意meta里的source字段它告訴調(diào)用方這條數(shù)據(jù)來自主源還是降級源。這個(gè)信息在排查問題時(shí)極其有用——當(dāng)用戶反饋數(shù)據(jù)不對你第一眼就能看出是不是降級導(dǎo)致的。3. 完整實(shí)操流程與關(guān)鍵環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與依賴梳理動手之前先把環(huán)境理清楚。我一般會列一個(gè)清單避免做到一半發(fā)現(xiàn)缺東西。基礎(chǔ)環(huán)境方面需要一個(gè)運(yùn)行環(huán)境Python 3.10 或 Node 18 或 JDK 17看你的技術(shù)棧、一個(gè)關(guān)系數(shù)據(jù)庫PostgreSQL 是我的首選功能全、生態(tài)好、一個(gè)緩存Redis 夠用。如果要做流處理再加一個(gè)消息隊(duì)列。依賴管理上我強(qiáng)烈建議用鎖定版本的方式。金融系統(tǒng)最怕的就是昨天還好好的今天依賴自動升級就崩了。Python 用pip-tools或poetry鎖定Node 用package-lock.jsonJava 用dependencyManagement。這個(gè)習(xí)慣能幫你省掉無數(shù)個(gè)深夜排查的夜晚。# 以 Python 為例用 poetry 管理依賴 poetry init poetry add fastapi uvicorn sqlalchemy psycopg2-binary redis poetry add --group dev pytest pytest-asyncio poetry lockpoetry lock這一步生成的鎖文件一定要提交到版本庫這是保證任何機(jī)器上裝出來的依賴都一樣的關(guān)鍵。3.2 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)表結(jié)構(gòu)設(shè)計(jì)我遵循一個(gè)原則先想清楚查詢再設(shè)計(jì)表。因?yàn)榻鹑跀?shù)據(jù)的查詢模式相對固定圍繞查詢來設(shè)計(jì)能避免后期加索引加到手軟。以行情數(shù)據(jù)為例最常見的查詢是某標(biāo)的某時(shí)間段的收盤價(jià)。那么表結(jié)構(gòu)就應(yīng)該圍繞(symbol, trade_date)這個(gè)組合來組織。CREATE TABLE daily_quotes ( id BIGSERIAL PRIMARY KEY, symbol VARCHAR(32) NOT NULL, trade_date DATE NOT NULL, open_price NUMERIC(18, 6), high_price NUMERIC(18, 6), low_price NUMERIC(18, 6), close_price NUMERIC(18, 6), volume BIGINT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE (symbol, trade_date) ); CREATE INDEX idx_quotes_symbol_date ON daily_quotes (symbol, trade_date DESC);幾個(gè)細(xì)節(jié)說明一下。價(jià)格字段用NUMERIC(18, 6)而不是FLOAT因?yàn)楦↑c(diǎn)數(shù)有精度問題金融計(jì)算里這是大忌。UNIQUE (symbol, trade_date)約束保證了同一標(biāo)的同一天只有一條記錄天然防重復(fù)。索引按(symbol, trade_date DESC)建因?yàn)樽畛Ｒ姷牟樵兪悄硺?biāo)的最近的行情倒序索引能直接命中。提示金額字段的精度要根據(jù)業(yè)務(wù)定。股票價(jià)格 6 位小數(shù)夠用但如果是加密貨幣或者外匯可能需要 8 位甚至更多。定少了后期改表很痛苦定多了浪費(fèi)空間但問題不大所以寧可多留一點(diǎn)。3.3 數(shù)據(jù)采集任務(wù)的實(shí)現(xiàn)采集任務(wù)我通常做成可配置、可重入的形式?？膳渲弥傅氖遣杉男?biāo)的、什么頻率、從哪個(gè)源都通過配置控制而不是寫死在代碼里?？芍厝胫傅氖侨蝿?wù)中斷后能從中斷點(diǎn)繼續(xù)而不是從頭再來。# 采集任務(wù)的核心結(jié)構(gòu)示意 class QuoteCollector: def __init__(self, source_adapter, storage, config): self.source source_adapter self.storage storage self.config config def run(self, symbols, start_date, end_date): for symbol in symbols: # 查詢已采集的日期跳過已完成部分實(shí)現(xiàn)可重入 done_dates self.storage.get_collected_dates(symbol, start_date, end_date) pending_dates self._get_pending_dates(start_date, end_date, done_dates) for date in pending_dates: try: raw self.source.fetch(symbol, date) normalized self._normalize(raw) self.storage.upsert_quote(normalized) except Exception as e: self._log_failure(symbol, date, e) continue這里upsert_quote用的是插入或更新語義配合前面的唯一約束重復(fù)采集也不會產(chǎn)生臟數(shù)據(jù)。_log_failure把失敗記錄下來但不中斷整個(gè)任務(wù)因?yàn)橐粋€(gè)標(biāo)的某天數(shù)據(jù)缺失不應(yīng)該影響其他標(biāo)的的采集。3.4 對外接口的實(shí)現(xiàn)與限流接口實(shí)現(xiàn)本身不難難的是保護(hù)自己不被調(diào)用方打垮。金融數(shù)據(jù)接口經(jīng)常被多個(gè)下游高頻調(diào)用沒有限流的話一個(gè)寫錯(cuò)循環(huán)的下游就能把你的服務(wù)打掛。限流我一般用令牌桶算法實(shí)現(xiàn)簡單、效果穩(wěn)定。按調(diào)用方維度限流每個(gè)調(diào)用方分配一個(gè)獨(dú)立的桶。import time from threading import Lock class TokenBucket: def __init__(self, rate, capacity): self.rate rate # 每秒補(bǔ)充的令牌數(shù) self.capacity capacity # 桶容量 self.tokens capacity self.last_refill time.time() self.lock Lock() def allow(self, n1): with self.lock: now time.time() # 按經(jīng)過的時(shí)間補(bǔ)充令牌 elapsed now - self.last_refill self.tokens min(self.capacity, self.tokens elapsed * self.rate) self.last_refill now if self.tokens n: self.tokens - n return True return False參數(shù)怎么定rate根據(jù)調(diào)用方的正常用量上浮 20% 左右capacity設(shè)為rate的 2 到 3 倍允許一定的突發(fā)流量。這個(gè)配置不是拍腦袋而是基于正常用量 合理突發(fā)來算的。定太緊會誤傷正常調(diào)用定太松起不到保護(hù)作用。4. 常見問題與排查技巧實(shí)錄4.1 數(shù)據(jù)不一致的排查思路數(shù)據(jù)不一致是金融系統(tǒng)最頭疼的問題因?yàn)樗皇菆?bào)錯(cuò)而是悄悄錯(cuò)了。我排查這類問題的順序是這樣的。先確認(rèn)是不是真的不一致。有時(shí)候是緩存沒更新導(dǎo)致的看起來不一致清一下緩存就正常了。所以第一步永遠(yuǎn)是繞過緩存直接查庫。再確認(rèn)不一致的范圍。是個(gè)別記錄還是批量是某個(gè)時(shí)間段還是全量范圍能極大縮小排查方向。如果是個(gè)別記錄大概率是并發(fā)問題如果是批量可能是某個(gè)任務(wù)邏輯錯(cuò)了。最后回溯數(shù)據(jù)血緣。這條數(shù)據(jù)從哪個(gè)源來、經(jīng)過哪些處理、什么時(shí)候?qū)懭氲?。如果系統(tǒng)有完善的日志和審計(jì)這一步很快如果沒有那就只能靠復(fù)現(xiàn)了。這也是為什么我前面強(qiáng)調(diào)可追溯性——它平時(shí)看不出價(jià)值出問題時(shí)就是救命稻草?，F(xiàn)象可能原因排查動作個(gè)別記錄金額偏差并發(fā)更新丟失檢查是否有樂觀鎖/悲觀鎖批量數(shù)據(jù)缺失采集任務(wù)中斷查任務(wù)日志和失敗記錄數(shù)據(jù)延遲隊(duì)列積壓查隊(duì)列深度和處理速率重復(fù)數(shù)據(jù)冪等失效檢查唯一約束和冪等鍵4.2 性能瓶頸的定位方法性能問題我一般用從外到內(nèi)的方式定位。先看接口響應(yīng)時(shí)間如果接口慢再看是數(shù)據(jù)庫慢還是應(yīng)用邏輯慢。數(shù)據(jù)庫慢就查慢查詢?nèi)罩緫?yīng)用慢就做 profiling。有個(gè)經(jīng)驗(yàn)值得分享大部分性能問題不在代碼在數(shù)據(jù)庫。我遇到過太多次優(yōu)化了半天代碼最后發(fā)現(xiàn)是少了個(gè)索引。所以定位性能問題時(shí)先看數(shù)據(jù)庫的慢查詢往往能一擊命中。-- PostgreSQL 查慢查詢的常用方式 SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY mean_time DESC LIMIT 20;這個(gè)查詢能直接告訴你哪些 SQL 平均耗時(shí)最長比盲目猜測高效得多。前提是要先啟用pg_stat_statements擴(kuò)展。4.3 我踩過的幾個(gè)典型坑坑一時(shí)區(qū)問題。金融數(shù)據(jù)對時(shí)間極其敏感而時(shí)區(qū)是最容易被忽略的。我早期一個(gè)項(xiàng)目服務(wù)器用 UTC業(yè)務(wù)方以為是本地時(shí)間結(jié)果行情日期整體偏了一天。后來統(tǒng)一規(guī)定存儲一律用 UTC展示時(shí)再轉(zhuǎn)本地時(shí)區(qū)并且所有時(shí)間字段都帶時(shí)區(qū)信息?？佣↑c(diǎn)數(shù)精度。前面提過金額要用NUMERIC但我還是見過用FLOAT存價(jià)格的。結(jié)果就是 0.1 0.2 不等于 0.3 這種經(jīng)典問題在對賬時(shí)暴露出來。這個(gè)坑的教訓(xùn)是涉及金額和價(jià)格永遠(yuǎn)不要用浮點(diǎn)數(shù)?？尤卦囷L(fēng)暴。有次下游服務(wù)抖動我們的重試邏輯同時(shí)觸發(fā)瞬間把下游打得更掛。后來加了重試抖動jitter在退避時(shí)間上加一個(gè)隨機(jī)量避免所有請求同時(shí)重試。import random def backoff_with_jitter(attempt, base0.5, cap30): # 指數(shù)退避 隨機(jī)抖動避免重試風(fēng)暴 exp min(cap, base * (2 ** attempt)) return random.uniform(0, exp)這個(gè)小小的隨機(jī)量在分布式系統(tǒng)里能救命。它的原理是如果所有客戶端都按同樣的退避時(shí)間重試它們會在同一時(shí)刻再次涌向服務(wù)端形成周期性的沖擊。加抖動后重試時(shí)間被打散服務(wù)端壓力就平滑了。4.4 監(jiān)控與告警的落地建議監(jiān)控不是裝個(gè)工具就完事關(guān)鍵是監(jiān)控什么。金融數(shù)據(jù)服務(wù)我必監(jiān)控的指標(biāo)有這么幾類數(shù)據(jù)新鮮度最新數(shù)據(jù)的時(shí)間戳距今多久、采集成功率、接口延遲分位數(shù)、錯(cuò)誤率。其中數(shù)據(jù)新鮮度是最重要的因?yàn)樗艿谝粫r(shí)間發(fā)現(xiàn)數(shù)據(jù)斷了。我一般會設(shè)一個(gè)閾值比如行情數(shù)據(jù)超過 5 分鐘沒更新就告警。這個(gè)指標(biāo)比單純的服務(wù)存活有用得多——服務(wù)活著但數(shù)據(jù)不更新對業(yè)務(wù)來說和掛了沒區(qū)別。告警的粒度也要控制。我見過告警配得太細(xì)一天幾百條最后大家都麻木了真出問題反而沒人看。我的做法是分級告警P0 直接打電話P1 發(fā)消息P2 只記錄。只有真正需要立刻處理的問題才走 P0保證告警的含金量。5. 項(xiàng)目擴(kuò)展與長期維護(hù)的思考5.1 從單機(jī)到分布式的演進(jìn)路徑financial-services這類項(xiàng)目很少一上來就是分布式的通常是單機(jī)跑通了業(yè)務(wù)量上來了再演進(jìn)。我把演進(jìn)路徑分成三個(gè)階段每個(gè)階段解決不同的瓶頸。第一階段是單機(jī) 數(shù)據(jù)庫所有模塊跑在一個(gè)進(jìn)程里數(shù)據(jù)存一個(gè)庫。這個(gè)階段的目標(biāo)是跑通別想太多架構(gòu)。第二階段是讀寫分離 緩存當(dāng)查詢壓力大了加只讀副本和緩存扛讀流量。第三階段才是服務(wù)拆分把采集、處理、服務(wù)拆成獨(dú)立部署的單元。這個(gè)順序不能亂。我見過一上來就搞微服務(wù)的團(tuán)隊(duì)結(jié)果業(yè)務(wù)還沒跑通光運(yùn)維微服務(wù)就耗盡了精力。架構(gòu)要跟著瓶頸走而不是跟著潮流走。5.2 數(shù)據(jù)質(zhì)量的長效保障數(shù)據(jù)質(zhì)量不是靠一次性的清洗而是靠長效機(jī)制。我的做法是建立數(shù)據(jù)質(zhì)量規(guī)則庫把常見的校驗(yàn)規(guī)則沉淀下來每次數(shù)據(jù)入庫前自動跑一遍。常見的規(guī)則包括價(jià)格必須為正、最高價(jià)不低于最低價(jià)、成交量非負(fù)、日期不能是未來。這些規(guī)則看起來簡單但能攔住絕大多數(shù)明顯的錯(cuò)誤數(shù)據(jù)。規(guī)則庫的好處是新接入一個(gè)數(shù)據(jù)源時(shí)直接復(fù)用已有規(guī)則不用重新想。# 數(shù)據(jù)質(zhì)量校驗(yàn)的規(guī)則示例 def validate_quote(quote): errors [] if quote[close_price] 0: errors.append(close_price must be positive) if quote[high_price] quote[low_price]: errors.append(high_price cannot be lower than low_price) if quote[volume] 0: errors.append(volume cannot be negative) if quote[trade_date] date.today(): errors.append(trade_date cannot be in the future) return errors校驗(yàn)失敗的數(shù)據(jù)不是直接丟棄而是進(jìn)隔離區(qū)等人工確認(rèn)后再決定是修正還是丟棄。直接丟棄太粗暴可能丟掉的是數(shù)據(jù)源格式變化導(dǎo)致的批量問題。5.3 我個(gè)人在實(shí)際操作中的體會做了這么多金融數(shù)據(jù)相關(guān)的項(xiàng)目我最大的體會是這類系統(tǒng)的難點(diǎn)從來不在技術(shù)而在對業(yè)務(wù)的理解。技術(shù)方案網(wǎng)上都能查到但這個(gè)字段到底代表什么這個(gè)時(shí)間戳是交易所時(shí)間還是本地時(shí)間這個(gè)價(jià)格含不含手續(xù)費(fèi)這些只有深入業(yè)務(wù)才能搞清楚。我見過太多技術(shù)很漂亮但業(yè)務(wù)理解錯(cuò)位的系統(tǒng)最后都推倒重來了。所以我的建議是動手寫代碼之前先花時(shí)間把數(shù)據(jù)字典、業(yè)務(wù)規(guī)則、邊界情況搞清楚。這份前期投入會在后期以十倍百倍的方式回報(bào)你。另外一個(gè)小技巧給每個(gè)數(shù)據(jù)字段都寫清楚注釋和來源。這看起來是小事但當(dāng)項(xiàng)目交接或者半年后你自己回頭看時(shí)這些注釋就是救命的東西。金融數(shù)據(jù)的語義往往很微妙一個(gè)字段的含義搞錯(cuò)整個(gè)分析結(jié)果就全錯(cuò)了。最后再分享一個(gè)習(xí)慣定期做數(shù)據(jù)對賬。拿系統(tǒng)里的數(shù)據(jù)和權(quán)威來源對一遍看看有沒有偏差。這個(gè)動作能發(fā)現(xiàn)很多平時(shí)監(jiān)控發(fā)現(xiàn)不了的問題比如某個(gè)數(shù)據(jù)源悄悄改了格式、某個(gè)計(jì)算邏輯有累積誤差。對賬不需要很頻繁一周一次就夠但要堅(jiān)持。