メルペイにおけるお客さま残高の管理手法 | メルカリエンジニアリング
はじめに この記事はMERPAY TECH OPENNESS MONTHの19日目の記事です。 こんにちは。株式会社メルペイのPayment Platformチームでエンジニアをしている knsh14 です。 メルペイの様々な決済手段でどのように決済の整合性を保とうとしているかは15日目の記事で紹介しました。 メルペイでは決済の手段をもつマイクロサービス(Payment Service)と決済のための原資を管理するマイクロサービス(Balance Service)を分けています。 今回はこのお客さまの残高を正しく管理するためのマイクロサービスがいかにして正確に増減をしているかを説明します。 Balance Service の提供する機能 Balance Service ではお客さまの残高を増減させるという機能を提供しています。 決済のフローや他のマイクロサービスとの整合性の管理などは上位レ
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
トランザクション技術とリカバリとInnoDBパラメータを調べた - たにしきんぐダム
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
同時実行制御とSQLite3 - Qiita
Intro 同時実行制御とは, 共有リソースにアクセスする複数のトランザクションを, いかに並列処理しつつ競合によるデータ破壊を回避するかを扱う分野である. 昨今のアプリケーションではクライアントが複数いることは珍しくない. 同時アクセスを許容せず, クライアントからの要求を直列的に処理できれば同時実行制御の課題は解決されるが, アプリケーションのレスポンスは極端に低下し使い物にならない. パフォーマンスの低下を抑えるためにトランザクションを並列化し, かつリソースの整合性を保証しなければならないため, 同時実行制御を考える必要が出てくる. Conflict 並列処理されるトランザクションの競合を制御しなかった場合の問題は主に4種類ある. 基本的にデータの一貫性は保証されない. Dirty Read (w-r) コミットされていないデータを別のトランザクションから参照できてしまう問題. ト
My sqlで遭遇したトランザクションとロックのお話
RDBMSのトランザクション、楽観ロック、悲観ロックがわかっている人向けのお話。 並行で処理が走っていて、同時にトランザクションが走った時、データベースから取得できる値がどうなるか？というお話Read less
Rails4のtransactionでハマった <- これは私の間違いでした - CubicLouve
申し訳ありません この記事完全に自分の間違いでした。 まず、自分のrailsアプリでは、、もろもろの深淵な理由で、モデルを作るときにActiveRecord::Baseを直接継承せずに、全てのモデルに共通で使うモデルを再定義しています。 なぜこんな事をしているかというと、これまた深淵な理由で、connection poolingができないからです。 まあ、そのモデルの基底クラスでゴニョゴニョしているせいで、ActiveRecord::Base使ってDBに繋ぎに行く場合と、モデルからDBに繋ぎに行く場合でコネクションが別々になっていました。 本当に申し訳ないです。。。。 つまりこの問題は、私のrailsアプリのみで起こる問題でした。。。。。 普通にrailsアプリを作っていれば、問題なくロールバックできます。(ActiveRecord::Baseを直接継承して試してみたら問題なくロールバック
TX本勉強会終了 - 急がば回れ、選ぶなら近道
先日をもって無事に読了しました。記念に記録しておきます。 読んだ本はこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー
A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スレッドIDを利用したMySQLのデッドロック解析手法
外部キー制約に伴うロックの小話