騰訊雲TDSQL審計原理揭祕

版權聲明：本文由孫勇福原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/244

來源：騰雲閣 https://www.qcloud.com/community

 

做者簡介：孫勇福，騰訊雲高級工程師，負責騰訊雲TDSQL產品研發，畢業至今一直從事數據存儲系統運維和研發工做，在數據庫領域以及NoSQL領域具備豐富的運維和開發經驗。

開源數據庫每每不具有商業數據庫同樣的高端能力，可是卻因簡單易用，無需license費用等深得你們喜歡，但在雲服務時代，打造一款同時具有了開源數據庫的性價比和商業數據庫的安全性的數據庫，幾乎是全部使用者心中的夢想。騰訊雲數據庫TDSQL基於這樣的考慮，實現了雲化的審計能力，下面就讓咱們一塊兒來看看具體的技術細節。

產品架構

各模塊特色

1) proxy

• 三個無差異proxy Ip，保證一個或者兩個proxy 故障時，剩餘proxy Ip 正常工做用戶無感知。

• 旁路信息進入kafka時，對數據進行壓縮上傳同時kafka必須半數節點響應成功後纔算正確上傳。

• 每一個用戶實例都有本身單獨的proxy，在數據上傳是不一樣實例消息併發上傳到kafak的topic,保證每一個用戶信息及時進入審計消息隊列。

2) Kafka

• Kafka是一種分佈式的，基於發佈/訂閱的消息系統。主要設計目標以下：

• 以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間的訪問性能

• 高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條消息的傳輸

• 支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個partition內的消息順序傳輸

• 同時支持離線數據處理和實時數據處理

Kafka解析

Terminology

• Broker：Kafka集羣包含一個或多個服務器，這種服務器被稱爲broker

• Topic：每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲topic。（物理上不一樣topic的消息分開存儲，邏輯上一個topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的topic便可生產或消費數據而沒必要關心數據存於何處）

• Partition：parition是物理上的概念，每一個topic包含一個或多個partition，建立topic時可指定parition數量。每一個partition對應於一個文件夾，該文件夾下存儲該partition的數據和索引文件

• Producer：負責發佈消息到Kafka broker

• Consumer：消費消息。每一個consumer屬於一個特定的consumer group（可爲每一個consumer指定group name，若不指定group name則屬於默認的group）。使用consumer high level API時，同一topic的一條消息只能被同一個consumer group內的一個consumer消費，但多個consumer group可同時消費這一消息。

Kafka框架

如上圖所示，一個典型的kafka集羣中包含若干producer（能夠是web前端產生的page view，或者是服務器日誌，系統CPU、memory等），若干broker（Kafka支持水平擴展，通常broker數量越多，集羣吞吐率越高），若干consumer group，以及一個Zookeeper集羣。Kafka經過Zookeeper管理集羣配置，選舉leader，以及在consumer group發生變化時進行rebalance。producer使用push模式將消息發佈到broker，consumer使用pull模式從broker訂閱並消費消息。

3) audit-server

• audit-server 是分佈式服務，採用一致性hash算法進行路由
• 多協程併發處理模式保證kafka數據秒級別消費

一致性hash

在分佈式集羣中，對於機器的添加和刪除已經故障機器自動脫離集羣不影響服務是分佈式集羣的最基本的功能。本次審計服務採用一致性hash完成這種基本功能。

具體描述以下：按照經常使用的hash算法來將對應的key哈希到一個具備2^32次方個桶的空間中，即0~(2^32)-1的數字空間中，也就是將object1，object2, object3, object4 四個（假設有四個實例對象）實例對象經過hash 散列到hash環上。如圖（來自於網絡）

同時將三個服務節點（假設三個服務節點），經過hash也散列到hash環上。如圖（來自於網絡），經過找出距離本身最近的node節點，便可找到服務節點。

在服務節點添加刪除或故障時實例對象都會自動的調整找到距離本身最近的服務節點進行審計服務。

同時，在引入audit-server路由時，咱們發現node服務節點分佈越均勻，每一個服務節點的負載也就越均勻。這裏引用了虛擬節點來解決這一問題。

審計策略

• 獨立規則加載協程：在規則加載時，不影響審計規則功能區性能

• 優先級：策略支持用戶自定義優先級，在策略匹配時，優先匹配到優先級較高的策略。

• 規則設置豐富: 支持規則=, !=，>, >=, <, <= 以及正則匹配。

• 權限：支持二次認證，保證數據安全性。

多併發協程

• 協程，不須要搶佔式調度，能夠有效提升線程的任務併發性，而避免多線程的缺點（go原生支持）

故障優化

• 耦合關係：保證一個子系統發生故障時，不會影響其餘系統的正常運行。

• 審計服務故障時保障數據不丟：消息消費時會動態的記錄匹配到規則的或者超過必定閾值消息的offset，保證服務被分配到其餘節點或者故障服務修復啓動時都會從正確的位置消費消息。

• 數據旁路kafka數據不丟：在數據傳入到kafka是必須保證半數以上的節點響應此消息時，才進行下面的數據傳輸。

• 告警及時感知：kafka 或者MongoDB不可用時會秒級別感知，發送告警信息給系統負責人，及時恢復服務。

• 自動擴容：匹配規則消息存儲採用騰訊雲MongoDB，經過後臺打通，在存儲空間不夠時支持自動擴容。

• 數據順序性：每一個消息在旁路時都會被打上一個時間戳同時消息也是按順序進入消息隊列，在數據讀取時按照時間戳順序讀取。

3) 騰訊雲MongoDB

騰訊雲MongoDB特色

設計服務數據存儲採用，騰訊雲自有的MongoDB服務，該產品具有如下特色：

1. 雲存儲服務，是騰訊雲平臺提供的面向互聯網應用的數據存儲服務。

2. 提供了高性能、高可靠、易用、便捷的MongoDB集羣服務，每個實例都是至少一主一從的副本集或者包含多個副本集的分片集羣。

3. 整合了備份、擴容等功能，儘量的保證用戶數據安全以及動態伸縮能力

固然，爲了用戶的安全考慮，咱們全部的數據，都是須要用戶主動開啓審計的前提下，纔會記錄流水數據，並對數據進行過濾和存儲。

使用雲數據庫MongoDB服務的好處：

1. 安全：提供在線的至少兩份數據存儲，確保線上數據安全。同時經過備份機制保存多天的備份數據以便於在災難狀況進行數據恢復。

2. 高性能：集中安裝專用高性能存儲服務器（高內存全SSD機型）來支持海量訪問。 省心：提供7×24小時的專業服務，擴容和遷移對用戶透明且不影響服務。提供全面監控，可隨時掌控MongoDB服務質量。