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

【關鍵詞】內存數據庫 故障預警 智能化故障處理

doi：10.3969/j.issn.1006-1010.2017.04.000 中圖分類號：TP399 文獻標志碼：A 文章編號：1006-1010（2017）04-0000-00

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

1 引言

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

2 內存數據庫簡介

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

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

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

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

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

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

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

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

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

3.1 智能處理方案的應用場景

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

3.2 模塊說明

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

圖2 內存數據庫故障智能處理方案主要構成模塊

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

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

（2）閾值設置

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

（3）智能判斷

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

（4）故障處理

故障處理模塊調用智能判斷模塊并進行故障處理的相關程序，這些程序根據特定的故障及處理過程編寫。

（5）實時預警

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

3.3 算法流程描述

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

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

圖3 整體處理流程

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

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

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

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

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

當前已經收集和整理了2個表象事件：

1）CPU使用率；

2）離線話單率。

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

根據當前表象事件，故障閾值的預設定如下：

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

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

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

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

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

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

4 實踐效果分析

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

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

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

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

5 結束語

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

參考文獻：

[1] 王珊，肖艷芹，劉大為，等. 內存數據庫關鍵技術研究[J]. 計算機應用， 2007，27（10）： 2353-2357.

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

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

[4] 哈索， 亞歷山大 蔡爾. 內存數據管理[M]. 2版. 北京： 清華大學出版社， 2012.

[5] 陸慧娟，徐展翼，高志剛，等. 嵌入式數據庫原理與應用[M]. 北京： 清華大學出版社， 2013.

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

[7] 楊武軍，張繼榮. 內存數據庫技術綜述[J]. 西安郵電學院學報， 2005，10（3）： 96-99.

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

[9] 楊艷，李煒，王純. 內存數據庫在高速緩存方面的應用[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.★