關於redis持久化，redis持久化

關於redis持久化，redis持久化

Redis有兩種持久化的方式：快照（RDB檔案）和追加式檔案（AOF檔案）

• RDB持久化方式是在一個特定的間隔儲存某個時間點的一個資料快照。

• AOF（Append only file）持久化方式則會記錄每一個伺服器收到的寫操作。資料回複時，這些記錄的操作會逐條執行從而重建出原來的資料。寫操作命令  記錄的格式跟Redis協議一致，以追加的方式進行儲存。

Redis的持久化是可以禁用的，兩種方式的持久化是可以同時存在的，但是當Redis重啟時，AOF檔案會被優先用於重建資料。

一、RDB

RDB就是Snapshot儲存，是預設的持久化方式。按照一定的策略周期性的將資料儲存到磁碟。對應產生的資料檔案為dump.rdb，通過設定檔中的save參數來定義快照的周期。Redis支援將當前資料的快照存成一個資料檔案實現持久化。而一個持續寫入的資料庫如何產生快照呢。Redis藉助了fork命令的copy on write機制。在產生快照時，將當前進程fork出一個子進程，然後在子進程中迴圈所有的資料，將資料寫成為RDB檔案。

Client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主線程中儲存快照的，由於redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求，所以不推薦使用。另一點需要注意的是，每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不 是增量的只同步髒資料。如果資料量大的話，而且寫操作比較多，必然會引起大量的磁碟io操作，可能會嚴重影響效能。 

Redis的RDB檔案不會壞掉，因為其寫操作是在一個新進程中進行的。當產生一個新的RDB檔案時，Redis產生的子進程會先將資料寫到一個臨時檔案中，然後通過原子性rename系統調用將臨時檔案重新命名為RDB檔案。這樣在任何時候出現故障，Redis的RDB檔案都總是可用的。並且Redis的RDB檔案也是Redis主從同步內部實現中的一環

主從同步

第一次Slave向Master同步的實現是：
Slave向Master發出同步請求，Master先dump出rdb檔案，然後將rdb檔案全量傳輸給slave，然後Master把緩衝的命令轉寄給Slave，初次同步完成。
第二次以及以後的同步實現是：
Master將變數的快照直接即時依次發送給各個Slave。但不管什麼原因導致Slave和Master斷開重連都會重複以上兩個步驟的過程。
Redis的主從複製是建立在記憶體快照的持久化基礎上的，只要有Slave就一定會有記憶體快照發生。

工作原理

• Redis調用fork()，產生一個子進程。

• 父進程繼續處理client請求，子進程把記憶體資料寫到一個臨時的RDB檔案。由於os的寫時複製機制（copy on write)父子進程會共用相同的物理頁面，當父進程處理寫請求時os會為父進程要修改的頁面棄置站台，而不是寫共用的頁面。所以子進程的地址空間內的資料是fork時刻整個資料庫的一個快照。

• 當子進程將快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子進程退出

優點

• RDB檔案是一個很簡潔的單檔案，它儲存了某個時間點的Redis資料，很適合用於做備份。你可以設定一個時間點對RDB檔案進行歸檔，這樣就能在需要的時候很輕易的把資料恢複到不同的版本。

• RDB很適合用於災備。單檔案很方便就能傳輸到遠端伺服器上。

• RDB的效能很好，需要進行持久化時，主進程會fork一個子進程出來，然後把持久化的工作交給子進程，自己不會有相關的I/O操作。

• 比起AOF，在資料量比較大的情況下，RDB的啟動速度更快。

缺點

• RDB容易造成資料的丟失。假設每5分鐘儲存一次快照，如果Redis因為某些原因不能正常工作，那麼從上次產生快照到Redis出現問題這段時間的資料就會丟失了。

• RDB使用fork()產生子進程進行資料的持久化，如果資料比較大的話可能就會花費點時間，造成Redis停止服務幾毫秒。如果資料量很大且CPU效能不是很好的時候，停止服務的時間甚至會到1秒。

檔案路徑和名稱

預設Redis會把快照檔案儲存體為目前的目錄下一個名為dump.rdb的檔案。要修改檔案的儲存路徑和名稱，可以通過修改設定檔redis.conf實現：

# RDB檔案名稱，預設為dump.rdb。dbfilename dump.rdb# 檔案存放的目錄，AOF檔案同樣存放在此目錄下。預設為當前工作目錄。dir ./

儲存點（RDB的啟用和禁用）

你可以配置儲存點，使Redis如果在每N秒後資料發生了M次改變就儲存快照檔案。例如下面這個儲存點配置表示每60秒，如果資料發生了1000次以上的變動，Redis就會自動儲存快照檔案：

save 60 1000

儲存點可以設定多個，Redis的設定檔就預設設定了3個儲存點：

# 格式為：save <seconds> <changes># 可以設定多個。save 900 1 #900秒後至少1個key有變動save 300 10 #300秒後至少10個key有變動save 60 10000 #60秒後至少10000個key有變動

如果想禁用快照儲存的功能，可以通過注釋掉所有"save"配置達到，或者在最後一條"save"配置後添加如下的配置：

save ""

錯誤處理

預設情況下，如果Redis在後台產生快照的時候失敗，那麼就會停止接收資料，目的是讓使用者能知道資料沒有持久化成功。但是如果你有其他的方式可以監控到Redis及其持久化的狀態，那麼可以把這個功能禁止掉。

stop-writes-on-bgsave-error yes

資料壓縮

預設Redis會採用LZF對資料進行壓縮。如果你想節省點CPU的效能，你可以把壓縮功能禁用掉，但是資料集就會比沒壓縮的時候要打。

rdbcompression yes

資料校正

從版本5的RDB的開始，一個CRC64的校正碼會放在檔案的末尾。這樣更能保證檔案的完整性，但是在儲存或者負載檔案時會損失一定的效能（大概10%）。如果想追求更高的效能，可以把它禁用掉，這樣檔案在寫入校正碼時會用0替代，載入的時候看到0就會直接跳過校正

rdbchecksum yes

手動產生快照

Redis提供了兩個命令用於手動產生快照。

SAVE

SAVE命令會使用同步的方式產生RDB快照檔案，這意味著在這個過程中會阻塞所有其他用戶端的請求。因此不建議在生產環境使用這個命令，除非因為某種原因需要去阻止Redis使用子進程進行後台產生快照（例如調用fork(2)出錯）。

BGSAVE

BGSAVE命令使用背景方式儲存RDB檔案，調用此命令後，會立刻返回OK返回碼。Redis會產生一個子進程進行處理並立刻恢複對用戶端的服務。在用戶端我們可以使用LASTSAVE命令查看操作是否成功。

127.0.0.1:6379> BGSAVEBackground saving started127.0.0.1:6379> LASTSAVE(integer) 1433936394

設定檔裡禁用了快照產生功能不影響SAVE和BGSAVE命令的效果。

二、AOF

快照並不是很可靠。如果伺服器突然Crash了，那麼最新的資料就會丟失。而AOF檔案則提供了一種更為可靠的持久化方式。每當Redis接受到會修改資料集的命令時，就會把命令追加到AOF檔案裡，當你重啟Redis時，AOF裡的命令會被重新執行一次，重建資料

原理

• redis調用fork ，現在有父子兩個進程

• 子進程根據記憶體中的資料庫快照集，往臨時檔案中寫入重建資料庫狀態的命令

• 父進程繼續處理client請求，除了把寫命令寫入到原來的aof檔案中。同時把收到的寫命令緩衝起來。這樣就能保證如果子進程重寫失敗的話並不會出問題

• 當子進程把快照內容寫入已命令方式寫到臨時檔案中後，子進程發訊號通知父進程。然後父進程把緩衝的寫命令也寫入到臨時檔案

• 現在父進程可以使用臨時檔案替換老的aof檔案，並重新命名，後面收到的寫命令也開始往新的aof檔案中追加

優點

• 比RDB可靠。你可以制定不同的fsync策略：不進行fsync、每秒fsync一次和每次查詢進行fsync。預設是每秒fsync一次。這意味著你最多丟失一秒鐘的資料。

• AOF記錄檔是一個純追加的檔案。就算伺服器突然Crash，也不會出現日誌的定位或者損壞問題。甚至如果因為某些原因（例如磁碟滿了）命令唯寫了一半到記錄檔裡，我們也可以用redis-check-aof這個工具很簡單的進行修複。

• 當AOF檔案太大時，Redis會自動在後台進行重寫。重寫很安全，因為重寫是在一個新的檔案上進行，同時Redis會繼續往舊的檔案追加資料。新檔案上會寫入能重建當前資料集的最小操作命令的集合。當新檔案重寫完，Redis會把新舊檔案進行切換，然後開始把資料寫到新檔案上。

• AOF把操作命令以簡單易懂的格式一條接一條的儲存在檔案裡，很容易匯出來用於恢複資料。例如我們不小心用FLUSHALL命令把所有資料刷掉了，只要檔案沒有被重寫，我們可以把服務停掉，把最後那條命令刪掉，然後重啟服務，這樣就能把被刷掉的資料恢複回來。

缺點

• 在相同的資料集下，AOF檔案的大小一般會比RDB檔案大。

• 在某些fsync策略下，AOF的速度會比RDB慢。通常fsync設定為每秒一次就能獲得比較高的效能，而在禁止fsync的情況下速度可以達到RDB的水平。

• 在過去曾經發現一些很罕見的BUG導致使用AOF重建的資料跟原資料不一致的問題。

啟用AOF

把配置項appendonly設為yes：

appendonly yes

檔案路徑和名稱

# 檔案存放目錄，與RDB共用。預設為當前工作目錄。dir ./# 預設檔案名稱為appendonly.aofappendfilename "appendonly.aof"

可靠性

你可以配置Redis調用fsync的頻率，有三個選項：

• 每當有新命令追加到AOF的時候調用fsync。速度最慢，但是最安全。

• 每秒fsync一次。速度快（2.4版本跟快照方式速度差不多），安全性不錯（最多丟失1秒的資料）。

• 從不fsync，交由系統去處理。這個方式速度最快，但是安全性沒有保證

推薦使用每秒fsync一次的方式（預設的方式），因為它速度快，安全性也不錯。相關配置如下：

# appendfsync alwaysappendfsync everysec# appendfsync no

日誌重寫

隨著寫操作的不斷增加，AOF檔案會越來越大。例如你遞增一個計數器100次，那麼最終結果就是資料集裡的計數器的值為最終的遞增結果，但是AOF檔案裡卻會把這100次操作完整的記錄下來。而事實上要恢複這個記錄，只需要1個命令就行了，也就是說AOF檔案裡那100條命令其實可以精簡為1條。所以Redis支援這樣一個功能：在不中斷服務的情況下在後台重建AOF檔案。

工作原理如下：

• Redis調用fork()，產生一個子進程。

• 子進程把新的AOF寫到一個臨時檔案裡。

• 主進程持續把新的變動寫到記憶體裡的buffer，同時也會把這些新的變動寫到舊的AOF裡，這樣即使重寫失敗也能保證資料的安全。

• 當子進程完成檔案的重寫後，主進程會獲得一個訊號，然後把記憶體裡的buffer追加到子進程產生的那個新AOF裡。

我們可以通過配置設定日誌重寫的條件：

#在日誌重寫時，不進行命令追加操作，而只是將其放在緩衝區裡，避免與命令的追加造成DISK IO上的衝突。#設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成後再寫入，預設為no，建議yesno-appendfsync-on-rewrite yes # Redis會記住自從上一次重寫後AOF檔案的大小（如果自Redis啟動後還沒重寫過，則記住啟動時使用的AOF檔案的大小）。# 如果當前的檔案大小比起記住的那個大小超過指定的百分比，則會觸發重寫。# 同時需要設定一個檔案大小最小值，只有大於這個值檔案才會重寫，以防檔案很小，但是已經達到百分比的情況。auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

要禁用自動的日誌重寫功能，我們可以把百分比設定為0：

auto-aof-rewrite-percentage 0

Redis 2.4以上才可以自動進行日誌重寫，之前的版本需要手動運行BGREWRITEAOF這個命令。

資料損毀修複

如果因為某些原因（例如伺服器崩潰）AOF檔案損壞了，導致Redis載入不了，可以通過以下方式進行修複：

• 備份AOF檔案。

• 使用redis-check-aof命令修複原始的AOF檔案：

  $ redis-check-aof --fix

• 可以使用diff -u命令看下兩個檔案的差異。

• 使用修複過的檔案重啟Redis服務。

從RDB切換到AOF

這裡只說Redis >= 2.2版本的方式：

• 備份一個最新的dump.rdb的檔案，並把備份檔案放在一個安全的地方。

• 運行以下兩條命令：

  $ redis-cli config set appendonly yes$ redis-cli config set save ""

• 確保資料跟切換前一致。

• 確保資料正確的寫到AOF檔案裡。

第二條命令是用來禁用RDB的持久化方式，但是這不是必須的，因為你可以同時啟用兩種持久化方式。

記得對設定檔redis.conf進行編輯啟用AOF，因為命令列方式修改配置在重啟Redis後就會失效。

從上面看出，RDB和AOF操作都是順序IO操作，效能都很高。而同時在通過RDB檔案或者AOF日誌進行資料庫恢複的時候，也是順序的讀取資料載入到記憶體中。所以也不會造成磁碟的隨機讀。

到底選擇什麼呢？下面是來自官方的建議：

通常，如果你要想提供很高的資料保障性，那麼建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的資料丟失，那麼你可以僅使用RDB。很多使用者僅使用了AOF，但是我們建議，既然RDB可以時不時的給資料做個完整的快照，並且提供更快的重啟，所以最好還是也使用RDB。

在資料恢複方面：RDB的啟動時間會更短，原因有兩個

• 一是RDB檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。

• 另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。 

注意：

上面說了RDB快照的持久化，需要注意：在進行快照的時候（save），fork出來進行dump操作的子進程會佔用與父進程一樣的記憶體，真正的copy-on-write，對效能的影響和記憶體的耗用都是比較大的。比如機器8G記憶體，Redis已經使用了6G記憶體，這時save的話會再產生6G，變成12G，大於系統的8G。這時候會發生交換；要是虛擬記憶體不夠則會崩潰，導致資料丟失。所以在用redis的時候一定對系統記憶體做好容量規劃。

目前，通常的設計思路是利用Replication機制來彌補aof、snapshot效能上的不足，達到了資料可持久化。即Master上Snapshot和AOF都不做，來保證Master的讀寫效能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證資料的安全性。

三、對Redis持久化的測試

通過上面的理論對snapshot和aof有了一定的理解，下面開始進行一些測試

1、redis.conf 開啟snapshot 關閉aof

save 900 1save 300 10save 60 10000rdbcompression nordbchecksum nodbfilename redis.rdbdir /home/backup/redisappendonly  no

測試

[root@localhost redis]# ./src/redis-cli 127.0.0.1:6379> keys *1) "a"127.0.0.1:6379> set b 2OK127.0.0.1:6379> set c 3OK127.0.0.1:6379> set d 4OK127.0.0.1:6379> keys *1) "c"2) "a"3) "aa"4) "b"5) "d"127.0.0.1:6379> saveOK#儲存，進行持久化，每執行一次save，會在日至裡面記錄一條：" * DB saved on disk "127.0.0.1:6379> lpush aa 1(integer) 1127.0.0.1:6379> lpush aa 2(integer) 2

持久化驗證，重啟redis

127.0.0.1:6379> keys *1) "c"2) "a"3) "aa"4) "b"5) "d"

lpush 操作在 save之後，但是重啟之後仍然有這個資料

什麼原因呢，我們可以查看一下日誌 

6720:signal-handler (1453738444) Received SIGTERM scheduling shutdown...6720:M 26 Jan 00:14:04.896 # User requested shutdown...6720:M 26 Jan 00:14:04.896 * Saving the final RDB snapshot before exiting.6720:M 26 Jan 00:14:04.932 * DB saved on disk6720:M 26 Jan 00:14:04.932 * Removing the pid file.6720:M 26 Jan 00:14:04.932 # Redis is now ready to exit, bye bye...

從日誌裡面可以看到，正常關閉redis，在關閉前執行save命令。 用kill的效果和上面一樣，屬於正常關閉

那異常關閉呢？當以kill -9 的形式發送訊號

127.0.0.1:6379> set ss 1Could not connect to Redis at 127.0.0.1:6379: Connection refusednot connected> get ssCould not connect to Redis at 127.0.0.1:6379: Connection refusednot connected> get ss(nil)

通過測試，開啟RDB持久化，在滿足save條件、手動save、正常關閉的時候資料都會被持久化；而異常關閉終止的時候資料會丟失

2、redis.conf 關閉snapshot，關閉aof

#save 900 1#save 300 10#save 60 10000rdbcompression nordbchecksum nodbfilename redis.rdbdir ./appendonly  no

操作

redis 127.0.0.1:6379> keys * (empty list or set)redis 127.0.0.1:6379> set name testOKredis 127.0.0.1:6379> saveOKredis 127.0.0.1:6379> set aa 1OKredis 127.0.0.1:6379> #重啟redisredis 127.0.0.1:6379> keys *                          #發現剛才沒有被儲存的key丟失了1) "name"

從上面的結果看出，關閉持久化，只有在手動save的時候資料都會被持久化，正常關閉的時候資料丟失。如果從一開始到關閉寫入資料的期間沒有手動save，則資料全部丟失，既然能手動save間接的說明了快照一直都存在，所以不能說是禁止snapshot，應該是禁止自動snapshot功能。

3、redis.conf 關閉snapshot，開啟aof

appendonly  yesappendfilename redis.aof# appendfsync alwaysappendfsync everysec# appendfsync nono-appendfsync-on-rewrite noauto-aof-rewrite-min-size 64mb

 操作

redis 127.0.0.1:6379> keys *1) "name"#修改開啟AOF參數，重啟資料庫：redis 127.0.0.1:6379> keys *(empty list or set)redis 127.0.0.1:6379> #資料庫裡面沒有記錄#查看日誌：#* DB loaded from append only file: 0.000 seconds#發現是從0位元組的aof檔案裡面同步資料，為什麼不同步rdb的資料？原來redis代碼裡面寫好了優先順序，AOF>RDB

查看原始碼 redis.c   grep 'DB loaded from' ./ -R

void loadDataFromDisk(void) {    long long start = ustime();    if (server.aof_state == REDIS_AOF_ON) {        if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)            redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);    } else {        if (rdbLoad(server.rdb_filename) == REDIS_OK) {            redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",                (float)(ustime()-start)/1000000);        } else if (errno != ENOENT) {            redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));            exit(1);        }        }}

這裡需要注意的是:當中途開啟AOF，重啟讓生效的時候，不能第2次正常重啟了

因為第一次重啟讓aof生效的時候，啟動redis已經讀取這個檔案了，導致此時的redis資料為空白的（優先順序）。第二次重啟，則會把這個空的資料save到RDB檔案，這樣導致RDB原有的資料被替換，導致資料丟失。所以一定要小心，為了避免悲劇的發生，當要重啟redis的時候最好都備份下RDB檔案。

redis 127.0.0.1:6379> keys *(empty list or set)redis 127.0.0.1:6379> set name ttOKredis 127.0.0.1:6379> saveOK#開啟aof參數#第一次重啟redis 127.0.0.1:6379> keys *   #如上面所說的優先順序原因:aof > rdb，結果為空白(empty list or set)#第2次正常重啟，把上面空的結果save到了RDB，資料丟失。此時的db是空的，日誌記錄 "* DB saved on disk"redis 127.0.0.1:6379> keys *(empty list or set)#資料已經被初始化了，資料丟失

這裡就有一個問題，比如在用redis的時候，剛開始只開啟RDB的持久方式，AOF沒有開啟，在跑一段時間之後想開啟AOF，那如何把RDB的資料直接寫到AOF檔案呢？有2種方法

a、在開啟AOF之前，先執行bgrewriteaof，再重啟

redis 127.0.0.1:6379> keys *                   #查看是否有資料(empty list or set)redis 127.0.0.1:6379> set name ttdOKredis 127.0.0.1:6379> keys *1) "name"redis 127.0.0.1:6379> bgsave                   #儲存資料Background saving startedredis 127.0.0.1:6379> keys *1) "name"#只有一個RDB檔案，沒有AOF檔案redis 127.0.0.1:6379> bgrewriteaof             #執行合并重寫功能，產生AOF檔案Background append only file rewriting started#這時候去開啟redis.conf 檔案中的aof參數（appendonly yes），重啟生效。#日誌裡面出現：* DB loaded from append only file: 0.000 secondsredis 127.0.0.1:6379> keys *                    #資料還在1) "name"#查看檔案[root@localhost data]# od -c redis.aof 0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S0000040   E   T  \r  \n   $   4  \r  \n   n   a   m   e  \r  \n   $   40000060  \r  \n   j   a   c   k  \r  \n0000070　

b、利用CONFIG GET/SET 的方法動態修改設定檔

redis 127.0.0.1:6379> BGSAVEBackground saving started#此時，只有rdb檔案#動態修改參數，把aof功能開啟：appendonly yesredis 127.0.0.1:6379> CONFIG SET appendonly yes        #動態修改參數OKredis 127.0.0.1:6379> CONFIG GET append*1) "appendonly"2) "yes"3) "appendfsync"4) "everysec"redis 127.0.0.1:6379>#aof檔案已經產生，並且有資料（同步rdb）#日誌裡面的資訊：* Background append only file rewriting started by pid 3165#因為參數是動態修改的，在重啟之後會失效，所以在維護的時候修改redis.conf檔案的參數即可

從上面的結果看出，redis重啟載入資料的時候，讀取aof的檔案要先於rdb檔案，所以盡量一開始開啟aof選項，不要在中途開啟。

通過日誌可以很清楚的知道redis通過那個檔案來取資料的：

RDB:   * DB loaded from disk: 0.000 secondsAOF： * DB loaded from append only file: 0.000 seconds

儲存資料則是

RDB：* DB saved on diskAOF:  * Calling fsync() on the AOF file

4、redis.conf 開啟snapshot，開啟aof

save 900 1save 300 10save 60 10000appendonly  yesappendfilename zhoujy.aof# appendfsync alwaysappendfsync everysec# appendfsync nono-appendfsync-on-rewrite noauto-aof-rewrite-min-size 64mb

通過上面的這些測試，已經說明RDB和AOF他們的操作方式，以及如重啟時的載入，重啟時將按照以下優先順序恢複資料到記憶體：

• 如果只配置AOF,重啟時載入AOF檔案恢複資料

• 如果同時 配置了RBD和AOF,啟動是只載入AOF檔案恢複資料

• 如果只配置RDB,啟動時候載入dump檔案恢複資料

四、Redis資料備份

備份很簡單，只需要把RDB，AOF的檔案複製備份起來就可以了

#redisA: A上產生測試資料redis 127.0.0.1:6379> set name test7.0.0.1:6379> set age 17OKredis 127.0.0.1:6379> keys *1) "age"redis 127.0.0.1:6379> bgsaveBackground saving started#redisB: B上沒有資料redis 127.0.0.1:6380> keys *(empty list or set)#複製A的檔案到B（rdb和aof檔案）cp redis/* redis2/  #修改許可權chown -R redis.redis *#重啟B 還原redis 127.0.0.1:6380> keys *1) "sex"

 

參考

http://redis.io/topics/persistence
http://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html
http://heylinux.com/archives/1932.html
http://database.51cto.com/art/201203/322144.htm