一、概述

數據庫防火墻和一般的傳統數據庫安全設備不同，它部署在應用服務器和數據庫服務器之間。業務系統巨大的流量將穿越數據庫防火墻，數據庫防火墻任何的風吹草動都會影響業務系統的正常運行。數據庫防火墻投放市場之前，不管數據庫防火墻功能的多寡，都必須解決兩個基本問題：性能和可靠性。

[[234478]]

二、性能

性能主要考慮兩方面的影響：延遲和并發。

1. 延遲

延遲：業務操作從指令發出到結果返回之間消耗的時間。

一般來說，絕大部分客戶的OLTP(線上交易處理)業務要求秒級響應，這個秒級響應包含了所有的業務處理，包括：客戶端的處理(比如瀏覽器)延遲，業務網絡延遲，應用服務器處理延遲，數據庫網絡延遲，數據庫處理延遲等。對于數據庫防火墻來說，應用服務器處理延遲和數據庫處理延遲之間增加了一個數據庫防火墻處理延遲。

我們來看看一般OLTP系統的常規情況，數據庫網絡延遲一般1ms之內，數據庫處理延遲大部分在0.1ms-10ms之間，少部分會在10ms-100ms之間，極少出現幾百ms以上的延遲。

為了簡化說明，我們把數據庫網絡延遲標定為1ms，每次數據庫響應處理延遲時間標定為2ms，每筆業務平均由20條SQL語句構成，則每次延遲時間為3ms，每筆業務的響應時間為60ms，每秒鐘可以處理16.8筆業務。如果數據庫防火墻的處理延遲時間為1ms，則每次處理延遲增加為4ms，總處理時間增加為80ms，每秒鐘可以處理12.5筆業務。

下面我們從三種不同的業務場景來分析：獨占數據庫連接(無數據庫連接池)、數據庫連接池和短連接業務。大部分C/S應用都獨占數據庫連接，大部分B/S應用都采用數據庫連接池，短連接的應用非常少見，只出現在極少數據庫處理的應用中。

(1) 獨占數據庫連接

獨占數據庫連接應用中，數據庫防火墻的接入在每次處理中增加1ms，整體響應中增加了20ms，也就是從1000ms增加到了1020ms，這個延遲增量一般情況下不會對于業務體驗造成任何影響。

(2) 數據庫連接池

不同于獨占數據庫連接，數據庫連接池為不同業務操作的共享單元。假設數據庫連接池數量為200個，冗余20%，可用數量為160個。顯然，引進數據庫防火墻之后，業務處理能力從16.8 * 160 = 2688/s下降為12.5*160=2000/s，吞吐量下降25.6%。當你需要比較2000筆/s更高吞吐量的時候，數據庫防火墻的接入將帶來業務線的影響。在這種情況下，你需要把數據庫連接池數量至少增加26%，也就是252個，這個時候數據庫連接池的處理能力將恢復到2688筆/s，整體業務感知的影響也僅僅從1000ms增加到了1020ms，基本可以被忽略。

(3) 短連接業務

在短連接業務中，數據庫連接消耗的時間將納入業務響應時間。以Oracle數據庫為例子，一個數據庫連接的建立消耗時間在120ms-200ms，數據庫防火墻增加的每次1ms延遲和合計20ms延遲基本不會產生業務層面的影響。

(4) 數據庫響應處理的影響

在上面的討論中都假設了數據庫不會受到影響，但是事實上數據庫防火墻的加入會到數據庫處理產生影響，其影響等同于網絡速度下降。一般而言，延遲造成的影響主要在于增加了數據被鎖定的時間，從而會從根本上影響數據庫并發性。

我們以簡單的update為例子：

update customer set balance=500 where cust_id=10080;  
commit; 

可以看到cust_id=10080這一行的鎖定周期從3ms增加到了4ms，鎖定周期增加了33.3%，這個增加的鎖定時間會在一定時間影響數據庫的并發性。

2. 并發性

對于一個企業級數據庫，幾千甚至幾萬個數據庫連接是很常見的，數據庫防火墻需要在處理高并發量的同時保持延遲時間的穩定。在現實場景中，隨著業務并發程度的上升，響應時間下跌甚至于非線性下跌都是很常見的事情。我們在這里不討論如何實現高并發，只是說明并發性會嚴重影響響應延遲。

3. 性能延遲的可接受性

從上面計算可以看到，絕大部分的業務應用在數據庫防火墻增加1ms延遲時間不會對業務造成太大影響。對于高度并發性或者響應時間極為苛刻的業務應用，1ms延遲具有比較大的風險，需要更低延遲的數據庫防火墻支持，300us-500us的延遲是一個相對合理的數值。當然如果你的網絡環境甚至已經在多接入一個網絡交換機(延遲時間一般在100-300us)都會對業務造成明顯影響的時候，顯然增加數據庫防火墻接入是不合適的。

三、可靠性

性能是一個復雜的問題，可靠性對于數據庫防火墻來說就是一個極為簡單的命題。由于數據庫防火墻部署在應用服務器和數據庫服務器之間，數據庫防火墻的任何故障顯然會導致業務操作失敗，在數據庫防火墻無法工作的時候導致所有業務中斷。

相信任何用戶在安全和業務保障之間都會優先選擇業務保障而暫時放棄安全。基于這個考慮，一個很樸素的需求就是：在數據庫防火墻出現任何故障，包括軟件故障，硬件故障等，依然需要保障業務運行不要被中斷和影響。

1. bypass

當防火墻軟件或者硬件故障的時候，可以自適應降級成網絡通路設備，保證業務運行不會受到防火墻軟件或者硬件故障的影響。

2. 可靠性保持

數據庫網絡往往具有很高的冗余措施，數據庫防火墻的接入要求不會改變原有網絡的冗余結構，保持原有網絡的可靠性。

四、總結

數據庫防火墻商業化需要兩個基本前提：可以接受的性能和可靠性保障，在這兩個基本前提解決之前，任何數據庫防火墻產品都只能是實驗室產品而無法投放市場。

從性能的角度看，絕大部分情況下1ms以下的延遲都可以接受，對于高并發的復雜業務或者響應苛刻業務會需要更高的延遲性能，要求在500us以下。