選擇KV資料庫最重要的是什麼
本文分享自華為雲社群《選擇KV資料庫最重要的是什麼？》，作者：GaussDB 資料庫 。
經常有客戶提到KV資料庫，但卻偏偏「不要Redis」。比如有個做安全威脅分析平臺的客戶，他們明確表示自己對可靠性要求非常高，需要的不是開源Redis這種記憶體快取庫，而是KV資料庫。
雖然最後我也沒問清楚他們業務存啥（推測是這塊業務資料比較機密），但確實業務本身對可靠性要求非常高，開源Redis自身的可靠性無法滿足他們的要求，最終該使用者選擇使用GaussDB(for Redis)資料庫，當前資料量已經是2TB規模，一直穩定執行中。
真正的KV資料庫，業界有好幾項開源的專案，雲廠商也紛紛推出自家產品，比如華為雲GaussDB(for Redis)。使用方在調研選型KV資料庫的時候，由於要儲存百GB甚至數十TB級的重要資料，首先關注的是資料庫是否穩定可靠，同時懂行的客戶一般也會聊到自建開源Redis的「不靠譜」問題，例如：
問題1：自建開源Redis有丟資料和資料不一致的風險
廣告競價和推薦等巨量資料業務將海量資料存放在KV資料庫，開源Redis是將全量資料存在記憶體中，雖然有RDB和AOF的備份機制，但那只是普通的文字檔案，可靠性很低，只能作為兜底手段，關鍵資料該丟還是會丟。
另外，開源Redis主備節點採用非同步複製的機制，故障倒換的時候有可能出現明顯的資料不一致，像是分散式鎖這類場景就會很尷尬：
問題2：「Cache+DB」的業務架構複雜
電商和遊戲等網際網路業務採用Redis快取+持久化資料庫的架構，通過快取加速來提升業務的使用體驗，業務需要設計快取的淘汰機制，還需要解決快取與持久化資料庫之間的資料一致性問題，業務架構複雜。
問題3：開源Redis分片故障不能提供服務，故障場景對業務影響比較大
金融、財經和電商等業務對可靠性要求極高，開源Redis單個資料分片存放在主備兩個節點上，如果兩個節點都出現故障，則整個分片的資料不可存取，應對極端故障場景的能力不足。
社群開源的專案一般都引入了RocksDB儲存引擎（這東西深的很），其實能把上層KV業務變得穩定許多，通過持久化儲存媒介替代記憶體的方式來彌補開源Redis的不足。但它們無法完美解決效能、相容性和擴容的問題，更無法保證資料庫的穩定可靠，還需要投入專門的人力進行搭建維護、調優等……最終綜合算下來，成本並不低。
雲廠商的KV資料庫由於進行了技術創新與優化，一般比較給力，以GaussDB(for Redis)為例，下面從以下幾個角度解釋如何把一款產品做到「靠譜」：
企業級特性1：採用記憶體+NVMe的儲存方案，全量資料三副本持久化儲存
GaussDB(for Redis)在儲存池中有三副本落盤到NVMe儲存池中，宕機不會丟資料，也不會存在主從同步的問題。因此，客戶可以直接拿GaussDB(for Redis)當做持久化資料庫使用，一庫頂多庫，業務架構變得簡單，也減輕了多套資料庫的運維成本。
企業級特性2：採用存算分離的架構，支援3AZ部署和N-1故障的超高可用
GaussDB(for Redis)支援3AZ部署計算節點，均勻分佈在3個不同的可用區，如果遇到1個或2個可用區出現網路、製冷、電力等突發故障，剩餘可用區的節點能接管故障節點的資料分片，還能繼續支撐業務存取全量資料。
同樣得益於存算分離的架構，GaussDB(for Redis)將全量資料落盤到分散式儲存池，最多支撐N-1故障，哪怕只剩下一個節點正常，也能通過接管所有分片，繼續支撐業務執行。
企業級特性3：雙活解決方案支援極致穩定可靠，靈活組網
如果遇到大規模網路故障、電力故障、火災或自然災害，導致整個資料庫範例不可用，甚至整個Region都不可用，GaussDB(for Redis)也在這些極端場景下保證業務的連續性。
GaussDB(for Redis)支援給兩個跨region的範例建立雙活關係，支援資料的同步，如果其中一個範例故障，另一個範例能接管業務，持續提供可靠的資料庫服務。雙活解決方案已在華為內部ERP中穩定部署執行，為ERP業務的持續執行提供強有力的保障。
總結
綜上所述，GaussDB(for Redis)提供了全量資料三副本持久化儲存，支援3AZ部署和N-1故障的超高可用，雙活解決方案支援極致穩定可靠，靈活組網，穩定性和可靠性遠超開源Redis，是一款真正能讓企業核心業務放心上雲的KV資料庫。
所以，如果你的業務需要一款穩定可靠的KV資料庫，可以試試GaussDB(for Redis)。