摘要：上一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)處理系統(tǒng)故障下一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)非事務(wù)型流水線為了確保數(shù)據(jù)的正確性，我們必須認(rèn)識(shí)到這一點(diǎn)在多個(gè)客戶(hù)端同時(shí)處理相同的數(shù)據(jù)時(shí)，不謹(jǐn)慎的操作很容易會(huì)導(dǎo)致數(shù)據(jù)出錯(cuò)。

上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第5節(jié)：處理系統(tǒng)故障
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第7節(jié)：非事務(wù)型流水線

為了確保數(shù)據(jù)的正確性，我們必須認(rèn)識(shí)到這一點(diǎn)：在多個(gè)客戶(hù)端同時(shí)處理相同的數(shù)據(jù)時(shí)，不謹(jǐn)慎的操作很容易會(huì)導(dǎo)致數(shù)據(jù)出錯(cuò)。本節(jié)將介紹使用Redis事務(wù)來(lái)防止數(shù)據(jù)出錯(cuò)的方法，以及在某些情況下，使用事務(wù)來(lái)提升性能的方法。

Redis的事務(wù)和傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的事務(wù)并不相同。在關(guān)系數(shù)據(jù)庫(kù)中，用戶(hù)首先向數(shù)據(jù)庫(kù)服務(wù)器發(fā)送begin，然后執(zhí)行各個(gè)相互一致的寫(xiě)操作和讀操作，最后，用戶(hù)可以選擇發(fā)送commit來(lái)確認(rèn)之前所做的修改，后者發(fā)送rollback來(lái)放棄那些修改。

在Redis里面也有簡(jiǎn)單的方法可以處理一連串相互一致的讀操作和寫(xiě)操作。正如之前介紹的那樣，Redis的事務(wù)以特殊命令multi為開(kāi)始，之后跟著用戶(hù)傳入的多個(gè)命令，最后以exec為結(jié)束。但是由于這種簡(jiǎn)單的事務(wù)在exec命令被調(diào)用之前不會(huì)執(zhí)行任何實(shí)際操作，所以用戶(hù)將沒(méi)辦法根據(jù)讀取到的數(shù)據(jù)來(lái)做決定。這個(gè)問(wèn)題看上去似乎無(wú)足輕重，但實(shí)際上無(wú)法以一致的形式讀取數(shù)據(jù)將導(dǎo)致某一類(lèi)型的問(wèn)題變得難以解決，除此之外，因?yàn)樵诙鄠€(gè)事務(wù)同時(shí)處理同一個(gè)對(duì)象時(shí)通常需要用到二階提交，所以如果事務(wù)不能以一致的形式讀取數(shù)據(jù)，那么二階提交將無(wú)法實(shí)現(xiàn)，從未導(dǎo)致一些原本可以成功執(zhí)行的事務(wù)淪落至失敗的地步。比如說(shuō)：在市場(chǎng)里面購(gòu)買(mǎi)一件商品，就是其中一個(gè)會(huì)因?yàn)闊o(wú)法以一致的形式讀取數(shù)據(jù)而變得難以解決的問(wèn)題，本節(jié)接下來(lái)將在實(shí)際環(huán)境中對(duì)這個(gè)問(wèn)題進(jìn)行介紹。

延遲執(zhí)行事務(wù)有助于提升性能
因?yàn)镽edis在執(zhí)行事務(wù)的過(guò)程中，會(huì)延遲執(zhí)行已入隊(duì)的命令直到客戶(hù)端發(fā)送exec命令為止。因此，包括本書(shū)使用的Python客戶(hù)端在內(nèi)的很多Redis客戶(hù)端都會(huì)等到事務(wù)包含的所有命令都出現(xiàn)了之后，才一次性地將multi命令、要在事務(wù)中執(zhí)行的一系列命令，以及exec命令全部發(fā)送給Redis，然后等待知道接受到所有命令的回復(fù)為止。這種【一次性發(fā)送多個(gè)命令，然后等待所有回復(fù)出現(xiàn)】的做法通常被成為流水線，它可以通過(guò)減少客戶(hù)端與Redis服務(wù)器之間的網(wǎng)絡(luò)通信次數(shù)來(lái)提示Redis在執(zhí)行多個(gè)命令時(shí)的性能。

最近幾個(gè)月，F(xiàn)ake Game公司發(fā)現(xiàn)他們?cè)谝粋€(gè)社交網(wǎng)站上推出的角色扮演網(wǎng)頁(yè)游戲正在變得越來(lái)越受歡迎。因此，關(guān)心玩家需求的Fake Game公司決定在游戲里面增加一個(gè)商品買(mǎi)賣(mài)市場(chǎng)，讓玩家們可以在市場(chǎng)里面銷(xiāo)售和購(gòu)買(mǎi)商品。本節(jié)接下來(lái)的內(nèi)容將介紹設(shè)計(jì)和實(shí)現(xiàn)這個(gè)商品買(mǎi)賣(mài)市場(chǎng)的方法，并說(shuō)明如何按需對(duì)這個(gè)商品買(mǎi)賣(mài)市場(chǎng)進(jìn)行擴(kuò)展。

下表展示了游戲中用于表示用戶(hù)信息和用戶(hù)包裹的結(jié)構(gòu)：用戶(hù)信息存儲(chǔ)在一個(gè)散列里面，散列的各個(gè)鍵值對(duì)分別記錄了用戶(hù)的姓名、用戶(hù)擁有的錢(qián)數(shù)等屬性。用戶(hù)包裹使用一個(gè)集合來(lái)表示，它記錄了包裹里面每件商品的唯一編號(hào)。

商品買(mǎi)賣(mài)市場(chǎng)的需求非常簡(jiǎn)單：一個(gè)用戶(hù)（賣(mài)家）可以將自己的商品按照給定的價(jià)格放到市場(chǎng)上進(jìn)行銷(xiāo)售，當(dāng)另一個(gè)用戶(hù)（買(mǎi)家）購(gòu)買(mǎi)這個(gè)商品時(shí)，賣(mài)家就會(huì)收到錢(qián)。另外，本節(jié)實(shí)現(xiàn)的市場(chǎng)只根據(jù)商品的價(jià)格來(lái)進(jìn)行排序，稍后章節(jié)將介紹如何在市場(chǎng)里面實(shí)現(xiàn)其他排序。

為了將被銷(xiāo)售商品的全部信息都存儲(chǔ)到市場(chǎng)里面，我們會(huì)將商品的ID和賣(mài)家的ID拼接起來(lái)，并將拼接的結(jié)果用作成員存儲(chǔ)到市場(chǎng)有序集合里面，而商品的售價(jià)則用作成員的分值。通過(guò)將所有數(shù)據(jù)都包含在一起，我們極大簡(jiǎn)化了實(shí)現(xiàn)商品買(mǎi)賣(mài)市場(chǎng)所需的數(shù)據(jù)結(jié)構(gòu)，并且，因?yàn)槭袌?chǎng)里面的所有商品都按照價(jià)格排序，所以針對(duì)商品的分頁(yè)功能和查找功能都可以很容易地實(shí)現(xiàn)。

下表展示了一個(gè)只包含數(shù)個(gè)商品的市場(chǎng)例子：

上表表示的商品買(mǎi)賣(mài)市場(chǎng)，第一行數(shù)據(jù)表示：用戶(hù)4正在銷(xiāo)售商品Item，售價(jià)為35塊錢(qián)

既然我們已經(jīng)知道了實(shí)現(xiàn)商品買(mǎi)賣(mài)市場(chǎng)所需的數(shù)據(jù)結(jié)構(gòu)，那么接下來(lái)該考慮如何實(shí)現(xiàn)市場(chǎng)的商品上架功能了。

為了將商品放到市場(chǎng)上進(jìn)行銷(xiāo)售，程序除了要使用multi命令和exec命令之外，還需要配合使用watch命令，有時(shí)候甚至還會(huì)用到unwatch和discard命令。在用戶(hù)使用watch命令對(duì)鍵進(jìn)行監(jiān)視之后，直到用戶(hù)執(zhí)行exec命令的這段時(shí)間里面，如果有其他客戶(hù)端搶先對(duì)任何被監(jiān)視的鍵進(jìn)行了替換、更新或刪除等操作，那么當(dāng)用戶(hù)嘗試執(zhí)行exec命令的時(shí)候，事務(wù)將失敗并返回一個(gè)錯(cuò)誤（之后用戶(hù)可以選擇重試事務(wù)或者放棄事務(wù)）。通過(guò)使用watch、multi/exec、unwatch/discard等命令。程序可以在執(zhí)行某些重要操作的時(shí)候，通過(guò)確保資金正在使用的數(shù)據(jù)沒(méi)有發(fā)生變化來(lái)避免數(shù)據(jù)出錯(cuò)。

什么是discard？
unwatch命令可以在watch命令執(zhí)行之后，multi命令執(zhí)行之前對(duì)連接進(jìn)行重置（reset）；同樣地，discard命令也可以在multi命令執(zhí)行之后、exec命令執(zhí)行之前對(duì)連接進(jìn)行重置。這也就是說(shuō)，用戶(hù)在使用watch監(jiān)視一個(gè)或多個(gè)鍵。接著使用multi開(kāi)始一個(gè)新的事物，并將多個(gè)命令入隊(duì)到事物隊(duì)列之后，仍然可以通過(guò)發(fā)送discard命令來(lái)取消watch命令并清空所有已入隊(duì)命令。本章展示的例子都沒(méi)有用到discard，主要原因在于我們已經(jīng)清楚的知道自己是否想要執(zhí)行multi/exec或者unwatch，所以沒(méi)有必要在這些例子里面使用discard。

在將一件商品放到市場(chǎng)上進(jìn)行銷(xiāo)售的時(shí)候，程序需要將被銷(xiāo)售的商品添加到記錄市場(chǎng)正在銷(xiāo)售商品的有序集合里面，并且在添加操作執(zhí)行的過(guò)程中，監(jiān)視賣(mài)家的包裹以確保被銷(xiāo)售的商品的確存在于賣(mài)家的包裹當(dāng)中。

下面代碼展示了這一操作的具體實(shí)現(xiàn)：

import time
import redis

def list_item(conn,itemid,sellerid,price):
    inventory="inventory:%s"%sellerid
    item="%s.%s"%(itemid,sellerid)
    end=time.time()+5
    pipe=conn.pipeline()

    while time.time()
上面函數(shù)的行為就和我們之前描述的一樣，它首先執(zhí)行一些初始化步驟，然后對(duì)賣(mài)家的包裹進(jìn)行監(jiān)視，驗(yàn)證賣(mài)家想要銷(xiāo)售的商品是否仍然存在于賣(mài)家的包裹當(dāng)中，如果是的話，函數(shù)就會(huì)將被銷(xiāo)售的商品添加到買(mǎi)賣(mài)市場(chǎng)里面，并從賣(mài)家的包裹中移除該商品。正如函數(shù)中的while循環(huán)所示，在使用watch命令對(duì)包裹進(jìn)行監(jiān)視的過(guò)程中，如果包裹被更新或者修改，那么程序?qū)⒔邮盏藉e(cuò)誤并進(jìn)行重試。
下表展示了當(dāng)Frank（用戶(hù)ID為17）嘗試以97塊錢(qián)的價(jià)格銷(xiāo)售ItemM時(shí)，list_item()函數(shù)執(zhí)行的過(guò)程：
watch("inventory:17") #監(jiān)視包裹發(fā)生的任何變化

鍵名：inventory:17 類(lèi)型：set

ItemL
ItemM
ItemN


sismermber("inventory:17","ItemM") #確保被銷(xiāo)售的物品仍然存在于Frank的包裹里面

鍵名：inventory:17 類(lèi)型：set

ItemL
ItemM
ItemN



鍵名：market 類(lèi)型：zset

ItemA.4:35
ItemC.7:48
ItemE.2:60
ItemG.3:73


#因?yàn)闆](méi)有一個(gè)Redis命令可以在移除集合元素的同時(shí)，將被移除的元素改名并添加到有序集合里面
#所以這里使用了zadd和srem兩個(gè)命令來(lái)實(shí)現(xiàn)這一操作
zadd("market","ItemM.17",97）
srem("inventory:17","ItemM")

鍵名：inventory:17 類(lèi)型：set

ItemL
ItemN



鍵名：market 類(lèi)型：zset

ItemA.4:35
ItemC.7:48
ItemE.2:60
ItemG.3:73
ItemM.17:97


因?yàn)槌绦驎?huì)確保用戶(hù)只能銷(xiāo)售他們自己所擁有的，所以在一般情況下，用戶(hù)都可以順利地將自己想要銷(xiāo)售的商品添加到商品買(mǎi)賣(mài)市場(chǎng)上面，但是正如之前所說(shuō)，如果用戶(hù)的包裹在watch執(zhí)行之后直到exec執(zhí)行之前的這段時(shí)間內(nèi)發(fā)送了變化，那么添加操作將執(zhí)行失敗并重試。
在弄懂了怎樣將商品放到市場(chǎng)上銷(xiāo)售之后，接下來(lái)讓我們來(lái)了解一下怎樣從市場(chǎng)上購(gòu)買(mǎi)商品。
購(gòu)買(mǎi)商品
下面的函數(shù)展示了從市場(chǎng)里面購(gòu)買(mǎi)一件商品的具體方法：程序首先使用watch對(duì)市場(chǎng)以及買(mǎi)家的個(gè)人信息進(jìn)行監(jiān)視，然后獲取買(mǎi)家擁有的錢(qián)數(shù)以及商品的售價(jià)，并檢查買(mǎi)家是否有足夠的錢(qián)來(lái)購(gòu)買(mǎi)該商品。如果買(mǎi)家沒(méi)有足夠的錢(qián)，那么程序會(huì)取消事務(wù)；相反，如果買(mǎi)家的錢(qián)足夠，那么程序首先會(huì)將買(mǎi)家支付的錢(qián)轉(zhuǎn)移給賣(mài)家，然后將售出的商品移動(dòng)至買(mǎi)家的包裹，并將該商品從市場(chǎng)中移除。當(dāng)買(mǎi)家的個(gè)人信息或者商品買(mǎi)賣(mài)市場(chǎng)出現(xiàn)變化而導(dǎo)致WatchError移除出現(xiàn)時(shí)，程序進(jìn)行重試，其中最大重試時(shí)間為10秒：
import time
import redis

def purchase_item(conn,buyerid,itemid,sellerid,lprice):
    buyer="users:%s"%buyerid
    seller="users:%s"%sellerid
    item="%s.%s"%(itemid,sellerid)

    inventory="inventory:%s"%buyerid
    end=time.time()+10
    pipe=conn.pipeline()

    while time.time()funds:
                pipe.unwatch()
                return None

            #先將買(mǎi)家支付的錢(qián)轉(zhuǎn)移給賣(mài)家，然后再將購(gòu)買(mǎi)的商品移交給買(mǎi)家
            pipe.multi()
            pipe.hincrby(seller,"funds",int(price))
            pipe.hincrby(buyer,"funds",int(-price))
            pipe.sadd(inventory,itemid)
            pipe.zrem("market:",item)
            pipe.execute()
            return True
        except redis.exceptions.WatchError:
            #如果買(mǎi)家的個(gè)人信息或者商品買(mǎi)賣(mài)市場(chǎng)在交易的過(guò)程中出現(xiàn)了變化，那么進(jìn)行重試。
            pass
    return False
在執(zhí)行商品購(gòu)買(mǎi)操作定位時(shí)候，程序除了需要花費(fèi)大量時(shí)間來(lái)準(zhǔn)備相關(guān)數(shù)據(jù)之外，還需要對(duì)商品買(mǎi)賣(mài)市場(chǎng)以及買(mǎi)家的個(gè)人信息進(jìn)行監(jiān)視：監(jiān)視商品買(mǎi)賣(mài)市場(chǎng)是為了確保買(mǎi)家想要購(gòu)買(mǎi)的商品仍然有售（或者在商品已經(jīng)被其他人買(mǎi)走時(shí)進(jìn)行提示），而監(jiān)視買(mǎi)家的個(gè)人信息則是為了驗(yàn)證買(mǎi)家是否有足夠的錢(qián)來(lái)購(gòu)買(mǎi)自己想要的商品。
當(dāng)程序確認(rèn)商品仍然存在并且買(mǎi)家有足夠的錢(qián)的時(shí)候，程序會(huì)將被購(gòu)買(mǎi)的商品移動(dòng)到買(mǎi)家的包裹里面，并將買(mǎi)家支付的錢(qián)轉(zhuǎn)移給賣(mài)家。
在觀察了市場(chǎng)上展示的商品之后，Bill（用戶(hù)ID為27）決定購(gòu)買(mǎi)Frank在市場(chǎng)上銷(xiāo)售的ItemM，下圖展示了購(gòu)買(mǎi)操作執(zhí)行期間，數(shù)據(jù)結(jié)構(gòu)的變化：
watch("market:"."users:27") #對(duì)物品買(mǎi)賣(mài)市場(chǎng)以及Bill的個(gè)人信息進(jìn)行監(jiān)視

鍵名：market 類(lèi)型：zset

ItemA.4:35
ItemC.7:48
ItemE.2:60
ItemG.3:73
ItemM.17:97



鍵名：users:27 類(lèi)型：hash

name：Bill
funds：125



鍵名：users:17 類(lèi)型：hash

name：Bill
funds：43


#驗(yàn)證物品的售價(jià)是否并為改變
#以及Bill是否有足夠的錢(qián)來(lái)購(gòu)買(mǎi)該物品
price=pipe.zscore("market:","ItemM.17")
funds=int(pipe.hget("users:27","funds"))
if price!=97 or price>funds:
pipe.sadd("inventory:27","ItemM")
pipe.zrem("market:","ItemM.17")

鍵名：market 類(lèi)型：zset

ItemA.4:35
ItemC.7:48
ItemE.2:60
ItemG.3:73



鍵名：users:27 類(lèi)型：hash

name：Bill
funds：28



鍵名：users:17 類(lèi)型：hash

name：Bill
funds：140


如果商品買(mǎi)賣(mài)市場(chǎng)有序集合或者Bill的個(gè)人信息在watch和exec執(zhí)行之前發(fā)生了變化，那么purchase_item()將進(jìn)行重試，或者在重試操作超時(shí)之后放棄此購(gòu)買(mǎi)操作。
為什么Redis沒(méi)有實(shí)現(xiàn)典型的加鎖功能？
在訪問(wèn)以寫(xiě)入為目的的數(shù)據(jù)的時(shí)候關(guān)系數(shù)據(jù)會(huì)對(duì)被訪問(wèn)的數(shù)據(jù)進(jìn)行加鎖，知道事務(wù)被提交或者被回滾為止。如果有其他客戶(hù)端視圖對(duì)被加鎖的數(shù)據(jù)行進(jìn)行寫(xiě)入，那么該客戶(hù)端將被阻塞，直到第一個(gè)事務(wù)執(zhí)行完畢為止，加速在實(shí)際使用中非常有效，基本上所有關(guān)旭數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了這種加鎖功能，它的缺點(diǎn)在于，持有鎖的客戶(hù)端運(yùn)行越慢，等待解鎖的客戶(hù)端被阻塞的時(shí)間就越長(zhǎng)。
因?yàn)榧渔i有可能會(huì)造成長(zhǎng)時(shí)間的等待，所以Redis為了盡可能減少客戶(hù)端的等待時(shí)間，并不會(huì)在執(zhí)行watch命令時(shí)對(duì)數(shù)據(jù)進(jìn)行加鎖。相反的，Redis只會(huì)在數(shù)據(jù)已經(jīng)被其他客戶(hù)端搶先修改的情況下，通知執(zhí)行了watch命令的客戶(hù)端，這種做法被稱(chēng)為樂(lè)觀鎖，而關(guān)系數(shù)據(jù)庫(kù)實(shí)際執(zhí)行的加鎖操作則被稱(chēng)為悲觀鎖。樂(lè)觀鎖在實(shí)際使用中同樣非常有效，因?yàn)榭蛻?hù)端永遠(yuǎn)不必花時(shí)間去等待第一個(gè)獲得鎖的客戶(hù)端：他們只需要在自己的事務(wù)執(zhí)行失敗時(shí)進(jìn)行重試就可以了。

這一節(jié)介紹了如何組合使用watch、multi和exec命令對(duì)多種類(lèi)型的數(shù)據(jù)進(jìn)行操作，從而實(shí)現(xiàn)游戲中的商品買(mǎi)賣(mài)市場(chǎng)。除了目前已有的商品買(mǎi)賣(mài)功能之外，我們還可以為整個(gè)市場(chǎng)添加商品拍賣(mài)和商品限時(shí)銷(xiāo)售等功能，或者讓市場(chǎng)支持更多不同類(lèi)型的商品排序方式，又或者基于后面的技術(shù)，給市場(chǎng)添加更高級(jí)的搜索和過(guò)濾公布。
當(dāng)有多個(gè)客戶(hù)端同時(shí)對(duì)相同的數(shù)據(jù)進(jìn)行操作時(shí)，正確的使用事務(wù)可以有效的防止數(shù)據(jù)錯(cuò)誤的發(fā)生。而接下來(lái)的一節(jié)將展示在無(wú)須擔(dān)心數(shù)據(jù)被其他客戶(hù)端修改了的情況下，如果以更快地速度執(zhí)行操作。
上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第5節(jié)：處理系統(tǒng)故障
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第7節(jié)：非事務(wù)型流水線