基于內(nèi)存數(shù)據(jù)庫的智能化故障處理方法

【摘 要】為提高實時計費業(yè)務(wù)的時效性、穩(wěn)定性與連續(xù)性，設(shè)計、開發(fā)并實現(xiàn)了一套智能化故障處理方法。該方法基于內(nèi)存數(shù)據(jù)庫架構(gòu)與特性，提出了新故障處理的方案，實現(xiàn)了對故障監(jiān)控、預(yù)警和處理的智能化。通過數(shù)據(jù)對比顯示，該系統(tǒng)能夠顯著提高故障處理效率。

【關(guān)鍵詞】內(nèi)存數(shù)據(jù)庫 故障預(yù)警 智能化故障處理

doi：10.3969/j.issn.1006-1010.2017.04.000 中圖分類號：TP399 文獻(xiàn)標(biāo)志碼：A 文章編號：1006-1010（2017）04-0000-00

引用格式：周世超. 基于內(nèi)存數(shù)據(jù)庫的智能化故障處理方法[J]. 移動通信， 2017，41（4）： 00-00.

1 引言

數(shù)據(jù)庫負(fù)責(zé)數(shù)據(jù)的存儲與處理，在諸如通信行業(yè)實時計費業(yè)務(wù)等對實時性要求非常高的關(guān)鍵業(yè)務(wù)場景中，內(nèi)存數(shù)據(jù)庫以其高響應(yīng)速度、高并發(fā)、高吞吐量等優(yōu)秀特性正得到逐步推廣與大規(guī)模應(yīng)用。在利用內(nèi)存技術(shù)提升數(shù)據(jù)庫性能、提高業(yè)務(wù)系統(tǒng)實時響應(yīng)能力的同時，對于內(nèi)存數(shù)據(jù)庫運行穩(wěn)定性的要求同樣不斷提高，要求其在出現(xiàn)故障時能夠?qū)崿F(xiàn)快速定位與修復(fù)，提高業(yè)務(wù)的連續(xù)性。

2 內(nèi)存數(shù)據(jù)庫簡介

傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)把所有數(shù)據(jù)都放在磁盤上進(jìn)行管理，所以稱做磁盤數(shù)據(jù)庫。由于對磁盤讀寫數(shù)據(jù)的操作一方面要進(jìn)行磁頭的機械移動，另一方面受到系統(tǒng)調(diào)用時間的影響，當(dāng)數(shù)據(jù)量很大，操作頻繁且復(fù)雜時，就會暴露出很多問題。

內(nèi)存數(shù)據(jù)庫除對內(nèi)存讀寫比對磁盤讀寫快之外，還針對數(shù)據(jù)庫架構(gòu)與管理方式進(jìn)行了重新設(shè)計，目前幾種常見的通用內(nèi)存數(shù)據(jù)庫，例如Oracle公司的TimesTen，Altibase公司的Altibase，McObject公司的eXtremeDB，均屬于關(guān)系型內(nèi)存數(shù)據(jù)庫產(chǎn)品。以下針對兩種不同架構(gòu)的數(shù)據(jù)庫進(jìn)行對比說明。

傳統(tǒng)磁盤數(shù)據(jù)庫檢索的基本算法基于硬盤的讀寫，而內(nèi)存數(shù)據(jù)庫基于內(nèi)存實現(xiàn)。內(nèi)存數(shù)據(jù)庫拋棄了傳統(tǒng)的磁盤數(shù)據(jù)管理方式（如圖1所示），基于全部數(shù)據(jù)都加載到內(nèi)存的設(shè)計理念，對數(shù)據(jù)庫的體系結(jié)構(gòu)進(jìn)行重新設(shè)計，并且在數(shù)據(jù)組織結(jié)構(gòu)、索引技術(shù)、并行操作等方面也進(jìn)行了相應(yīng)的改進(jìn)，數(shù)據(jù)處理速度比傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)處理速度快，一般在10倍以上。通過采用內(nèi)存數(shù)據(jù)庫，可以極大地緩解傳統(tǒng)數(shù)據(jù)庫中大量的磁盤讀寫操作導(dǎo)致的I/O瓶頸。

當(dāng)前數(shù)據(jù)庫大多采用C/S（Client/Server，客戶機/服務(wù)器）模式的進(jìn)程間通信。傳統(tǒng)數(shù)據(jù)庫大多通過管道，本地IPC（Inter-Process Communication，進(jìn)程間通信）或遠(yuǎn)程Socket（網(wǎng)絡(luò)上的兩個程序通過一個雙向的通信連接實現(xiàn)數(shù)據(jù)的交換，連接的一端稱為一個Socket）形式的通信，在進(jìn)行批處理操作時需要處理大量的數(shù)據(jù)，性能消耗明顯。因此，在傳統(tǒng)場景下需要關(guān)注數(shù)據(jù)庫交互的往返次數(shù)。而在內(nèi)存數(shù)據(jù)庫產(chǎn)品中，大多采用直接共享內(nèi)存的方式，Client通過Driver直接讀取共享內(nèi)存，省去了通信開銷，幾乎無性能損耗。

從上述對比分析可知，內(nèi)存數(shù)據(jù)庫相對于傳統(tǒng)磁盤數(shù)據(jù)庫具有性能好、響應(yīng)速度快和處理速度快等優(yōu)勢，但在企業(yè)的實際應(yīng)用中，如果發(fā)生故障，這些優(yōu)勢將轉(zhuǎn)變?yōu)榱觿?。由于采用?nèi)存數(shù)據(jù)庫支撐的業(yè)務(wù)場景實時性要求很高，業(yè)務(wù)中斷對于客戶的感知影響非常大。例如，某省級通信運營商的實時計費系統(tǒng)使用ORACLE公司的TimesTen內(nèi)存數(shù)據(jù)庫，在業(yè)務(wù)試運行階段故障發(fā)生相對較多，但原廠家提供的配套故障診斷工具卻很少，出現(xiàn)問題之后需要人工排查處理，業(yè)務(wù)中斷時長在1小時左右，對于實時計費系統(tǒng)是不可接受的。

針對上述問題，該省級通信運營商通過分析與總結(jié)，制定出一套完善的智能化的故障處理方法。

3 智能故障處理方法原理及實現(xiàn)

對于企業(yè)的核心系統(tǒng)，監(jiān)控和預(yù)警體系配備相對完善，在故障發(fā)生時一般能夠及時通知運維人員，但運維人員接入系統(tǒng)后對故障原因的分析判斷環(huán)節(jié)將耗費較長的時間。

本文提出的智能化處理方案主要針對故障處理過程中耗費時間最長的故障原因診斷環(huán)節(jié)進(jìn)行優(yōu)化，通過智能判斷替代人工故障分析，解決故障處理瓶頸。通過預(yù)設(shè)方案進(jìn)行故障預(yù)處理，極大地縮短了故障處理的總時長，使業(yè)務(wù)連續(xù)性滿足SLA的要求，確保了該運營商實時計費系統(tǒng)上線后的穩(wěn)定運行。

3.1 智能處理方案的應(yīng)用場景

本文研究的內(nèi)存數(shù)據(jù)庫故障智能處理方案，是基于故障重復(fù)發(fā)生、表象一致、發(fā)生具有規(guī)律性，且表象能夠轉(zhuǎn)化成具體的業(yè)務(wù)或系統(tǒng)指標(biāo)的情況。根據(jù)這些指標(biāo)對不同故障有針對性地制定解決方案，做到故障發(fā)生時能夠智能判斷、自動處理。

3.2 模塊說明

本文所述的內(nèi)存數(shù)據(jù)庫故障智能處理方案，主要分為以下5個模塊，即事件監(jiān)控（故障監(jiān)控）、閾值設(shè)置、智能判斷、故障處理與實時預(yù)警，具體如圖2所示：

圖2 內(nèi)存數(shù)據(jù)庫故障智能處理方案主要構(gòu)成模塊

（1）事件監(jiān)控

事件監(jiān)控，即故障監(jiān)控，將各個獨立的故障現(xiàn)象轉(zhuǎn)化成事件，對事件實施監(jiān)控，并通過各種算法對業(yè)務(wù)、系統(tǒng)的運行信息進(jìn)行統(tǒng)計分析，轉(zhuǎn)化成可以識別的指標(biāo)。

（2）閾值設(shè)置

本模塊主要是根據(jù)事件監(jiān)控轉(zhuǎn)化而來的指標(biāo)信息，結(jié)合故障及過往積累的知識庫，預(yù)設(shè)指標(biāo)閾值，供智能判斷模塊進(jìn)行處理。該閾值可以根據(jù)實際情況進(jìn)行調(diào)整。

（3）智能判斷

智能判斷模塊根據(jù)事件監(jiān)控模塊獲取的指標(biāo)信息與閾值設(shè)置模塊設(shè)置的閾值進(jìn)行對比，并根據(jù)比對結(jié)果選擇不同的故障處理程序。

（4）故障處理

故障處理模塊調(diào)用智能判斷模塊并進(jìn)行故障處理的相關(guān)程序，這些程序根據(jù)特定的故障及處理過程編寫。

（5）實時預(yù)警

實時預(yù)警模塊是將整個智能處理過程的相關(guān)信息進(jìn)行實時展現(xiàn)與通知的模塊，主要將故障發(fā)生、智能處理過程信息、結(jié)果信息等發(fā)送給相關(guān)處理人員，便于跟蹤故障處理過程。

3.3 算法流程描述

各個故障表象在“事件監(jiān)控”環(huán)節(jié)被轉(zhuǎn)化為事件，并根據(jù)具體的業(yè)務(wù)算法、系統(tǒng)運行信息生成體現(xiàn)故障的具體指標(biāo)。“智能判斷”模塊會根據(jù)事件監(jiān)控模塊獲取的指標(biāo)信息與預(yù)設(shè)的閾值進(jìn)行對比，并根據(jù)對比的結(jié)果選擇相應(yīng)的故障處理程序，完成故障的智能處理。從“智能判斷”模塊開始，會將相關(guān)的處理信息通過“實時預(yù)警”模塊告知相關(guān)維護(hù)人員，從而便于維護(hù)人員跟進(jìn)故障的處理，并實時告知整個處理過程。

整體處理流程如圖3所示：

圖3 整體處理流程

3.4 智能處理方案的具體實現(xiàn)

下面以一個TimesTen內(nèi)存數(shù)據(jù)庫承載的實時計費系統(tǒng)故障為例進(jìn)行說明。該案例屬于數(shù)據(jù)庫統(tǒng)計信息異常引發(fā)的故障。由于實時計費系統(tǒng)的業(yè)務(wù)特性，在內(nèi)存數(shù)據(jù)庫中的統(tǒng)計信息與業(yè)務(wù)表的實際數(shù)據(jù)量偏差大于30%的情況下將會出現(xiàn)異常，繼而引發(fā)業(yè)務(wù)系統(tǒng)故障。

本案例共分為2個事件，第一個是CPU使用率，第二個是離線話單率，以下結(jié)合圖4來闡述具體的實現(xiàn)方法。

圖4 計費系統(tǒng)TimesTen統(tǒng)計信息異常故障智能預(yù)警流程

（1）將故障現(xiàn)象進(jìn)行分析、總結(jié)，并轉(zhuǎn)化成事件監(jiān)控。

當(dāng)前已經(jīng)收集和整理了2個表象事件：

1）CPU使用率；

2）離線話單率。

（2）將事件表象的故障閾值進(jìn)行預(yù)設(shè)定，并隨后續(xù)業(yè)務(wù)運行情況優(yōu)化調(diào)整。

根據(jù)當(dāng)前表象事件，故障閾值的預(yù)設(shè)定如下：

1）CPU使用率預(yù)設(shè)定為80%，業(yè)務(wù)運行正常的情況下，CPU使用率小于80%。

2）離線話單率預(yù)設(shè)定為10%，業(yè)務(wù)運行正常的情況下，離線話單率小于10%。

（3）根據(jù)事件故障的發(fā)生進(jìn)行第一次智能處理。如果CPU使用率或離線話單率超過了預(yù)設(shè)閾值，在未做其他系統(tǒng)變更的情況下，可以確定為中間臨時表，統(tǒng)計收集不準(zhǔn)引發(fā)故障。立即進(jìn)行中間臨時表統(tǒng)計信息收集，中間臨時表數(shù)據(jù)一般小于30萬行，故所需執(zhí)行時間較短，一般可在5分鐘之內(nèi)完成。

（4）完成了第一次智能處理5分鐘之后，再次對CPU使用率和離線話單率進(jìn)行統(tǒng)計分析。

（5）由于第一次處理只是完成了中間臨時表的統(tǒng)計收集，不排除業(yè)務(wù)突然對其他非臨時表做了大量的數(shù)據(jù)變更。因此，如果第一次處理后未能修復(fù)故障，則應(yīng)在此時立即實施全庫統(tǒng)計收集，進(jìn)行第二次的智能化處理。全庫統(tǒng)計收集一般會在30分鐘內(nèi)完成，但30分鐘的處理時長對于實時計費系統(tǒng)來說仍不可接受，因此需要立即發(fā)出預(yù)警，通知運維人員同步處理，縮短故障處理時間。

（6）在全庫統(tǒng)計收集完成之后，如果故障仍未解除，則可判斷故障由其他因素引發(fā)，必須由維護(hù)人員介入處理，此時需要再次發(fā)出告警，并提高告警級別。

4 實踐效果分析

通過該方案在實時計費系統(tǒng)運維中的應(yīng)用，減小了故障發(fā)生的頻率，并且使故障的解決時間基本控制在5分鐘之內(nèi)，相較于傳統(tǒng)的故障處理時長減少了5倍以上。上述實時計費系統(tǒng)沒有再次出現(xiàn)由于內(nèi)存數(shù)據(jù)庫統(tǒng)計信息異常等過往故障引發(fā)的長時間業(yè)務(wù)中斷。

通過不斷的運用、總結(jié)與完善，該方案的應(yīng)用使人力、物力及風(fēng)險方面都得到了很好的控制，有效提高了系統(tǒng)的可用性。

從圖5的分析結(jié)果可以看出，2010、2011年故障平均處理時長在25分鐘-30分鐘，2012年開始推行本文提出的處理方法并不斷完善以后，同類故障處理時長明顯下降。

圖5 2010-2015年內(nèi)存數(shù)據(jù)庫故障平均處理時長統(tǒng)計圖

5 結(jié)束語

本文以基于內(nèi)存數(shù)據(jù)庫的故障智能化處理方案應(yīng)用場景為例，介紹了該方案的實現(xiàn)原理以及處理流程，并針對方案涉及的核心功能模塊進(jìn)行了詳細(xì)闡述。通過分析一個基于TimesTen內(nèi)存數(shù)據(jù)庫的某實時計費系統(tǒng)運維實踐證明，采用該方案對業(yè)務(wù)系統(tǒng)的故障進(jìn)行實時監(jiān)控、智能判斷、自動處理能夠有效提高數(shù)據(jù)庫及業(yè)務(wù)系統(tǒng)的穩(wěn)定性與業(yè)務(wù)連續(xù)性。本文的解決方案也可應(yīng)用于其他內(nèi)存數(shù)據(jù)庫產(chǎn)品的故障處理，為故障處理從人工處理向自動化、智能化處理的思路轉(zhuǎn)變提供了參考。

參考文獻(xiàn)：

[1] 王珊，肖艷芹，劉大為，等. 內(nèi)存數(shù)據(jù)庫關(guān)鍵技術(shù)研究[J]. 計算機應(yīng)用， 2007，27（10）： 2353-2357.

[2] 蔡俠. 利用TimesTen內(nèi)存數(shù)據(jù)庫搭建高可用性的電信IT系統(tǒng)[J]. 福建電腦， 2012（6）： 134-136.

[3] 曾超宇，李金香. Redis在高速緩存系統(tǒng)中的應(yīng)用[J]. 微型機與用， 2013，32（12）： 11-13.

[4] 哈索， 亞歷山大 蔡爾. 內(nèi)存數(shù)據(jù)管理[M]. 2版. 北京： 清華大學(xué)出版社， 2012.

[5] 陸慧娟，徐展翼，高志剛，等. 嵌入式數(shù)據(jù)庫原理與應(yīng)用[M]. 北京： 清華大學(xué)出版社， 2013.

[6] 李國徽，楊進(jìn)才. 內(nèi)存數(shù)據(jù)庫查詢優(yōu)化[J]. 華中科技大學(xué)學(xué)報， 2003，31（4）： 21-23.

[7] 楊武軍，張繼榮. 內(nèi)存數(shù)據(jù)庫技術(shù)綜述[J]. 西安郵電學(xué)院學(xué)報， 2005，10（3）： 96-99.

[8] 劉云生，吳紹春. 一種實時內(nèi)存數(shù)據(jù)庫組織與管理方法[J]. 計算機研究與發(fā)展， 1998，35（5）： 469-473.

[9] 楊艷，李煒，王純. 內(nèi)存數(shù)據(jù)庫在高速緩存方面的應(yīng)用[J]. 現(xiàn)代電信科技， 2011，41（12）： 59-64.

[10] 甲骨文軟件系統(tǒng)有限公司. Oracle TimesTen In-Memory Database Documentation[EB/OL]. （2015-08-01）[2016-04-26]. http：//docs.oracle.com/cd/E21901_01/index.html.★