マイクロサービスにひそむ複雑さに立ち向かう - Qiita

のように書きます。突然でてきた「ランダム値」は何かというと、 クライアントAがロックを取得 クライアントAが何らかの理由により処理遅延(GCとかなんでもいい)し、許可されているロック時間を超えているのに気付かずアンロック ロックがタイムアウトした後、ロックを取得していたクライアントBのロックがアンロックされてしまった といったことが起きないように「自分がかけたロックのみアンロック」するために利用します。 これで解決かというと、厳密にはそうではなく、Redisのレプリケーションが非同期であるため、 クライアントAがロックを取得 レプリに書き込まれる前にマスターがクラッシュ フェイルオーバーし、レプリがマスターになる クライアントBが同じロックを取得 となり、ロック対象をA/B両方同時に保持してしまう可能性があります。 上記が許容できない場合を想定し、Redisチームは、お互いに完全に独立した

[roshi]

開発は楽しいと思うけど、これだけコスト払って得られるマイクロサービスのメリットって何なんだろうって思ってしまう。。

[ya--mada]

ん？自家製ロックでトランザクションという話？

[strawberryhunter]

分けちゃいけないところを分けた結果苦しんだように思えるんだけど、マイクロサービスってこんなもんなのかね。Kyashはリアルタイムで出金がわかるところが好きなのでがんばってほしいわ。

[turanukimaru]

マイクロサービスの問題と言うよりは集約にトランザクションスタート時の残高というか最終バージョンが入っていないのが問題と思われる。あとでちゃんと考える。

[lets_skeptic]

マイクロサービス化は、なんとなく当然の流れみたいな扱いされているけど、設計ミスるとホントに大惨事になるし設計が難しい。

[takezaki]

“キャンセルさせたい元APIでは冪等IDを呼び出し元で採番してリクエストしよう”

[pascal256]

後で読む

[wazpk6no]

最近、やたらもてはやされてるけどMSAは考え方の理解とそれに基づくシステム設計しないといけないからマジでむずいよ。合わないシステムに適用したら大変

[cpw]

分けるべきでないところをシステム分割しちゃったのかな？という印象。そうしなくちゃいけない理由でもあったのだろうか。

[n314]

App Engine 用のフレームワーク Slim3 が実装したグローバルトランザクションの話を思い出した。トランザクション管理だけのサービスって無いんかね。

[daishi_n]

決済のマイクロサービスはトランザクションをどうするか問題の最たるものだからね。

[odakaho]

“許容できないのであれば、先に残高減算してしまって、キャンセルAPIの実行に失敗したら残高をもどしてあげればいい”

[yamami78651]

他のシステムは気にせんでいいとかそんなことはないけど、決済は特にお金が絡むからエラーハンドリングができてなかったり、ロールバック漏れで損害になるんよな。

[baronhorse]

いい記事だわ