1.redis総務
実際に取引を指し、コマンドのセットは途中で他のコマンドを追加することはできません、シリアル順序で実行されますされて実行されます。バッチのニーズに対応するために使用されています。
Redisの中で実質的に次のように:
>マルチ
OK
>本INCR
QUEUED
> Execの
(整数)1
(整数)2
multi
そして、exec
トランザクションの開始と終了のサインです、真ん中には、トランザクション特定のコンテンツです。サービスの利用可能廃棄discard
コマンドは、すべてのトランザクションは、execの前に実行されません。
Redisのトランザクションは、次の特性があります。
1.すべての罪悪感
>set books python
ok
>multi
ok
>set a1 b1
QUEUED
>cbaafasfaf books linux
(error) ERR unknown command 'cbaafasfaf'
>set a2 b2
QUEUED
>exec
(error) EXECABORT Transaction discarded because of previous errors.
>get a1
(nil)
>get a2
(nil)
エラーが発生したときに目に見えるマルチ声明、命令ごとに一度入力するには、一度テストされる文の提出後の幹部は、トランザクションが実行されないことがわかります、文法エラーに直接返されます。
メイン債務2.不正ヘッド
>set books redis
ok
>multi
ok
>set k1 v1
QUEUED
>incr books
QUEUED
>set k2 v2
QUEUED
>exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
>get k1
"v1"
>get k2
"v2"
>get books
"redis"
目に見える、Redisのトランザクションは、命令が実行されて訂正します、ただ間違ったコマンドを立ち往生。これはなぜでしょうか?
実際に取引のRedis、厳格な取引ではない限り、明白特に明白な誤りの真ん中として、彼らは正しい命令になりますのみ間違った順序を放棄し、実行されます。そして、Redisのトランザクションのロールバックは、この操作をサポートしていません。
2.悲観的ロックと楽観的ロック
クライアントのデータは、データの誤作動を防ぐために、混乱の原因になります動作することをロック悲観的には、操作前のデータは、不正使用を防ぐために、さまざまの範囲をロックするデータを含むデータベーステーブルを操作することになります。
楽観的ロックは一部だけと思うが、おそらくロックされた間違ったデータを行くことができる、クライアントは基本的なデータの操作に影響を与えないだろうと信じています。
次のように具体的な動作は以下のとおりです。
データベースの実装を使用して、表および行ロックまたは他のロック機構:悲観的ロック
楽観的ロック:Redisの使用watch
、他の時計データを変更する要求である場合に達成する方法は、本質的にも、ロックが追加され、トランザクションが再開始要求を必要とする、実行に失敗します。Redisで、時計は専用トランザクションの開始前に使用することができ、またはエラーが発生することに注意してください。
次のように基本的な使用であります:
import redis
def key_for(user_id):
return 'account_{}'.format(user_id)
def bussiness(client,user_id):
key = key_for(user_id)
while True:
client.watch(key)
# 数值加倍
value = int(client.get(key))
value *= 2
#用管道提交事务
pipe = client.pipeline(translation=True)
pipe.multi()
pipe.set(key,value)
#尝试提交事务,成功时跳出循环;失败时重新尝试。
try:
pipe.exec()
break
except WatchError:
continue
return int(client.get(key))
client = redis.StructRedis()
user_id = 'abc'
client.setnx(key_for(user_id),5) #初始化
print(bussiness(client,user_id))
借用トランザクションパイプラインの複数のI / O操作は、効率を改善するために、単一のI / Oに圧縮することができます。パイプラインの使用を強制するためにpythonでクライアントRedisのトランザクションをコミットします。
悲観的ロックが安全であるが、実装、運用データでロックを取らなければならないにも関わらず、プロセスがロックを解除し、この過程で他のリクエストのみを待つことができます。同時の場合は、特に高い同時要求で、速度が本当に遅いです。これは、一般的にデータベースやその他の重要な状況に大きな変化にのみ適用されます。
楽観的ロックは主要求、データセキュリティ要件が要求されていない場合のように読み出し動作に適用され、非常に高い同時実行の要求の処理速度を向上させることができます。