続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi

いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→

[masaru_b_cl]

"いつも心に冪等性"

[wozaki]

“信頼性が要求される操作と失敗しやすい操作が混じっている場合は、同一のトランザクションで実行すると悪影響が大きい。失敗しやすい操作は非同期で実行することで、トランザクションの粒度は小さく保っ”

[griefworker]

いつも心に冪等性。

[jumperson]

リトライと冪等性にいて。RDBではトランザクションがあるのであまり意識しないところだが、FluentdやEmbulkをやっていくには必須らしい。

[efcl]

冪等性とトランザクション

[mergyi]

"いつも心に冪等性"

[HHR]

ログ先行書き込みの欠点はログが増えることだけなのか？

[civitaspo]

続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi

[yosuke_furukawa]

なんかDatomicを思い出した

[iekusup]

ほー。

[mazgi]

"いつも心に冪等性"

[toyama0919]

“Digdagの実装では、実際にほぼすべてのREST APIとDB操作が冪等になっており”

[sonots]

3年越し！スゴい！

[Songmu]

うおー、完結編待ってた