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