本申請涉及計算機領域，尤其涉及一種用于修復數據庫備庫數據的技術。
背景技術：
：隨著數據庫技術的迅猛發(fā)展，數據庫的應用十分廣泛，深入到各個領域。在數據庫系統中，無論是出于容災還是讀寫分離等目的，往往對一個數據庫實例主庫建立備庫，而由于主機宕機、備庫不慎被設置為可寫、數據庫設計本身缺陷或人為操作失當等原因，可能造成主庫和其備庫的數據不一致。目前，為了對不一致的數據片段進行修復，許多用戶都有自己的修復方法，一些廠商也提供了用于修復的腳本工具，例如，比對主庫與備庫的數據塊(chunk)中每一行，對找到的主備不一致的行，采用插入數據列表中(repalceinto)語句，在主庫執(zhí)行一遍用以生成該行全量的執(zhí)行日志(binlog)，并同步到備庫，這會以主庫數據為基準來修復備庫，對于主庫有的行而備庫沒有的行，采用替代(replace)在主庫上插入，對于備庫有而主庫沒有的行，通過在主庫執(zhí)行刪除，直到修復該數據塊所有不一致的行。一方面，在整個數據塊的修復過程中，需要持有數據塊的加鎖(forupdate鎖)，備庫的延遲越大，主庫加鎖時間越長，對線上影響就越大。在云計算場景下，面對的是大量的不知具體業(yè)務場景及使用習慣的用戶，如采用此工具，會帶來難以彌補的失誤。另一方面，還會存在以下風險：如果數據出現亂碼，這一修復動作將可能無法完成修復，甚至會修錯數據；被修復的表必須有唯一主鍵，否則會無法準確定位被修復的行，這可能造成修復對象錯誤，表現為替代(replaceinto)錯誤數據或者刪除(delete)錯誤數據，這樣的錯誤是不可挽回的。此外，在云計算情況下，現有腳本工具進行的修復，一旦主備關系發(fā)生變化，會直接導致數據源錯誤。技術實現要素：本申請的目的是提供一種用于修復數據庫備庫數據的方法與設備，要解決的技術問題是在云計算場景下不暫停用戶業(yè)務時如何精準安全地修復用戶數據的問題。根據本申請的一個方面，提供了一種用于修復數據庫備庫數據的方法，包括：實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處理；實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作；請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理；獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。根據本申請的另一方面，還提供了一種用于修復數據庫備庫數據的設備，包括：加鎖裝置，用于實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處理；備庫停止裝置，用于實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作；解鎖裝置，用于請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理；修復裝置，用于獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。與現有技術相比，根據本申請的實施例所述方法及設備，當所述主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息一致時，即實現主備第 一次等同步，對所述主庫進行可讀不可寫的加鎖處理；接著，所述備庫的執(zhí)行日志位點信息達到所述主庫在完成加鎖處理時執(zhí)行日志位點信息時，即實現主備第二次等同步，停止所述備庫從所述主庫進行的復制工作；隨后，請求所述主庫備份待修復數據，此時備份的數據正是所述備庫所需數據，在所述待修復數據備份完成后，對所述主庫進行解鎖處理，用戶可以正常寫入數據；獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，按數據塊或數據文件修復，無需對數據進行逐行分析，就可以完成修復，之后，開啟所述備庫從所述主庫進行的復制工作。修復過程控制在數秒內，對線上業(yè)務的影響小，主備兩次等同步使在修復的位點上修復了所需修復的數據，達到精確修復的效果；進一步地，記錄對所述主庫進行可讀不可寫加鎖處理的已加鎖時間，當所述已加鎖時間超過設定超時時間時，停止當前修復操作，不會存在半修復半不修復的情況，達到修復安全的目的。附圖說明通過閱讀參照以下附圖所作的對非限制性實施例所作的詳細描述，本申請的其它特征、目的和優(yōu)點將會變得更明顯：圖1示出根據本申請一個方面的一種用于修復數據庫備庫數據的設備結構示意圖；圖2示出根據本申請一個方面的一個優(yōu)選實施例的修復數據庫備庫數據的流程示意圖；圖3示出根據本申請一個方面的又一個優(yōu)選實施例的修復裝置14的結構示意圖；圖4示出根據本申請又一個方面的一種用于修復數據庫備庫數據的方法流程示意圖；圖5示出根據本申請又一個方面的一個優(yōu)選實施例中步驟S14的方法流程示意圖。附圖中相同或相似的附圖標記代表相同或相似的部件。具體實施方式下面結合附圖對本申請作進一步詳細描述。圖1示出根據本申請一個方面的一種用于修復數據庫備庫數據的設備結構示意圖。該設備包括加鎖裝置11、備庫停止裝置12、解鎖裝置13和修復裝置14。其中，加鎖裝置11用于實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處理；備庫停止裝置12實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作；解鎖裝置13請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理；修復裝置14獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。在此，所述設備1包括但不限于用戶設備、或用戶設備與網絡設備通過網絡相集成所構成的設備。所述用戶設備其包括但不限于任何一種可與用戶通過觸摸板進行人機交互的移動電子產品，例如智能手機、PDA等，所述移動電子產品可以采用任意操作系統，如android操作系統、iOS操作系統等。其中，所述網絡設備包括一種能夠按照事先設定或存儲的指令，自動進行數值計算和信息處理的電子設備，其硬件包括但不限于微處理器、專用集成電路(ASIC)、可編程門陣列(FPGA)、數字處理器(DSP)、嵌入式設備等。所述網絡包括但不限于互聯網、廣域網、城域網、局域網、VPN網絡、無線自組織網絡(AdHoc網絡)等。優(yōu)選地，設備1還可以是運行于所述用戶設備、或用戶設備與網絡設備、觸摸終端或網絡設備與觸摸終端通過網絡相集成所構成的設備上的腳本程序，其中，設備1可以是獨立于主庫設備和備庫設備的第三方設備、也可以是運行于主庫設備、備庫設備，或部分運行于主庫設備并部分運行于備庫設備。當然，本領域技術人員應能理解上述設備1僅為舉例，其他現有的或今后可能出現的設備1如可適用于本申請，也應包含在本申請保護范圍以內，并在此以引用方式包含于此。數據庫系統中，為解決單點問題，同時為了實現數據實例負載均衡，往往建立一個主庫及建立一個或多個對主庫進行復制的備庫，只有主庫可 以寫入，備庫只可以進行讀取。主從復制原理往往是通過備庫復制主庫的執(zhí)行日志(binlog)再進行執(zhí)行來完成的。對于復制關系，各種數據庫產品都有各自的實現方法，以mysql(一種關系型數據庫管理系統)為例，mysql主庫在事務提交時寫執(zhí)行日志，并通過同步執(zhí)行日志(sync_binlog)參數來控制執(zhí)行日志刷新到磁盤“落地”，而備庫通過輸入輸出(io)線程從主庫讀取執(zhí)行日志，并記錄到本地的中繼日志(relaylog)中，由本地的sql(結構化查詢語言)線程再將中繼日志的數據應用到本地數據庫。數據庫為了效率等原因，數據只保存在內存中，沒有真正的寫入到磁盤上去。如果數據庫響應為“提交成功”，但是由于數據庫掛掉，操作系統，數據庫主機等任何問題導致這次“提交成功”的事務對數據庫的修改沒有生效，那么我們認為這個事務的數據丟失了。對于銀行業(yè)務或者金融業(yè)務等數據一致性要求高的場景來說是不能接受的，所以，保證數據不丟失也是數據庫選擇的一個重要衡量標準。為了保證數據不丟失以及主備間數據的一致性，各類數據庫系統都做了大量的工作，但是在實際使用過程中，在數據可靠性和使用效率上往往要做一個權衡，這就給主備數據不一致的產生創(chuàng)造了可能性，另外，由于雙寫、日志文件損壞等因素，即使運行在完全高可靠的工作模式，仍有可能造成主備間數據不一致。本申請一實施例所述設備1用于修復數據庫備庫數據，由于主備庫兩次等同步后對主庫短暫的加鎖，通過停止備庫，主庫內待修復數據的備份及備庫獲取已備份好的數據進行修復數據，按數據塊或數據文件修復，無需對數據進行逐行分析，就可以完成修復。修復過程控制在數秒內，在云計算場景下，可以不暫停業(yè)務就可以修復數據，主備兩次等同步使在修復的位點上修復了所需修復的數據，達到精確修復的效果；進一步地，對主庫加鎖時有超時控制，當時間超過設定的超時時間，停止當前修復操作，不會存在半修復半不修復的情況，達到修復安全的目的。需要說明的是，一個主庫對應一個或多個備庫，主庫和備庫可以分布在同一設備上，可以分布在不同設備上。具體地，加鎖裝置11用于實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處 理。在此，等同步為主庫的執(zhí)行日志位點信息和對應的備庫的執(zhí)行日志位點信息一致，實時比較主備庫的位點信息實現第一次等同步，即實時將獲取的主庫的執(zhí)行日志位點信息與獲取的備庫的執(zhí)行日志的位點信息進行比較，若一致，則為主備第一次等同步；當主備第一次等同步后，主備庫位于同一位點，對主庫進行加鎖處理使用戶短時間內不可寫入，加鎖時間可為數秒，短暫時間內對線上業(yè)務影響極小，此時利用中間層阻塞用戶的結構化查詢語言。主庫的加鎖動作有超時控制，控制方式是通過另開線程等待該超時時間，時間到將放棄加鎖動作，并放棄本次修復。具體地，備庫停止裝置12實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作。在一具體實施例中，以mysql為例，可在主庫中通過命令顯示主庫執(zhí)行日志文件的狀態(tài)信息(showmasterstatus)獲取到主庫當前位點信息，再等待備庫復制到該位點，主備庫在實現第一次等同步后的極短時間內可實現第二次等同步，此時主庫的數據為備庫修復數據所需的，將備庫停止是指停止備庫從主庫進行復制，備庫停止后能夠獲取到備庫所需的數據，且能在相應的修復位點上進行修復。具體地，解鎖裝置13請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理。接前例，備庫停止后，主庫進行備份待修復數據，在此，待修復數據是指備庫所需的修復數據塊或數據文件對應的相應數據，將待修復的數據塊或數據文件在主庫進行本地備份，備份時間極短，因此此時主庫的加鎖超時尚未到，對主庫進行解鎖處理可以使用戶可以正常寫入。具體地，修復裝置14獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。在一優(yōu)選實施例中，主庫備份數據后，將本地備份的數據上傳到中轉站，備庫從中轉站中下載相應的數據塊覆蓋到備庫或進行數據文件覆蓋。按照數據塊或數據文件進行修復避免了對數據進行逐行分析的問題，完成修復后開 啟備庫從主庫進行的復制工作，主備之間開始正常復制。圖2示出根據本申請一個方面的一個優(yōu)選實施例的修復數據庫備庫數據的流程示意圖。其中的標號1-10為流程圖的順序，Master為所述主庫，Slave為其對應的備庫。流程為：加鎖裝置11在主備第一次等同步后對主庫加鎖；接著，備庫停止裝置12在主備第二次等同步后停止備庫；隨后，解鎖裝置13在主庫備份數據后將主庫解鎖；最后，修復裝置14將主庫中的已備份數據上傳中轉站，備庫從中轉站中下載進行修復數據，修復數據完成后將備庫開啟。在此，數據庫的引擎可分為兩種，一種為不支持事務的，一種為支持事務的，在此，對于不支持事務類型的，其每個表有單獨的數據文件和索引文件，進行修復時最安全的方式為數據文件的覆蓋，對于支持事務類型的，支持事務及行級鎖。因此，對于不支持事務的引擎，安全修復方式為進行數據文件的覆蓋，對于支持事務的引擎，在一個事務里用兩個執(zhí)行語句(包括刪除數據塊和導入備份的數據)可以進行修復。以下為針對兩種引擎類型進行修復數據庫備份數據的優(yōu)選實施例進行說明修復流程。針對所述數據庫的數據引擎類型為不支持事務類型的，本申請所述設備1中的解鎖裝置13包括備份單元，如圖3示出，所述設備1中的所述修復裝置14包括：鎖表單元141、獲取單元142、解鎖單元143和修復表單元144；其中，所述備份單元131請求所述主庫備份所述待修復數據的數據文件和索引文件；所述鎖表單元141對所述備庫進行鎖表處理；獲取單元142獲取從所述主庫中所備份的待修復數據；解鎖單元143對所述備庫進行解鎖處理；修復表單元144基于所述待修復數據進行修復表操作。進一步地，在所述設備1中，所述解鎖裝置13包括：備份單元，用于請求所述主庫備份所述待修復數據的數據文件和索引文件。在此，對于數據庫的數據引擎類型為不支持事務類型，每個表有單獨的數據文件和索引文件，進行修復時最安全的方式為數據文件的覆蓋，因此主庫進行備份數據時為備份所述待修復數據的數據文件和索引文件。需要說明的是，Myisam引擎有自帶的附加修復(repairtable)動作，在主庫備份時備份待修復數據的數據文件，備庫執(zhí)行附加修復(repairtable)動作重建被修復 數據的索引數據。具體地，在所述設備1中，所述修復裝置14包括：鎖表單元141對所述備庫進行鎖表處理；獲取單元142獲取從所述主庫中所備份的待修復數據；解鎖單元143對所述備庫進行解鎖處理；修復表單元144基于所述待修復數據進行修復表操作。例如，Mysiam引擎為不支持事務，對主庫進行加鎖時表現為鎖表，即直接鎖定整張表，修復過程中主庫中待修復數據備份并將所備份的數據上傳到中轉站中后，因Mysiam引擎的修復過程中對備庫執(zhí)行了附加修復(repairtable)動作，為防止用戶或數據庫管理員(dba)進行附加修復(repairtable)動作從而影響修復，需對備庫進行鎖表操作。因備庫從主庫中的復制過程已停止，備庫若要獲取主庫中所備份的待修復數據可通過先將主庫中已備份好的數據上傳到中轉站，然后備庫再從中轉站下載備份數據。備庫獲取備份的待修復數據后對備庫進行解鎖，備庫執(zhí)行附加修復(repairtable)動作，重建被修復數據的索引數據等，保證備庫中原有的數據文件被完全覆蓋，獲得新的正確的數據文件。需要說明的是，Myisam引擎能夠執(zhí)行附加修復(repairtable)動作，主庫備份時只需備份數據文件，備庫執(zhí)行附加修復動作時能夠重建索引文件，對于其它不帶附加修復動作的不支持事務的引擎，主庫備份時備份數據文件和索引文件，備庫利用獲取已備份好的數據文件和索引文件進行文件覆蓋實現表的修復。進一步地，例如，Myisam引擎不支持事務，在Myisam表中每個被存在分離的文件中，Myisam為表級鎖，直接鎖定整張表，在鎖定期間，其它進程無法對該表進行寫操作。此外，針對Myisam進行修復的前期工作流程為：首先檢查是否需要修復，包括檢查主備庫的地址(ip)、端口(port)的關系來確定主備切換機制沒有改變，檢查主備的數據庫文件(db)、數據列表(table)的存在性，以確定某個數據庫中的某個文檔及其相應的表都是完整的，以及檢查主備庫的數據引擎的變化等確定是否需要修復；若需要數據修復則在主備的同步狀態(tài)下將主庫中的數據塊和備庫中相應的數據塊進行比對，檢查是否一致，若不一致則關閉主備切換功能(HA)，停止容災，防止修復過程中主備關系發(fā)生變化，如一個主庫對應多個備庫，在修復過程中，主庫與備庫A關系發(fā)生變化，備庫A已被備庫B替換，主庫執(zhí)行的sql 會執(zhí)行到備庫B中，造成備庫B中數據錯誤；接著，在主備的同步狀態(tài)下檢查是否已經修復，若未修復則對備庫執(zhí)行附加修復(repairtable)動作，對于能夠用repairtable修復的數據可以避免進行鎖表才能修復，需說明的是，附加修復(repairtable)動作只是僅對mysql的Myisam引擎的附加動作，其他的數據庫中沒有這一動作。完成備庫的修復表操作后實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，進行后續(xù)的修復流程。如前例，以Myisam引擎為例的數據庫備庫數據的修復流程為本申請的一優(yōu)選實施例，首先，檢查主備庫的地址(ip)、端口(port)的關系，數據庫文件(db)、數據列表(table)的存在性，以及數據引擎的變化等；當檢查沒問題時在主備庫的復制達到同一位點的狀態(tài)下從主庫獲取不一致的數據塊進行直接比對，若比對結果為不一致則關閉主備切換功能，在主備庫的復制達到同一位點的狀態(tài)下檢查主備間數據是否一致，若不一致，對于Myisam則需要對備庫執(zhí)行附加的修復動作(repairtable)，其它數據庫不執(zhí)行此附加動作，重新檢查是否需要修復，若需要修復，則執(zhí)行以下修復流程：在加鎖裝置11中，獲取主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息，將兩個位點信息進行比較，若相同，則加鎖裝置11對主庫進行加鎖處理，引擎為不支持事務時即為鎖表，直接對整張表進行鎖定。在備庫停止裝置12中，當備庫的執(zhí)行日志的位點達到主庫完成加鎖處理時的執(zhí)行日志的位點時，備庫停止從主庫復制操作，此時可在需要修復數據對應的位點上對獲取到主備庫上不一致的數據塊進行修復。解鎖裝置13用于請求所述主庫備份待修復數據，主庫獲取到請求后會將數據文件進行本地備份，備份完成后，主庫進行解鎖處理。在修復裝置14中，獲取所述待修復數據，方式為主庫將備份的數據上傳到中轉站，備庫從中轉站中進行下載備份數據，接著，備庫執(zhí)行重建被修復數據的索引數據的操作，在修復完成后，開啟備庫使其從主庫中的復制能夠正常進行。最后，打開主備切換功能，恢復數據庫的正常狀態(tài)。本領域技術人員應能理解，所述Myisam的數據庫備庫數據修復流程為本申請的一優(yōu)選實施例，對本申請所述用于針對數據庫的數據引擎類型為不支持事務時的修復數據庫備庫數據的方法進行詳細描述，當然，現有或今后可能出現的適合本申請修復流程的數據庫，均可以引用的方式包含于本申請。針對所述數據庫的數據引擎類型為支持事務類型的，在本申請設備1中，所述解鎖裝置13包括備份單元，所述修復裝置14包括導入單元；其中，所述備份單元用于請求所述主庫對所述待修復數據所在的數據塊進行邏輯備份；所述導入單元用于刪除所述備庫中待修復的事務數據，將所述主庫所邏輯備份的待修復數據所在的數據塊導入所述備庫。以所述數據庫的數據引擎類型為支持事務類型為例進行詳細說明數據庫備庫數據修復流程。具體地，所述解鎖裝置13包括：備份單元，請求所述主庫對所述待修復數據所在的數據塊進行邏輯備份。在一優(yōu)選實施例中，主庫進行本地備份是對待修復數據所在的數據塊進行邏輯備份，其中，邏輯備份是指只是原數據庫中數據內容的一個映像；邏輯備份后主庫進行解鎖之前鎖定的數據塊，將本地備份的待修復數據上傳到中轉站，備庫從中轉站下載備份。具體地，所述修復裝置14還包括：導入單元，刪除所述備庫中待修復的事務數據，將所述主庫所邏輯備份的待修復數據所在的數據塊導入所述備庫。接前例，備庫從中轉站下載備份后用下載的邏輯備份對備庫數據進行修復，修復動作即在同一事務內刪除原來的數據和向備庫導入主庫備份的數據。進一步地，例如，Innodb為Mysql數據庫的一種引擎，其支持事務及行級鎖，其中，行級鎖是指僅對指定的記錄進行加鎖，其它進程還是可以對同一表的記錄進行操作。Innodb存儲它的表和索引在一個表空間中，表空間可以包含數個文件或原始磁盤分區(qū)。此外，針對Innodb進行修復的前期工作流程為：首先檢查是否需要修復，包括檢查主備庫的地址(ip)、端口(port)的關系來確定主備切換機制沒有改變，檢查主備的數據庫文件(db)、數據列表(table)的存在性，以確定某個數據庫中的某個文檔及其相應的表都是完整的，以及檢查主備庫的數據引擎的變化等確定是否需要修復；若需要數據修復則在主備的同步狀態(tài)下將主庫中的數據塊和備庫中相應的數據塊進行比對，檢查是否一致，若不一致則關閉主備切換的HA功能，停止容災，防止修復過程中主備關系發(fā)生變化，如一個主庫對應多個備庫，在修復過程中，主庫與備庫A關系發(fā)生變化，備庫A已被備庫B替換，主庫執(zhí)行的結構化查 詢語句(sql)會執(zhí)行到備庫B中，造成備庫B中數據錯誤。完成備庫的修復表操作后實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，進行后續(xù)的修復流程。如前例，以Innodb引擎為例的數據庫備庫數據的修復流程為本申請的又一優(yōu)選實施例，首先，檢查主備庫的地址(ip)、端口(port)的關系，數據庫文件(db)、數據列表(table)的存在性，以及數據引擎的變化等；當檢查沒問題時在主備庫的復制達到同一位點的狀態(tài)下從主庫獲取不一致的數據塊進行直接比對，若比對結果為不一致則關閉主備切換功能，在主備庫的復制達到同一位點的狀態(tài)下檢查主備間數據是否一致，若不一致，則執(zhí)行以下修復流程：在加鎖裝置11中，獲取主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息，將兩個位點信息進行比較，若相同，則加鎖裝置11對主庫進行加鎖處理，引擎為支持事務時即為鎖數據塊，直接對指定的數據塊進行鎖定。在備庫停止裝置12中，當備庫的執(zhí)行日志的位點達到主庫完成加鎖處理時的執(zhí)行日志的位點時，備庫停止從主庫復制操作，此時可在需要修復數據對應的位點上對獲取到主備庫上不一致的數據塊進行修復。解鎖裝置13用于請求所述主庫備份待修復數據，主庫獲取到請求后會將數據塊進行邏輯備份，備份完成后，主庫進行解鎖處理，即解鎖數據塊。在修復裝置14中，獲取所述待修復數據，方式為主庫將備份的數據上傳到中轉站，備庫從中轉站中進行下載備份數據，接著，用下載的邏輯備份對備庫數據進行修復，修復動作是在同一事務內刪除原來的數據和向備庫導入主庫備份的數據，在修復完成后，開啟備庫使其從主庫中的復制能夠正常進行。最后，打開主備切換功能，恢復數據庫的正常狀態(tài)。本領域技術人員應能理解，上述Innodb的數據庫備庫數據的修復流程為本申請的又一優(yōu)選實施例，對本申請所述用于針對數據庫的數據引擎類型為支持事務時的修復數據庫備庫數據的方法進行詳細描述，當然，現有或今后可能出現的適合本申請修復流程的數據庫，均可以引用的方式包含于本申請。需要說明的是，所述數據庫的數據引擎類型為不支持事務類型時的修復方式為所述優(yōu)選實施例中的文件覆蓋，但本領域技術人員應能理解，不支持事務類型的修復方式也可按照支持事務的修復流程進行修復，如主庫備份時 為邏輯備份，備庫數據修復時刪除數據塊和導入備份數據，但相比較而言，進行文件覆蓋的方式安全性更高。優(yōu)選地，所述設備1還包括：關閉裝置(未顯示)，用于在所述實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致之前，關閉所述主庫與所述備庫之間的主備切換功能；備庫開啟裝置(未顯示)，用于在所述獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，打開所述主庫與所述備庫之間的主備切換功能。在此，在實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致之前，需要關閉主備切換功能(HA)，用戶將數據寫入主庫，當主庫發(fā)生某個錯誤時HA切換到其對應的備庫，因此關閉HA功能避免了在修復過程中發(fā)生用戶將數據寫到備庫的情況。在修復完成后，需要打開主備HA功能，使主備能夠進行正常的切換。優(yōu)選地，所述設備1還包括：記錄裝置(未顯示)，用于記錄對所述主庫進行可讀不可寫加鎖處理的已加鎖時間，當所述已加鎖時間超過設定超時時間時，停止當前修復操作。在一具體實施例中，主庫進行可讀不可寫加鎖處理操作時需要有超時控制，控制方式可以通過另開線程等待該超時時間，時間到將放棄加鎖動作，并放棄本次修復。本領域技術人員應能理解，所述控制超時方法僅為舉例，其他現有的或今后可能出現的控制超時的方法如可適用于本發(fā)明，也應包含在本發(fā)明保護范圍以內，并在此以引用方式包含于此。進一步地，與現有技術相比，通過上述本申請的實施例可知，在修復流程過程中沒有通過執(zhí)行總和檢驗碼逐行比較主備數據塊中的每一行，而是通過數據文件的覆蓋或導入數據塊實現數據庫備庫數據的修復，從而避免了被修復表沒有唯一主鍵時所造成的修復對象錯誤的情況克服不需要對數據塊進行逐行分析就可以完成準確修復數據的問題。圖4出根據本申請又一個方面的一種用于修復數據庫備庫數據的方法流程示意圖。該方法包括步驟S11、步驟S12、步驟S13和步驟S14。其中，在步驟S11中，實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行 日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處理；在步驟S12中，實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作；在步驟S13中，請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理；在步驟S14中，獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。數據庫系統中，為解決單點問題，同時為了實現數據實例負載均衡，往往建立一個主庫及建立一個或多個對主庫進行復制的備庫，只有主庫可以寫入，備庫只可以進行讀取。主從復制原理往往是通過備庫復制主庫的執(zhí)行日志(binlog)再進行執(zhí)行來完成的。對于復制關系，各種數據庫產品都有各自的實現方法，以mysql(一種關系型數據庫管理系統)為例，mysql主庫在事務提交時寫執(zhí)行日志，并通過同步執(zhí)行日志(sync_binlog)參數來控制執(zhí)行日志刷新到磁盤“落地”，而備庫通過輸入輸出(io)線程從主庫讀取執(zhí)行日志，并記錄到本地的中繼日志(relaylog)中，由本地的sql(結構化查詢語言)線程再將中繼日志的數據應用到本地數據庫。數據庫為了效率等原因，數據只保存在內存中，沒有真正的寫入到磁盤上去。如果數據庫響應為“提交成功”，但是由于數據庫掛掉，操作系統，數據庫主機等任何問題導致這次“提交成功”的事務對數據庫的修改沒有生效，那么我們認為這個事務的數據丟失了。對于銀行業(yè)務或者金融業(yè)務等數據一致性要求高的場景來說是不能接受的，所以，保證數據不丟失也是數據庫選擇的一個重要衡量標準。為了保證數據不丟失以及主備間數據的一致性，各類數據庫系統都做了大量的工作，但是在實際使用過程中，在數據可靠性和使用效率上往往要做一個權衡，這就給主備數據不一致的產生創(chuàng)造了可能性，另外，由于雙寫、日志文件損壞等因素，即使運行在完全高可靠的工作模式，仍有可能造成主備間數據不一致。本申請又一實施例所述方法用于修復數據庫備庫數據，由于主備庫兩次等同步后對主庫短暫的加鎖，通過停止備庫，主庫內待修復數據的備份及備庫獲取已備份好的數據進行修復數據，按數據塊或數據文件修復，無 需對數據進行逐行分析，就可以完成修復。修復過程控制在數秒內，在云計算場景下，可以不暫停業(yè)務就可以修復數據，主備兩次等同步使在修復的位點上修復了所需修復的數據，達到精確修復的效果；進一步地，對主庫加鎖時有超時控制，當時間超過設定的超時時間，停止當前修復操作，不會存在半修復半不修復的情況，達到修復安全的目的。需要說明的是，一個主庫對應一個或多個備庫，主庫和備庫可以分布在同一設備上，可以分布在不同設備上。具體地，步驟S11：實時比較主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息是否一致，當一致時，對所述主庫進行可讀不可寫的加鎖處理。在此，等同步為主庫的執(zhí)行日志位點信息和對應的備庫的執(zhí)行日志位點信息一致，實時比較主備庫的位點信息實現第一次等同步，即實時將獲取的主庫的執(zhí)行日志位點信息與獲取的備庫的執(zhí)行日志的位點信息進行比較，若一致，則為主備第一次等同步；當主備第一次等同步后，主備庫位于同一位點，對主庫進行加鎖處理使用戶短時間內不可寫入，加鎖時間可為數秒，短暫時間內對線上業(yè)務影響極小，此時利用中間層阻塞用戶的結構化查詢語言(sql)。主庫的加鎖動作有超時控制，控制方式是通過另開線程等待該超時時間，時間到將放棄加鎖動作，并放棄本次修復。具體地，步驟S12：實時比較所述主庫在完成加鎖處理時執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，當一致時，停止所述備庫從所述主庫進行的復制工作。在一具體實施例中，以mysql為例，可在主庫中通過命令顯示主庫執(zhí)行日志文件的狀態(tài)信息(showmasterstatus)獲取到主庫當前位點信息，再等待備庫復制到該位點，主備庫在實現第一次等同步后的極短時間內可實現第二次等同步，此時主庫的數據為備庫修復數據所需的，將備庫停止是指停止備庫從主庫進行復制，備庫停止后能夠獲取到備庫所需的數據，且能在相應的修復位點上進行修復。具體地，步驟S13：請求所述主庫備份待修復數據，并在所述待修復數據備份完成后，對所述主庫進行解鎖處理。接前例，備庫停止后，主庫進行備份待修復數據，在此，待修復數據是 指備庫所需的修復數據塊或數據文件對應的相應數據，將待修復的數據塊或數據文件在主庫進行本地備份，備份時間極短，因此此時主庫的加鎖超時尚未到，對主庫進行解鎖處理可以使用戶可以正常寫入。具體地，步驟S14：獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，開啟所述備庫從所述主庫進行的復制工作。在一優(yōu)選實施例中，主庫備份數據后，將本地備份的數據上傳到中轉站，備庫從中轉站中下載相應的數據塊覆蓋到備庫或進行數據文件覆蓋。按照數據塊或數據文件進行修復避免了對數據進行逐行分析的問題，完成修復后開啟備庫從主庫進行的復制工作，主備之間開始正常復制。圖2示出根據本申請一個方面的一個優(yōu)選實施例的修復數據庫備庫數據的流程示意圖。其中的標號1-10為流程圖的順序，Master為所述主庫，Slave為其對應的備庫。流程為：步驟S11，在主備第一次等同步后對主庫加鎖；接著，在步驟S12中，在主備第二次等同步后停止備庫；隨后，在步驟S13中，在主庫備份數據后將主庫解鎖；最后，在步驟S14中，將主庫中的已備份數據上傳中轉站，備庫從中轉站中下載進行修復數據，修復數據完成后將備庫開啟。在此，數據庫的引擎可分為兩種，一種為不支持事務的，一種為支持事務的，在此，對于不支持事務類型的，其每個表有單獨的數據文件和索引文件，進行修復時最安全的方式為數據文件的覆蓋，對于支持事務類型的，支持事務及行級鎖。因此，對于不支持事務的引擎，安全修復方式為進行數據文件的覆蓋，對于支持事務的引擎，在一個事務里用兩個執(zhí)行語句(包括刪除數據塊和導入備份的數據)可以進行修復。以下為針對兩種引擎類型進行修復數據庫備份數據的優(yōu)選實施例進行說明修復流程。針對所述數據庫的數據引擎類型為不支持事務類型的，本申請所述方法中的步驟S13請求所述主庫備份所述待修復數據的數據文件和索引文件；如圖5示出，所述步驟S14包括：步驟S141、步驟S142、步驟S143和步驟S144，其中，在所述步驟S141中，對所述備庫進行鎖表處理；在所述步驟S142中，獲取從所述主庫中所備份的待修復數據；在步驟S143中，對所述備庫進行解鎖處理；修復表單元144基于所述待修復數據進行修復表操作。具體地，請求所述主庫備份待修復數據包括：請求所述主庫備份所述待修復數據的數據文件和索引文件。在此，對于數據庫的數據引擎類型為不支持事務類型，每個表有單獨的數據文件和索引文件，進行修復時最安全的方式為數據文件的覆蓋，因此主庫進行備份數據時為備份所述待修復數據的數據文件和索引文件。需要說明的是，Myisam引擎有自帶的附加修復(repairtable)動作，在主庫備份時備份待修復數據的數據文件，備庫執(zhí)行附加修復(repairtable)動作重建被修復數據的索引數據。具體地，所述獲取所述待修復數據包括：步驟S141，對所述備庫進行鎖表處理；步驟S142，獲取從所述主庫中所備份的待修復數據；步驟S143，對所述備庫進行解鎖處理；步驟S144，基于所述待修復數據進行修復表操作。例如，Mysiam引擎為不支持事務，對主庫進行加鎖時表現為鎖表，即直接鎖定整張表，修復過程中主庫中待修復數據備份并將所備份的數據上傳到中轉站中后，因Mysiam引擎的修復過程中對備庫執(zhí)行了附加修復(repairtable)動作，為防止用戶或數據庫管理員(dba)進行附加修復(repairtable)動作從而影響修復，需對備庫進行鎖表操作。因備庫從主庫中的復制過程已停止，備庫若要獲取主庫中所備份的待修復數據可通過先將主庫中已備份好的數據上傳到中轉站，然后備庫再從中轉站下載備份數據。備庫獲取備份的待修復數據后對備庫進行解鎖，備庫執(zhí)行附加修復(repairtable)動作，重建被修復數據的索引數據等，保證備庫中原有的數據文件被完全覆蓋，獲得新的正確的數據文件。需要說明的是，Mysiam引擎能夠執(zhí)行附加修復(repairtable)動作，主庫備份時只需備份數據文件，備庫執(zhí)行附加修復動作時能夠重建索引文件，對于其它不帶附加修復動作的不支持事務的引擎，主庫備份時備份數據文件和索引文件，備庫利用獲取已備份好的數據文件和索引文件進行文件覆蓋實現表的修復。進一步地，例如，Myisam引擎不支持事務，在Myisam表中每個被存在分離的文件中，Myisam為表級鎖，直接鎖定整張表，在鎖定期間，其它進程無法對該表進行寫操作。此外，針對Myisam進行修復的前期工作流程為： 首先檢查是否需要修復，包括檢查主備庫的地址(ip)、端口(port)的關系來確定主備切換機制沒有改變，檢查主備的數據庫文件(db)、數據列表(table)的存在性，以確定某個數據庫中的某個文檔及其相應的表都是完整的，以及檢查主備庫的數據引擎的變化等確定是否需要修復；若需要數據修復則在主備的同步狀態(tài)下將主庫中的數據塊和備庫中相應的數據塊進行比對，檢查是否一致，若不一致則關閉主備切換功能(HA)，停止容災，防止修復過程中主備關系發(fā)生變化，如一個主庫對應多個備庫，在修復過程中，主庫與備庫A關系發(fā)生變化，備庫A已被備庫B替換，主庫執(zhí)行的結構化查詢語句(sql)會執(zhí)行到備庫B中，造成備庫B中數據錯誤；接著，在主備的同步狀態(tài)下檢查是否已經修復，若未修復則對備庫執(zhí)行附加修復(repairtable)動作，對于能夠用附加修復(repairtable)動作修復的數據可以避免進行鎖表才能修復，需說明的是，附加修復(repairtable)動作只是僅對mysql的Myisam引擎的附加動作，其他的數據庫中沒有這一動作。完成備庫的修復表操作后實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，進行后續(xù)的修復流程。如前例，以Myisam引擎為例的數據庫備庫數據的修復流程為本申請的一優(yōu)選實施例，首先，檢查主備庫的地址(ip)、端口(port)的關系，數據文件(db)、數據列表(table)的存在性，以及數據引擎的變化等；當檢查沒問題時在主備庫的復制達到同一位點的狀態(tài)下從主庫獲取不一致的數據塊進行直接比對，若比對結果為不一致則關閉主備切換功能，在主備庫的復制達到同一位點的狀態(tài)下檢查主備間數據是否一致，若不一致，對于Myisam則需要對備庫執(zhí)行附加的修復動作(repairtable)，其它數據庫不執(zhí)行此附加動作，重新檢查是否需要修復，若需要修復，則執(zhí)行以下修復流程：在步驟S11中，獲取主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息，將兩個位點信息進行比較，若相同，則在步驟S11中對主庫進行加鎖處理，引擎為不支持事務時即為鎖表，直接對整張表進行鎖定。在步驟S12中，當備庫的執(zhí)行日志的位點達到主庫完成加鎖處理時的執(zhí)行日志的位點時，備庫停止從主庫復制操作，此時可在需要修復數據對應的位點上對獲取到主備庫上不一致的數據塊進行修復。在步驟S13中，請求所述主庫備份待修復數據，主庫獲取 到請求后會將數據文件進行本地備份，備份完成后，主庫進行解鎖處理。在步驟S14中，獲取所述待修復數據，方式為主庫將備份的數據上傳到中轉站，備庫從中轉站中進行下載備份數據，接著，備庫執(zhí)行重建被修復數據的索引數據的操作，在修復完成后，開啟備庫使其從主庫中的復制能夠正常進行。最后，打開主備切換功能，恢復數據庫的正常狀態(tài)。本領域技術人員應能理解，所述Myisam的數據庫備庫數據修復流程為本申請的一優(yōu)選實施例，對本申請所述用于針對數據庫的數據引擎類型為不支持事務時的修復數據庫備庫數據的方法進行詳細描述，當然，現有或今后可能出現的適合本申請修復流程的數據庫，均可以引用的方式包含于本申請。針對所述數據庫的數據引擎類型為支持事務類型的，在本申請方法中，所述步驟S13還包括：請求所述主庫對所述待修復數據所在的數據塊進行邏輯備份；在所述步驟14還包括：刪除所述備庫中待修復的事務數據，將所述主庫所邏輯備份的待修復數據所在的數據塊導入所述備庫。以所述數據庫的數據引擎類型為支持事務類型為例進行詳細說明數據庫備庫數據修復流程。具體地，所述主庫備份待修復數據還包括：請求所述主庫對所述待修復數據所在的數據塊進行邏輯備份。在一優(yōu)選實施例中，主庫進行本地備份是對待修復數據所在的數據塊進行邏輯備份，其中，邏輯備份是指只是原數據庫中數據內容的一個映像；邏輯備份后主庫進行解鎖之前鎖定的數據塊，將本地備份的待修復數據上傳到中轉站，備庫從中轉站下載備份。具體地，基于所述待修復數據對所述備庫進行修復還包括：刪除所述備庫中待修復的事務數據，將所述主庫所邏輯備份的待修復數據所在的數據塊導入所述備庫。接前例，備庫從中轉站下載備份后用下載的邏輯備份對備庫數據進行修復，修復動作即在同一事務內刪除原來的數據和向備庫導入主庫備份的數據。進一步地，例如，Innodb為Mysql數據庫的一種引擎，其支持事務及行級鎖，其中，行級鎖是指僅對指定的記錄進行加鎖，其它進程還是可以對同一表的記錄進行操作。Innodb存儲它的表和索引在一個表空間中，表空間可 以包含數個文件或原始磁盤分區(qū)。此外，針對Innodb進行修復的前期工作流程為：首先檢查是否需要修復，包括檢查主備庫的地址(ip)、端口(port)的關系來確定主備切換機制沒有改變，檢查主備的數據庫文件(db)、數據列表(table)的存在性，以確定某個數據庫中的某個文檔及其相應的表都是完整的，以及檢查主備庫的數據引擎的變化等確定是否需要修復；若需要數據修復則在主備的同步狀態(tài)下將主庫中的數據塊和備庫中相應的數據塊進行比對，檢查是否一致，若不一致則關閉主備切換的HA功能，停止容災，防止修復過程中主備關系發(fā)生變化，如一個主庫對應多個備庫，在修復過程中，主庫與備庫A關系發(fā)生變化，備庫A已被備庫B替換，主庫執(zhí)行的結構化查詢語言(sql)會執(zhí)行到備庫B中，造成備庫B中數據錯誤。完成備庫的修復表操作后實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致，進行后續(xù)的修復流程。如前例，以Innodb引擎為例的數據庫備庫數據的修復流程為本申請的又一優(yōu)選實施例，首先，檢查主備庫的地址、端口的關系，數據文件、數據列表的存在性，以及數據引擎的變化等；當檢查沒問題時在主備庫的復制達到同一位點的狀態(tài)下從主庫獲取不一致的數據塊進行直接比對，若比對結果為不一致則關閉主備切換功能，在主備庫的復制達到同一位點的狀態(tài)下檢查主備間數據是否一致，若不一致，則執(zhí)行以下修復流程：在步驟S11中，獲取主庫的執(zhí)行日志位點信息和備庫的執(zhí)行日志位點信息，將兩個位點信息進行比較，若相同，則對主庫進行加鎖處理，引擎為支持事務時即為鎖數據塊，直接對指定的數據塊進行鎖定。在步驟S12中，當備庫的執(zhí)行日志的位點達到主庫完成加鎖處理時的執(zhí)行日志的位點時，備庫停止從主庫復制操作，此時可在需要修復數據對應的位點上對獲取到主備庫上不一致的數據塊進行修復。在步驟S13中，請求所述主庫備份待修復數據，主庫獲取到請求后會將數據塊進行邏輯備份，備份完成后，主庫進行解鎖處理，即解鎖數據塊。在步驟S14中，獲取所述待修復數據，方式為主庫將備份的數據上傳到中轉站，備庫從中轉站中進行下載備份數據，接著，用下載的邏輯備份對備庫數據進行修復，修復動作是在同一事務內刪除原來的數據和向備庫導入主庫備份的數據，在修復完成后，開啟備庫使其從主庫中的復制能夠正常進行。最后， 打開主備切換功能，恢復數據庫的正常狀態(tài)。本領域技術人員應能理解，上述Innodb的數據庫備庫數據的修復流程為本申請的又一優(yōu)選實施例，對本申請所述用于針對數據庫的數據引擎類型為支持事務時的修復數據庫備庫數據的方法進行詳細描述，當然，現有或今后可能出現的適合本申請修復流程的數據庫，均可以引用的方式包含于本申請。需要說明的是，所述數據庫的數據引擎類型為不支持事務類型時的修復方式為所述優(yōu)選實施例中的文件覆蓋，但本領域技術人員應能理解，不支持事務類型的修復方式也可按照支持事務的修復流程進行修復，如主庫備份時為邏輯備份，備庫數據修復時刪除數據塊和導入備份數據，但相比較而言，進行文件覆蓋的方式安全性更高。優(yōu)選地，所述方法還包括：在所述實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致之前，關閉所述主庫與所述備庫之間的主備切換功能；在所述獲取所述待修復數據，并基于所述待修復數據對所述備庫進行修復，在修復完成后，打開所述主庫與所述備庫之間的主備切換功能。在此，在實時比較主庫的執(zhí)行日志位點信息和所述備庫的執(zhí)行日志位點信息是否一致之前，需要關閉主備切換功能(HA)，用戶將數據寫入主庫，當主庫發(fā)生某個錯誤時HA切換到其對應的備庫，因此關閉HA功能避免了在修復過程中發(fā)生用戶將數據寫到備庫的情況。在修復完成后，需要打開主備HA功能，使主備能夠進行正常的切換。優(yōu)選地，所述方法還包括：記錄對所述主庫進行可讀不可寫加鎖處理的已加鎖時間，當所述已加鎖時間超過設定超時時間時，停止當前修復操作。在一具體實施例中，主庫進行可讀不可寫加鎖處理操作時需要有超時控制，控制方式可以通過另開線程等待該超時時間，時間到將放棄加鎖動作，并放棄本次修復。本領域技術人員應能理解，所述控制超時方法僅為舉例，其他現有的或今后可能出現的控制超時的方法如可適用于本發(fā)明，也應包含在本發(fā)明保護范圍以內，并在此以引用方式包含于此。進一步地，與現有技術相比，通過上述本申請的實施例可知，在修復 流程過程中沒有通過執(zhí)行總和檢驗碼逐行比較主備數據塊中的每一行，而是通過數據文件的覆蓋或導入數據塊實現數據庫備庫數據的修復，從而避免了被修復表沒有唯一主鍵時所造成的修復對象錯誤的情況克服不需要對數據塊進行逐行分析就可以完成準確修復數據的問題。需要注意的是，本申請可在軟件和/或軟件與硬件的組合體中被實施，例如，可采用專用集成電路(ASIC)、通用目的計算機或任何其他類似硬件設備來實現。在一個實施例中，本申請的軟件程序可以通過處理器執(zhí)行以實現上文所述步驟或功能。同樣地，本申請的軟件程序(包括相關的數據結構)可以被存儲到計算機可讀記錄介質中，例如，RAM存儲器，磁或光驅動器或軟磁盤及類似設備。另外，本申請的一些步驟或功能可采用硬件來實現，例如，作為與處理器配合從而執(zhí)行各個步驟或功能的電路。另外，本申請的一部分可被應用為計算機程序產品，例如計算機程序指令，當其被計算機執(zhí)行時，通過該計算機的操作，可以調用或提供根據本申請的方法和/或技術方案。而調用本申請的方法的程序指令，可能被存儲在固定的或可移動的記錄介質中，和/或通過廣播或其他信號承載媒體中的數據流而被傳輸，和/或被存儲在根據所述程序指令運行的計算機設備的工作存儲器中。在此，根據本申請的一個實施例包括一個裝置，該裝置包括用于存儲計算機程序指令的存儲器和用于執(zhí)行程序指令的處理器，其中，當該計算機程序指令被該處理器執(zhí)行時，觸發(fā)該裝置運行基于前述根據本申請的多個實施例的方法和/或技術方案。對于本領域技術人員而言，顯然本申請不限于上述示范性實施例的細節(jié)，而且在不背離本申請的精神或基本特征的情況下，能夠以其他的具體形式實現本申請。因此，無論從哪一點來看，均應將實施例看作是示范性的，而且是非限制性的，本申請的范圍由所附權利要求而不是上述說明限定，因此旨在將落在權利要求的等同要件的含義和范圍內的所有變化涵括在本申請內。不應將權利要求中的任何附圖標記視為限制所涉及的權利要求。此外，顯然“包括”一詞不排除其他單元或步驟，單數不排除復數。裝置權利要求中陳述的多個單元或裝置也可以由一個單元或裝置通過軟件或者硬件來實現。第一，第二等詞語用來表示名稱，而并不表示任何特定 的順序。當前第1頁1 2 3