極驗目前的用戶超過7萬家網站，日均驗證量1億次，作為一家專註於驗證安全服務的公司，極驗所要面臨的併發壓力主要表現在以下幾點： 日益增加的用戶併發量。 驗證請求是全動態過程，不能夠進行緩存。 每一次請求都會造成資料庫的讀寫。 處理請求需要耗費CPU大量的時間進行模型的計算。 作為抗擊黑產的第一線，可能 ...
極驗目前的用戶超過7萬家網站，日均驗證量1億次，作為一家專註於驗證安全服務的公司，極驗所要面臨的併發壓力主要表現在以下幾點：
- 日益增加的用戶併發量。
- 驗證請求是全動態過程，不能夠進行緩存。
- 每一次請求都會造成資料庫的讀寫。
- 處理請求需要耗費CPU大量的時間進行模型的計算。
- 作為抗擊黑產的第一線，可能遭到黑產的攻擊。
- 代碼示例
但是對於極驗來說這樣的方式並不是那麼合適，存在著以下幾點極驗必須要考慮的問題。
- 使用代理使得整個結構多了一層不安全因素，一旦代理層出現問題，那麼後面的都無法正常運轉。
- 代理本身並不具備良好的擴展性，無法自動的進行分配，在運維上有一定的難度。
- 加入代理層也會使得整個結構的響應速度相應減慢。
客戶端通過一致性hash，寫入當前機器與hash環上的下一臺機器，實現數據冗餘。讀取時從當前機器讀取，失敗則從hash環上下一臺機器讀取。得益於相對簡單的結構，擴容、故障恢復速度會快得多，同時運維成本更低。
在高併發量的情況下，資料庫往往成為瓶頸，加上大量掛起等待的協程也會使得資料庫的性能大大降低。像極驗這樣每天有大量的驗證數據需要讀取，提升資料庫性能就顯得十分重要。我們的解決方案是進行嵌入式緩存，所有查詢完全遵循緩存中的數據，緩存定期與資料庫同步。同時緩存直接嵌入服務進程內，實現幾乎零開銷查詢。由於Python的GIL存在，我們利用mmap實現進程間共用記憶體。
我們在實現這個嵌入式緩存的過程中，完全按照我們業務中遇到的實際問題進行設計，所以可能對於其他業務不是很適用。具體來說，極驗的資料庫查詢主要有三種特性：1.數據幾乎只讀不寫，並且對於數據一致性要求不高。2.資料庫查詢開銷相對計算邏輯比重較大。3.介面併發數長期保持在較高水平，用傳統緩存方式的話一旦緩存被穿透(例如惡意偽造不存在的數據)系統將崩潰。基於上面三點特性，我們專門定製了最適合我們自己的緩存，並使得資料庫完全不再是系統的瓶頸。
提高計算性能
提高計算性能極驗主要採用以下兩種方式：
主要性能消耗在數據處理邏輯以及神經網路參數計算
- 利用Cython將計算密集代碼編譯成擴展模塊供Python調用
- 控制神經網路規模，同時優化計算效率
