Code Monkey home page Code Monkey logo

isucon9-qualify's Introduction

isucon9-qualify

ディレクトリ構成

├── bench        # ベンチマーカーなどが依存するパッケージのソースコード
├── cmd          # ベンチマーカーなどのソースコード
├── docs         # 運営が用意したイベント当日や開発に利用した各種ドキュメント
├── initial-data # 初期データ作成
├── provisioning # セットアップ用ansible
└── webapp       # 各言語の参考実装

ISUCARIについて

ISUCARIの使い方、紹介はISUCARI アプリケーション仕様書を、決済と配送のために利用している外部サービスAPIの詳細は外部サービスAPIの仕様を参照してください。

ストーリー

ISUCARIは椅子を売りたい人/買いたい人をつなげるフリマアプリです。

  • 日々開発が進められ、先日もBump機能がリリースされたばかり
  • 世界的な椅子ブームを追い風に順調に成長を続け
  • さらなる成長を見込み社長は自腹による「イスコイン還元キャンペーン」を企画
  • しかし「イスコイン還元キャンペーン」の驚異的な拡散力により負荷に耐えられないことが発覚
  • 社長「緊急メンテナンスをいれていいので18時までに改修しろ。18時にプロモーション開始だ」

商品取得APIと更新の反映について

ISUCARIには以下の商品取得APIがあります。

  • 新着一覧
  • カテゴリ毎新着一覧
  • ユーザ毎一覧
  • 取引一覧
  • 商品詳細

商品が出品・編集された場合は、カテゴリ毎新着一覧、ユーザ毎一覧、取引一覧、商品詳細APIに即座に反映してください。 編集・購入された商品については、全ての商品一覧・詳細取得APIで即座に情報を更新してください。 古いデータの削除、非表示はベンチマーク上で許可されません。各商品一覧取得APIが一度に返す商品数は初期実装と同じ状態を保つ必要があります。 新着一覧については、上記の制限を満たした上でよりユーザにあわせた商品の一覧を返すことで、購入の機会を増やすことができます。

キャンペーン機能

POST /initialize のレスポンスにて、イスコイン還元キャンペーンの「還元率の設定」を返すことができます。この還元率によりユーザが増減します。

POST /initialize のレスポンスは JSON 形式で

{
  "campaign": 0,
  "language": "実装言語"
}

campaignが還元率の設定となります。有効な値は 0 以上 4 以下の整数で 0 の場合はキャンペーン機能が無効になります。

languageについては別の項目で説明しています。

なお、イスコイン還元の費用が下で説明するスコアから引かれることはありません。

ベンチマーク走行

ベンチマーク走行は以下のように実施されます。

  1. 初期化処理の実行 POST /initialize(20秒以内)
  2. アプリケーション互換性チェックの走行(適宜: 数秒〜数十秒)
  3. 負荷走行(60秒)
  4. 負荷走行後の確認(適宜: 数秒〜数十秒)

各ステップで失敗が見付かった場合にはその時点で停止します。 ただし、負荷走行中のエラーについては、タイムアウトや500エラーを含む幾つかのエラーについては無視され、ベンチマーク走行が継続します。

また負荷走行が60秒行われた後、レスポンスが返ってきていないリクエストはすべて強制的に切断されます。 その際にnginxのアクセスログにステータスコード499が記録されることがありますが、これらのリクエストについては減点の対象外です。

スコア計算

スコアは取引が完了した商品(椅子)の価格の合計(イスコイン) をベースに以下の計算式で計算されます。

取引が完了した商品(椅子)の価格の合計(イスコイン) - 減点 = スコア(イスコイン)

以下の条件のエラーが発生すると、失格・減点の対象となります。

  • 致命的なエラー
    • 1回以上で失格
    • メッセージの最後に (critical error) が付与されます
  • HTTPステータスコードやレスポンスの内容などに誤りがある
    • 1回で500イスコイン減点、10回以上で失格
  • 一定時間内にレスポンスが返却されない・タイムアウト
    • 200回を超えたら100回毎に5000イスコイン減点、失格はなし
    • メッセージの最後に (タイムアウトしました) が付与されます

HTTPステータスコードは、基本的に参照実装と同一のものを想定しています。またベンチマーカーのメッセージは同一のメッセージを1つにまとめます。表示されているメッセージの数とエラー数は一致しないことがあります。

また減点により0イスコイン以下になった場合は失格となります。

POST /initialize での実装言語の出力

POST /initialize のレスポンスにて、本競技で利用した言語を出力してください。

POST /initialize のレスポンスは次のような JSON 形式になります。

{
  "campaign": 0,
  "language": "実装言語"
}

languageの値が実装に利用した言語となります。languageが空の場合はベンチマーカーは失敗と見なされます。

アプリケーションおよびベンチマーカーの起動方法

こちらのblogでも紹介しています。参考にしてください http://isucon.net/archives/53805209.html

前準備

初期データを生成する。インターネットからダウンロードするので注意。

$ make init

ベンチマーカー

Version: Go 1.21 or later

build

Dockerを使う方法もある。

# ベンチマーカーbuild
$ make
$ ./bin/benchmarker

実行オプション

$ ./bin/benchmarker -help
Usage of isucon9q:
  -allowed-ips string
        allowed ips (comma separated)
  -data-dir string
        data directory (default "initial-data")
  -payment-port int
        payment service port (default 5555)
  -payment-url string
        payment url (default "http://localhost:5555")
  -shipment-port int
        shipment service port (default 7001)
  -shipment-url string
        shipment url (default "http://localhost:7001")
  -static-dir string
        static file directory (default "webapp/public/static")
  -target-host string
        target host (default "isucon9.catatsuy.org")
  -target-url string
        target url (default "http://127.0.0.1:8000")
  • HTTPとHTTPSに両対応
    • 証明書を検証するのでHTTPSは面倒
  • -allowed-ipsオプションは他チームからの嫌がらせを防ぐために作られたオプションで、基本的に利用する必要はない
    • 利用する場合はisucariアプリケーションのIPアドレスを指定する
  • 外部サービス2つを自前で起動するので、いい感じにするならnginxを立てている必要がある
  • nginxでいい感じにするなら以下の設定が必須

外部サービス

実行オプション

$ ./bin/shipment -help
Usage of shipment:
  -data-dir string
        data directory (default "initial-data")
  -port int
        shipment service port (default 7001)

$ ./bin/payment -help
Usage of payment:
  -port int
        payment service port (default 5555)

注意点

nginxでいい感じにするなら以下の設定が必須

  • proxy_set_header Host $http_host;
    • shipmentのみ必須
  • proxy_set_header X-Forwarded-Proto "https";
    • HTTPSでないなら不要

webapp 起動方法

cd webapp/sql

# databaseとuserを初期化する
mysql -u root < 00_create_database.sql

# データを流し込む
cd ..
./init.sh

cd webapp/go
make
./isucari

アプリケーションの動作確認

GET / へアクセスすることで、トップページにアクセスすることができます。 画面の「新規会員登録」から、ユーザを作成あるいは以下のテスト用ユーザが利用できます

id password
isudemo1 isudemo1
isudemo2 isudemo2
isudemo3 isudemo3

Dockerを利用する

前準備を行った上で実行

webapp

cd webapp
docker compose up

benchmarker

# benchmarkerのbuild
docker build -t isucari-benchmarker -f bench/Dockerfile .

# benchmarkerの実行(Linuxは --add-host host.docker.internal:host-gateway を追加)
docker run -p 5678:5678 -p 7890:7890 -i isucari-benchmarker /opt/go/benchmarker -target-url http://host.docker.internal -data-dir /initial-data -static-dir /static -payment-url http://host.docker.internal:5678 -payment-port 5678 -shipment-url http://host.docker.internal:7890 -shipment-port 7890

external service

以上だけでもベンチマークを実行することはできますが、外部サービスを起動しないと購入などのアクションを行えないため、外部サービスは別途起動する必要があります。

docker compose up

手元のマシンのIPアドレスが192.0.2.2の場合は以下のコマンドを実行します。ベンチマーク走行時にこの値は書き換わるので、ベンチマーク走行後に確認したい場合も都度実行する必要があります。

$ cat initialize.json
{
  "payment_service_url": "http://192.0.2.2:5556",
  "shipment_service_url": "http://192.0.2.2:7002"
}

$ curl -XPOST http://127.0.0.1:8000/initialize \
-H 'Content-Type: application/json' \
-d @initialize.json

なお外部サービス(の決済サービスAPI)はアプリケーションとブラウザ両方から同じURLでアクセスできる必要があります。

Ansibleを利用する場合

provisioningを参照

TLS証明書について

以下のrepoを利用して *.t.isucon.pw の証明書を利用している。

https://github.com/KOBA789/t.isucon.pw

証明書が古い場合、更新するスクリプトを用意している。

sudo /etc/nginx/update_cert.sh

ホスト名

それぞれのアプリケーションのホスト名のprefixは以下になっている。

host prefix 用途
isucari. isucariアプリケーション
payment payment service
shipment shipment service
bp benchmarker用のpayment service
bs benchmarker用のshipment service

以下の点に気をつけること。

  • payment-serviceはブラウザとisucariアプリケーション両方からアクセスするため、ローカルとisucariアプリケーションの両方から同じホスト名でアクセスできる必要がある
    • shipment serviceはisucariアプリケーションだけでもよいが、今回は全部同じ設定をする方法を紹介する
  • shipment serviceはAnsibleではHTTPSで提供されているが、HTTPに変更したい場合はnginx上のproxy_set_header X-Forwarded-Proto "https";を削除する必要がある

なのでisucariアプリケーションを203.0.113.1、ベンチマーカーのIPアドレスが192.0.2.1だった場合、以下のように /etc/hosts を指定する。

共通

192.0.2.1 bp.t.isucon.pw
192.0.2.1 bs.t.isucon.pw
192.0.2.1 payment.t.isucon.pw
192.0.2.1 shipment.t.isucon.pw

ローカル

203.0.113.1 isucari.t.isucon.pw

もちろんDNSの設定をすれば問題ない。その場合は証明書を自分で用意するか、HTTPで提供すること。ISUCON9予選本番では外部サービスはDNSを設定、競技者が利用するisucariアプリケーションはDNSを通さずに利用した。これは競技者は同じ証明書・host名を使い回していたためである。

initialize

$ cat initialize.json
{
  "payment_service_url": "https://payment.t.isucon.pw",
  "shipment_service_url": "https://shipment.t.isucon.pw"
}

$ curl -XPOST https://isucari.t.isucon.pw/initialize \
-H 'Content-Type: application/json' \
-d @initialize.json

ベンチマーカー

isucariアプリケーションのIPアドレスが203.0.113.1なら以下のように実行する。

/home/isucon/isucari/bin/benchmarker -target-url https://203.0.113.1 -target-host isucari.t.isucon.pw -data-dir /home/isucon/isucari/initial-data/ -static-dir /home/isucon/isucari/webapp/public/static/ -payment-url https://bp.t.isucon.pw -shipment-url https://bs.t.isucon.pw

なお、hostsを指定しているか、DNSが設定されているなら-target-hostは指定する必要はなく、-target-url https://isucari.t.isucon.pwという指定でよい。

運営側のブログ

技術情報などについても記載されているので参考にしてください。

サポートするMySQLのバージョン

MySQL 8.0にて動作確認しています。

ただし、nodejsでアプケーションを起動する場合、MySQL 8.0の認証方式によっては動作しないことがあります。 詳しくは、 #316 を参考にしてください

使用データの取得元

isucon9-qualify's People

Contributors

catatsuy avatar chibiegg avatar cubicdaiya avatar dependabot[bot] avatar gfx avatar kazeburo avatar koba789 avatar nagarei avatar owatan avatar renovate[bot] avatar shoma avatar sota1235 avatar walf443 avatar ykzts avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

isucon9-qualify's Issues

getUserIDをgetUserにする

毎度あると思うが

  • 毎回 user をselectする負荷となる
  • select userが多いので読みやすく

shipment serviceの実装

# /create
| isucari | == address => | shipment service |
                name
            <=   id    ==
 (initial)

# /request
| isucari | == id => | shipment service |
        <= url (/accept) ==
(wait_pickup)

# /accept
| operator | == GET => | shipment service |

([sync] shipping)

# /status
| isucari | == id =>  | shipment service |
          <= status ==

(shipping, done)
  • URLはQRコードに入れて返す
  • データベースは欲しいが、ベンチマーカからも使うことを考えるとオンメモリで持っておきたい

cf:

payment serviceの実装

| user | == shop id => (CORS API) | payment service |
          card number

         <=  token  ==


| user | == token => | isucari | == token  => | payment service |
                                   api key

                                 <= result ==
  • Originがどこからでもpayment serviceのCORS APIは許容する
    • 本当はダメなのでコメントなどにも記述しておく
  • APIはJSON API
  • API Keyはあらかじめ決めておく
  • tokenは期限があり、一度だけ使える
    • 今回はオンメモリで1台前提にするのでDBは使わない
    • tokenはshop idとカードナンバーがセットで生成するが、今回はshop idは1つしかない前提なのでチェックするだけで良い
  • card numberは16進数の8桁の数字で、絶対に決済が成功するものと、失敗するものが存在する
  • resultに決済が成功したかどうかが返っている
  • Goで作って、ベンチマーカーと魔合体できるように作る

refs #7
refs #6

postShipの処理フロー

postShip
Sellerがアクセス
shippings.status をinitialからwait_pickupに変更する
リクエストパラメータは item_id

  • select seller
    -- sellerの存在チェック
  • select transaction_evidence
    -- レコードの存在チェック
    -- sellerのチェック
    -- transaction_evidence.id の取得
  • begin
  • select item for update
    -- 存在チェック
    -- statusチェック
  • select transaction_evidence for update (by primary key)
    -- status チェック
  • select shippings for update
  • Call ShipmentRequest API
  • update shippings
  • commit

Shipping APIが遅くなることで、itemのlock時間が伸びる

実際にはtransactionは必要なく
item_idからtransaction_evidence.id を取得して、 API呼んで update shippings だけでよい
商品の売れた数だけくる

初期実装アプリケーションの最小実装

とりあえず骨子となる機能だけを作る。

テーブル構造

  • users
  • items
  • transaction_evidences
  • shippings

パス一覧

  • GET /users/{user_id}.json
  • GET /items/{item_id}.json
  • POST /sell
  • POST /buy
  • POST /ship
  • POST /ship_done
  • POST /complete
  • GET /listings.json
  • GET /reports.json
    • ベンチマーカーだけが叩く想定

外部サービス

  • payment service
  • shipment service

postShipDone処理フロー

shipping を pickup から先へ
trx_evidences wait_ship から wait_done にする

リクエストパラメータはitem_id

  • select seller
    -- seller の存在チェック
  • select transaction_evidences
    -- 存在確認
    -- seller チェック
  • begin
  • select item for update
    -- 存在チェック
    -- statusチェック
  • select transaction_evidence for update (by primary key)
    -- status チェック
  • select shippings for update
  • Call shipment API
  • update shipping
  • update trx_evidences
  • commit

shipment APIが遅くなると、itemのlockがたまり、他に影響しやすくなる
ただ、実際にはtransactionは必要なく、shippingをselectして、
API callして、shippingとtrx_evidencesを更新する(更新する必要があれば)だけ

ベンチマーク用ワーカーの作成

以下の一連のタスクを実行するデーモンないしはcronjobを作成。

  1. ポータルのジョブキューをポーリングしてベンチマーク実行ジョブをフェッチ
  2. フェッチした情報を元にベンチマーカーをキック
  3. ベンチマーカーの実行結果をポータルに投げ返す

商品リスト系APIの商品出し分け条件

# timeline (/new_items.json) 
status=on_sale, sold_out

# user  (/users/:user_id.json) 
seller=:user_id で status=on_sale, trading, sold_out

# transactions (/users/transactions.json) は
閲覧者がbuyerもしくはsellerで、
status=全て

ベンチマーカーに関してメモ

ベンチマーカーのフェーズ

  • initialize
  • verify
  • validation
    • check
    • load

initialize

初期化フェーズ。/initialize にリクエストを送ることでアプリケーションがDBのデータを削除したりする。この時に外部リソースのURLを指定する問題もあった。今回もそうなりそう。

verify

初期チェック。正しく動いているかどうかを確認する。明らかにおかしいレスポンスを返しているアプリケーションはさっさと停止させることで、運営側のリソースを使い果たさないようにする。

validation

一番大切なメイン処理。checkとloadの大きく2つのリクエストを送る。

  • checkはアプリケーションが正しく動いているか常にチェックする
    • 理想的には全リクエストはcheckされるべきだが、それをやるとパフォーマンスが出し切れず、最適化されたアプリケーションよりも遅くなる
    • 最低限の確認しかしないloadが必要
  • checkとloadは区別がつかないようにしないといけない
    • 以前loadのリクエストはログアウト状態しかなかったので、ログアウト時のキャッシュを強くするだけでスコアがはねる問題があった
  • 遅いエンドポイントがあるときに他のエンドポイントのリクエスト数を増やさないようにする
    • 特定のエンドポイントに投げる専用goroutineを用意して、sleepを入れることで理論的に特定エンドポイントで取れる最高点を決めておく
    • POSTにsleepを入れることで、キャッシュがしやすいエンドポイントへのリクエスト数を増やすことでスコアが不当に上がることを防ぐ

悩み

  • loadはどう増やしていくか?
    • 失敗数が少なければどんどん増やすという実装だと、失敗するまでリクエストが送られ続けるので、必ずアプリケーションは失敗する
    • たまたま詰まってしまうと点数が全く上がらなくなってしまうので、スコアが安定して出せない

画面モック作る

Cacooで作って共有してずれてなかったらフロントエンドがつがつすすめる

ユーザに num_sell_items カラムの追加

出品数のカウントをする
別テーブルにしてしまっても面白い

例年であれば、select count(*) をするところかもしれないが、
出品トランザクションにuserテーブルの追加をする理由とする。

get_itemsやtimelineでsellerの出品数を返すとN+1がつくれる
select count だともっと大変

ansibleの用意

必要なもの

  • 参加者用インスタンス
  • ポータル
  • ベンチマーカー
  • 開発用サーバ (paymentおよびshipmentのサービス)

構成

  • アプリケーションはDockerを使うか?
    • ISUCON6本選の時は色々言われたが、ほぼ同じ構成のISUCON8本選は特に苦情はなかったので予選で使っても苦情は出なそう
    • Dockerを問う問題にはしたくないので考え方次第
    • 今回は外部リソースに依存するアプリケーションなので、開発環境を構築するのが難しい。ISUCON5本選では開発環境構築が難しいこと自体もお題の一つだった(と解釈している)。ISUCON8本選はDockerを使って開発環境は構築可能でドキュメントにも詳細に書かれていた

OS

Ubuntu18.04 LTS

注意点

外部リソースをどう提供するか

ジャストアイディア

  • Goで作って単体でもベンチマーカー上でも動かせるように作っておく
  • もちろんHTTPS前提
  • 単体のURLは全参加者で共有する
  • ベンチマーカー上で適当なポートで起動して、証明書を持ったnginxでルーティングする
  • アプリケーションの/initializeで外部リソースのURLを渡してそこにリクエストを送ってもらう
  • ベンチマーカー上で起動するアプリケーションを他の競技者が叩くのはマズい。ポータルでIPアドレスを登録してもらって、そこ以外からのリクエストは弾くようにしたい。

Bump機能を取り入れる

timelineで商品を並べる際に、
order by idとorder by createdに差がない状況
bump機能を取り入れ、createdをupdateすることで、order by createdを強制することができる。

createdが更新される、たぶん世の中のアプリケーションではたまにあること

先行して参考実装移植

例年参考実装移植中にバグや問題(問題・ベンチマーカー両方)が見つかるので、先行して @kazeburo さんにPerl実装を移植してもらう。

topページ

  • ログイン/新規登録導線
  • 煽り文句表示
    • ついにリリース!椅子限定C2CのECサービス カードで簡単決済。もちろんセキュリティも万全。 お互いの住所を知らなくても配送可能。
  • ロゴ

お題のフロントエンド

  • テンプレートの他言語への移植コストが高すぎるので、アプリケーションはJSON APIしか提供したくない
  • フロントエンドでいい感じになるようにしたい
  • SSRは不要の予定

画面イメージ

https://cacoo.com/diagrams/Bl0Kq0HTVfo1LM4w/FBDB8

進捗

画面モック進捗

  • 新規登録ページ
  • 新着商品一覧ページ
  • カテゴリ新着商品一覧ページ #173
  • トップページ
  • 商品詳細ページ
    • ざっくり見た目
    • フッター
  • 出品ページ
    • アップロードした画像の反映
  • 取引ページ #182
  • ユーザーページ
    • ざっくり見た目
    • タブ #241
  • ユーザー設定ページ
  • 商品編集ページ
  • 購入ページ

画面機能進捗

  • 新規登録ページ
  • ログインページ
  • 新着商品一覧ページ #117
  • カテゴリ新着商品一覧ページ #173
  • トップページ
  • 商品詳細ページ
  • 出品ページ
  • 取引ページ #182
  • ユーザーページ #92 #241
  • ユーザー設定ページ
  • 商品編集ページ
  • 購入ページ

postSell の処理フロー

Sellerが行う
num_sell_items がある前提で

  • begin
  • select seller for update
  • insert into item
  • 画像保存
  • update seller
  • commit

わりとシンプル
transactionなくても実は構わないな

ジョブキューの仕様

  • ベンチマーカーはCLIツールで、標準出力にスコアやメッセージをJSONとして出力する
  • トラブル時の原因究明のために標準エラー出力には色々ログを吐いておいて、運営だけがポータル上で見れるようにしたい
  • ポータル上でリアルタイムにベンチマーカーの進捗を出す機能が欲しい。その場合はベンチマーカーはどうログを出力すればいいか
  • ベンチマーカーがマシンのリソースを使い果たして、ジョブキューの仕組みごと死んだらどうなる?
  • ジョブキューはCLIを実行するだけ、ベンチマーカーはポータルとは一切やりとりしないようにしたい

公開account/passwordをつくる

isucon8では、公開ログイン情報がなく、試すにはregisterする必要があった。
initializeで消されるので、若干不便
seller, buyerを試せる用、2つぐらい公開account/passwordの組みを作り、公開する

postItemEditの処理フロー

  • priceのverify
  • select seller
    -- idのチェック
  • select item
    -- item_idの存在チェック
    -- sellerのチェック
  • begin
  • select item for update
    -- statusチェック
  • update item
  • commit

begin前のselect sellerは実際に必要ない
begin前のselect itemはbegin後にまとめられる

商品にカテゴリを追加

商品にカテゴリIDを追加
カテゴリマスターでのN+1
カテゴリごとtimelineの実装の実装に利用

postComplete処理フロー

Buyerが商品をうけとったときに実行。
reviewなどはない

パラメータはitem_id

  • select buyer
    -- buyerのチェック
  • select transaction_evidences
    -- 存在確認
    -- buyerのチェック
  • begin
  • select item for update
    -- 存在確認
    -- statusチェック
  • select transaction_evidences for update
  • select shipping for update
  • Call ShipmentStatus API
  • update shipping
  • update transaction_evidences
  • update item
  • commit

購入数と同じだけリクエストがくる
Shipment APIが遅くなることで、itemのlockがたまり、他の影響がでやすい
transactionは必要なく、transaction_evidencesをselectし、API call後のupdate 3つで問題ない

タイムライン機能の仕様

N+1 を解決する
seller, buyer, categoryなどがある

select *をやめる
descriptionは表示しないので、速くなる可能性があるう

カテゴリ指定のtimelineとカテゴリ指定なしのtimelineがある

postBuyの処理フロー

  • select buyer
    -- idの確認
  • begin
  • select item for update
    -- itemの存在確認
    -- statusの確認
  • select seller for update
    -- sellerの確認
  • insert into transaction_evidences
  • update item
  • Call ShipmentCreate API
  • Call PaymentToken API
  • insert into shippings
  • commit

postBuyは有名人アカウント出品で詰まるようにつくる
一個のitemに集中した場合、select item for update
sellerに集中した場合、 select seller for update が詰まる

解法としては、begin前に select itemしてstatusをみる
transactionとは別のlockをtransaction前で行うというのを想定

select seller for updateは実は必要ない

キャンペーン機能について考える

負荷をかけていいというサインとして「キャンペーン」、キャンペーン中に一気に購入者が来る「人気者出品」という用語を考え中。

キャンペーン中に起こること

  • ドンドン負荷が上がる
    • 倍々だとスコアが安定しないのでもう少しゆっくり
  • 1商品に購入が集中する「人気者出品」があり、これはスコアが普通より高い
  • 外部サービスのレイテンシが急増するタイミングがある

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.