[B! トランザクション][システム] kyo

kyo_ago id:kyo_ago

トランザクションとシステムに関するkyo_agoのブックマーク (2)

分散ロックという名の過ち - Software Transactional Memo
TL;DR; 「分散ロック」が分散システムの設計図に登場した時だいたいその設計は間違っていて本当に必要なものはトランザクションだ並行システムを実装する際にロックを用いるのはとても自然なことだ。僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
kyo_ago 2018/03/26
algorithm

distributed system

トランザクション

distributed

ロック

google

database

システム

software
リンク
[システム間連携]接続方向を逆転させるとうまくいく - Qiita
システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。システム間の接続非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、
kyo_ago 2015/12/17
Class

class

api

WebSocket

Web

システム

トランザクション

サーバ

void

データ
リンク
1