注文の同期


バックグラウンド

注文は販売者の核となるデータです。販売者の日常業務の多くは注文を中心に展開しています。アプリケーションの基本機能は次のとおりです。注文がリアルタイムかつ完全に売り手の目の前に表示されるようにする。 API リクエストはネットワークに依存しているため、ネットワークの不安定性や同期時間が長いなどの問題があるため、アプリケーションは Taobao の注文データをローカルで同期する必要があります。注文をローカルエリアに迅速かつ完全に同期させる方法は、この計画で議論される問題です。

注文を同期するには 2 つの方法があります: 1. API を介した同期 2. rds 注文同期サービスに基づく。この記事では主に、API を使用して注文を同期するシナリオを分析します。RDS 注文同期の使用方法については、//open.taabao.com/docs/doc.htm.htm?articleId=101587&docType=1&treeId=2# を参照してください。

##用語の説明

オンライン注文: 販売者による注文販売者は3か月以内に。

増分注文: ローカルに同期されている注文と比較して、タオバオで変更された注文はすべて増分です。注文。

メッセージ サービス: HTTP 長い接続を通じて、データ (トランザクション) の変更をクライアント (アプリケーション) にリアルタイムでプッシュするチャネル。

API

はじめに

#taabao.trades. sold.get - 3 か月間のオンライン注文を取得期間内に販売されたものは、ユーザーの初期化中の使用に適しています。ISV は、増分注文を取得するためにこのインターフェイスを使用しないでください。このインターフェイスを使用すること、またはできるだけ使用しないことはお勧めできません。

taabao.trades. sold.increment.get – 増分注文を取得します。ユーザー初期化後の増分同期で変更された注文に適しています。ISV はこれを使用しないでください。 3か月以内に注文を獲得できるインターフェース。

taabao.trade.fullinfo.get - 1 つの注文の詳細を取得します。

#実装計画

注文の同期は主に、初期化と増分取得の 2 つのステップに分かれています。

1. 初期化では、すべてのオンライン注文を 3 か月以内に同期する必要がありますが、これには長い時間がかかります。

2. 増分取得とは、タオバオで変更された注文を同期することであり、通常、これにかかる時間は短くなります。

#次のソリューションは、初期化と増分取得の方法に焦点を当てています。

1

2

##オプション 1

同期プロセス:

T1cRo6XidbXXb1upjX.jpg

##コアステップ:

T1j8o5XixeXXb1upjX.jpg##u

3 か月のデータ: 3 か月以内に作成された注文 ID を、taabao.trades. sold.get、 の順で取得し、taovao.trade.fullinfo.get注文の詳細を取得する# ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

u 増分データ: 今後、taovao.trades. sold.increment.get を通じて増分注文 ID を取得し、その後、注文を取得します詳細は taabao.trade.fullinfo.get

## を介して# 適用範囲:

ISV の注文同期機能のテストや、生産環境における中小規模の販売者に適しています。注文の同期。この解決策は比較的非効率であり、古いアプリケーションの更新コストがよほど高額でない限り、すべての人に推奨できるわけではありませんが、次の解決策を採用することをお勧めします。

オプション 2

同期プロセス:

TB13fTQGXXXXXbdXFXXSutbFXXX.jpg

コアステップ:

TB1HOv3GXXXXXaNXXXXSutbFXXX.jpg

a) まず、taovao.trades. sold.get を使用して、昨日 23:59 までの 3 か月以内のデータを取得します。 59 作成された注文の詳細

u

3 か月分のデータ:

b) 次に、taovao.trades. sold.increment.get を使用して、今日の 00:00:00 から現在までの増分注文 ID を取得し、その後、taovao を使用します。 trade .fullinfo.get 注文の詳細を取得します

u 増分データ: メッセージを通じてリアルタイムで注文を監視しますサービスクライアント メッセージを変更し、taabao.trade.fullinfo.get

適用範囲: ## を通じて注文の詳細を取得します。

# は、あらゆるタイプの販売者に適しています。比較的複雑ですが、すべてのソリューションの中で最も効率的なソリューションです。すべての ISV が採用することをお勧めします。

#経験の共有

注文ミスの問題:

M

taabao.trades. sold.get および taabao.trades. sold.increment.get を通じて注文を取得する場合、取引タイプを次のように入力します。パラメータ デフォルトでは、一部のタイプの注文のみが照会されます。すべてのタイプの注文を照会するには、すべてのトランザクション・タイプを type 入力パラメータとして明示的に指定する必要があります。

MM

taobao.trades. sold.increment.get を通じて増分注文を取得すると、返される結果は次のとおりです。注文が変更時間の逆順にソートされている場合、前方へのページめくりプロセス中に注文の変更によって注文が見逃されるのを防ぐために、ページングを後ろから前へめくらなければなりません。

M taovao.trades. sold.increment.get を通じて増分注文を取得する場合、各取得の開始時間は適切に 10 分繰り上げられます。左右 (double11ビッグセール中は 30約分 前に進むことをお勧めします)タオバオのシステム圧力による注文の欠落による極端な状況を防ぐため、データベースへの注文の更新に遅れが生じます。

MM アクティブな通知を通じて注文変更メッセージを受信した場合は、サーバーの再起動またはネットワークの切断を処理する必要があります。結果としてメッセージ損失の問題が発生するため、詳細についてはメッセージ サービスを確認してください。

#パフォーマンスの問題:

##M

taabao.trades. sold.get 販売者の注文を 3 か月間取得します##n

use_has_next=true パラメーターを指定してページング メソッドを使用すると、Taobao データベースへの各 API リクエストによって生成されるカウント (*) を回避できるため、速度と安定性が大幅に向上します。 n

3 か月以内に注文を取得するためのインターフェイスは、作成時間と作成時間によってフィルターされているためです。 time これは不変なので、ページを前から後ろにめくっても注文が失われることはありません。そのため、最初のステップで count(*) を保存し、パラメータ use_has_next=true を直接使用して、has_next までページ単位で取得できます。結果に = が返され、 false の場合はページめくりを終了します。

n インターフェースによって返されるフィールドがアプリケーションのニーズを満たせない場合は、fields=tid フィールドのみを取得することを強くお勧めします。そして、taobao. trade.fullinfo.get を渡すと、注文の詳細が取得されます。

n 販売者の 3 か月分の注文量は比較的多いため、3 か月に分割することをお勧めします。 -月の注文は、効率を向上させるために単一のリクエストでタオバオデータベースのレコードスキャンの量を減らすために毎日取得されます。

M ##taabao.trades. sold.increment.get増分注文を取得する

n 入力パラメータ use_has_next=true を指定してページング メソッドを使用すると、各 API リクエスト中に Taobao データベースによって生成されるカウント (*) を回避できます。これにより、速度と安定性が大幅に向上します。

n 増分注文を取得するためのインターフェイスは変更時間によってフィルターされており、変更時間は可変であるためです。 , したがって、注文を見逃さないように、ページを後ろから前にめくる必要があります。ページを後ろから前にめくるには、最後のページを知っている必要があるため、最初の API リクエストで use_has_next=false を使用して注文の合計数をカウントし、合計ページ数を計算してから、use_has_next=true を設定して終了する必要があります。注文統計を確認し、ページを後ろから前にめくってください。

n インターフェイスによって返されるフィールドがアプリケーションのニーズを満たせない場合は、次のことを強くお勧めします。 field=tid のみを取得するため このフィールドは、taabao.trade.fullinfo.get を通じて注文の詳細を取得するために使用されます。

M taovao.trades. sold.get/taabao.trades. sold.increment.get を使用して tid フィールドのみを取得する場合、次のようになります。 page_size を に設定することを推奨します。最大値を指定すると、API リクエストの数が減り、効率が向上します。複数のフィールドを取得する場合は、ネットワークの状況に応じて page_size を設定できますが、50 程度に設定することを推奨します。

#例外処理:

MM 同期注文は通常マルチスレッドで処理されますが、API リクエストには APP の頻度制限があるため、スレッドプールサイズを設定する場合は、TOP が許可する API 呼び出し頻度に応じて設定する必要があります。その結果、アプリケーションは長時間にわたって API を呼び出すことができなくなります。

MM API によって返された ISP タイプのエラーまたはネットワーク接続エラーの場合、アプリケーション スレッドは次の時間スリープする必要があります。しばらくすると自動的に再試行されます。 API によって返される ISV タイプのエラーの場合、アプリケーションは将来のトラブルシューティングのためにログを記録する必要があり、再試行しないでください。

FAQ

    このドキュメントに関する FAQ はありません
←
→