【摘 要】為提高實(shí)時(shí)計(jì)費(fèi)業(yè)務(wù)的時(shí)效性、穩(wěn)定性與連續(xù)性，設(shè)計(jì)、開發(fā)并實(shí)現(xiàn)了一套智能化故障處理方法。該方法基于內(nèi)存數(shù)據(jù)庫架構(gòu)與特性，提出了新故障處理的方案，實(shí)現(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è)實(shí)時(shí)計(jì)費(fèi)業(yè)務(wù)等對實(shí)時(shí)性要求非常高的關(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)實(shí)時(shí)響應(yīng)能力的同時(shí)，對于內(nèi)存數(shù)據(jù)庫運(yùn)行穩(wěn)定性的要求同樣不斷提高，要求其在出現(xiàn)故障時(shí)能夠?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)行磁頭的機(jī)械移動，另一方面受到系統(tǒng)調(diào)用時(shí)間的影響，當(dāng)數(shù)據(jù)量很大，操作頻繁且復(fù)雜時(shí)，就會暴露出很多問題。

內(nèi)存數(shù)據(jù)庫除對內(nèi)存讀寫比對磁盤讀寫快之外，還針對數(shù)據(jù)庫架構(gòu)與管理方式進(jìn)行了重新設(shè)計(jì)，目前幾種常見的通用內(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)存實(shí)現(xiàn)。內(nèi)存數(shù)據(jù)庫拋棄了傳統(tǒng)的磁盤數(shù)據(jù)管理方式（如圖1所示），基于全部數(shù)據(jù)都加載到內(nèi)存的設(shè)計(jì)理念，對數(shù)據(jù)庫的體系結(jié)構(gòu)進(jìn)行重新設(shè)計(jì)，并且在數(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，客戶機(jī)/服務(wù)器）模式的進(jìn)程間通信。傳統(tǒng)數(shù)據(jù)庫大多通過管道，本地IPC（Inter-Process Communication，進(jìn)程間通信）或遠(yuǎn)程Socket（網(wǎng)絡(luò)上的兩個程序通過一個雙向的通信連接實(shí)現(xiàn)數(shù)據(jù)的交換，連接的一端稱為一個Socket）形式的通信，在進(jìn)行批處理操作時(shí)需要處理大量的數(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è)的實(shí)際應(yīng)用中，如果發(fā)生故障，這些優(yōu)勢將轉(zhuǎn)變?yōu)榱觿?。由于采用?nèi)存數(shù)據(jù)庫支撐的業(yè)務(wù)場景實(shí)時(shí)性要求很高，業(yè)務(wù)中斷對于客戶的感知影響非常大。例如，某省級通信運(yùn)營商的實(shí)時(shí)計(jì)費(fèi)系統(tǒng)使用ORACLE公司的TimesTen內(nèi)存數(shù)據(jù)庫，在業(yè)務(wù)試運(yùn)行階段故障發(fā)生相對較多，但原廠家提供的配套故障診斷工具卻很少，出現(xiàn)問題之后需要人工排查處理，業(yè)務(wù)中斷時(shí)長在1小時(shí)左右，對于實(shí)時(shí)計(jì)費(fèi)系統(tǒng)是不可接受的。

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

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

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

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

3.2 模塊說明

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

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

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

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

（2）閾值設(shè)置

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

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

3.3 算法流程描述

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

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

圖3 整體處理流程

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

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

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

圖4 計(jì)費(fèi)系統(tǒng)TimesTen統(tǒng)計(jì)信息異常故障智能預(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ùn)行情況優(yōu)化調(diào)整。

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

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

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

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

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

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

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

4 實(shí)踐效果分析

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

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

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

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

5 結(jié)束語

本文以基于內(nèi)存數(shù)據(jù)庫的故障智能化處理方案應(yīng)用場景為例，介紹了該方案的實(shí)現(xiàn)原理以及處理流程，并針對方案涉及的核心功能模塊進(jìn)行了詳細(xì)闡述。通過分析一個基于TimesTen內(nèi)存數(shù)據(jù)庫的某實(shí)時(shí)計(jì)費(fèi)系統(tǒng)運(yùn)維實(shí)踐證明，采用該方案對業(yè)務(wù)系統(tǒng)的故障進(jìn)行實(shí)時(shí)監(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]. 計(jì)算機(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]. 微型機(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é)報(bào)， 2003，31（4）： 21-23.

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

[8] 劉云生，吳紹春. 一種實(shí)時(shí)內(nèi)存數(shù)據(jù)庫組織與管理方法[J]. 計(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.★