Background

주문은 판매자의 핵심 데이터이며, 판매자의 일상 업무 중 많은 부분이 이를 중심으로 이루어집니다. 주문 확장, 애플리케이션의 기본 기능은 주문이 판매자 앞에 실시간으로 완전하게 표시되도록 하는 것입니다. API 요청은 네트워크에 의존하기 때문에 네트워크 불안정, 긴 동기화 시간 등의 문제가 있으므로 애플리케이션은 타오바오 주문 데이터를 로컬에서 동기화해야 합니다. 어떻게 하면 주문을 현지에 신속하고 완벽하게 동기화할 수 있는지가 이 계획에서 논의될 문제입니다.

주문을 동기화하는 방법에는 두 가지가 있습니다. 1. API를 통한 동기화 2. rds 주문 동기화 서비스 기반. 이 글에서는 주로 API를 사용하여 주문을 동기화하는 시나리오를 분석합니다. RDS 주문 동기화 사용 방법에 대한 자세한 내용은 //open.taobao.com/docs/doc.htm.htm?articleId=101587&docType=1&treeId=2#을 참조하세요. 🎜🎜#

용어 정의

#🎜 🎜# 온라인 주문#🎜 🎜#: 3개월 이내에 판매자가 판매한 주문입니다.

incremental order: 로컬에 동기화된 주문을 기준으로 모든 일이 발생합니다. 타오바오 변경된 순서는 증분순입니다.

Message Service: 일종의 실시간 푸시 데이터를 통해 클라이언트(애플리케이션)에 데이터를 보냅니다. (트랜잭션) 변경을 위한 HTTP 긴 연결 채널입니다.

API

소개

#🎜🎜 # taobao.trades.sold.get - 3개월 이내에 온라인 주문을 받습니다. 사용자 초기화에 적합합니다. ISV는 이 인터페이스를 사용하여 증분 주문을 받아서는 안 됩니다. 이 인터페이스를 사용하거나 가능한 한 적게 사용하는 것은 권장되지 않습니다.

taobao.trades.sold.increment.get – 증분 주문 받기, 사용자 초기화 주문 후 증분 동기화 변경 사항에 적용 가능, ISV는 3개월 이내에 주문을 받기 위해 이 인터페이스를 사용하지 마십시오.

taobao.trade.fullinfo.get - 단일 주문 세부정보를 확인하세요.

구현 계획

주문 동기화는 크게 초기화와 동기화로 나누어집니다. 증분 수량을 얻는 데는 두 단계가 있습니다.

1 초기화는 3개월 이내에 모든 온라인 주문을 동기화하는 것입니다. 오랜만이다

2. 증분 획득은 Taobao에서 변경된 주문을 동기화하는 것으로 일반적으로 시간이 더 짧습니다.

다음 솔루션은 모두 초기화 및 점진적 획득 방법에 중점을 둡니다.

1 # 🎜🎜#

2

# 🎜 🎜#

옵션 1

# 🎜 🎜#

동기화 프로세스:

# 🎜🎜#

핵심 단계:

u#🎜 🎜 #

3개월 데이터: taobao.trades.sold.get, 및 #🎜 🎜##을 통해 3개월 이내에 생성된 주문 ID를 가져옵니다. 🎜🎜#taobao.trade.fullinfo.get주문 세부정보 가져오기

u 증분 데이터: 지금부터 taobao.trades.sold.increment.get을 통해 증분 주문 ID를 가져오고, 그런 다음 taobao.trade.fullinfo.get을 통해 주문 세부 정보를 가져옵니다.

적용 범위:

주문 동기화를 위한 생산 환경의 ISV 테스트 주문 동기화 기능 또는 중소 판매자에게 적합합니다. 이 솔루션은 상대적으로 비효율적입니다. 오래된 애플리케이션의 업데이트 비용이 매우 높지 않는 한, 다음 솔루션을 채택하는 것은 권장되지 않습니다.

옵션 2

동기화 프로세스:

핵심 단계:

a) 먼저 3개월 이내에 생성된 주문 내역을 taobao.trades.sold.get

u을 통해 어제 23시 59분 59초까지 가져옵니다. 3개월 데이터:

b) 그런 다음 taobao.trades.sold.increment.get을 통해 오늘 00:00:00부터 현재까지의 증분 주문 ID를 가져오고, taobao.trade.fullinfo.get을 통해 주문 내역을 가져옵니다.

u 증분 데이터: 메시징 서비스 클라이언트를 통해 주문 변경 메시지를 실시간으로 모니터링한 후 taobao.trade.fullinfo.get

을 통해 주문 세부 정보를 얻습니다.

적용 범위 :

모든 유형의 판매자에게 적용 가능하며 모든 솔루션 중에서 비교적 복잡하지만 가장 효율적인 솔루션이며 모든 ISV에게 권장됩니다.

경험 공유

주문 누락 문제:

Mtaobao.trades.sold.get 및 taobao.trades.sold를 통해 .increment.get 얻을 때 order , 거래 유형 유형 입력 매개변수는 기본적으로 일부 유형의 주문만 조회합니다. 모든 유형의 주문을 조회하려면 모든 거래 유형을 유형 입력 매개변수로 명시적으로 제공해야 합니다.

M taobao.trades.sold.increment.get을 통해 증분 주문을 받을 때 반환된 결과는 주문 수정 시간을 기준으로 역순으로 정렬됩니다. 페이징은 뒤에서 앞으로 이루어져야 합니다. 앞으로 스크롤되는 것을 방지합니다. 페이지 프로세스 중에 순서가 변경되어 주문이 누락되었습니다.

M taobao.trades.sold.increment.get을 통해 증분 주문을 받을 때 각 취득의 시작 시간을 약 10분 정도 적절하게 앞당겨야 합니다. 대규모 프로모션 기간 동안 앞으로 이동 약 30분)을 진행하여 극단적인 상황에서 타오바오 시스템 압박으로 인해 주문 데이터베이스 업데이트가 지연되어 주문 누락을 방지하세요. M

활성 알림을 통해 주문 변경 메시지를 받을 경우, 서버 재시작이나 네트워크 연결 끊김으로 인한 메시지 손실 문제를 처리해야 합니다. 자세한 내용은 메시지 서비스를 확인하세요. 성능 문제:

M

taobao.trades.sold.get 3개월 동안 판매된 판매자로부터 주문 받기 n

Adopt use_has_next=true인 페이징 방법은 Taobao 데이터베이스에 대한 각 API 요청에 의해 생성되는 카운트(*)를 방지하여 속도와 안정성을 크게 향상시킬 수 있습니다. n

3개월 이내 주문을 받기 위한 인터페이스는 생성 시간을 기준으로 필터링되고 생성 시간은 불변이므로 페이지를 앞뒤로 넘겨도 주문을 놓칠 염려가 없습니다. 첫 번째 단계에서 count(*)를 생략하고 결과에 has_next=false가 반환될 때 페이지 넘김이 종료될 때까지 입력 매개변수 use_has_next=true를 직접 사용하여 페이지로 가져옵니다.

n 인터페이스에서 반환된 필드가 애플리케이션의 요구 사항을 충족할 수 없는 경우 다음만 수행하는 것이 좋습니다. fields=tid.field를 얻은 다음 taobao.trade.fullinfo.get을 통해 주문 세부정보를 얻습니다.

n 판매자의 주문량이 상대적으로 많기 때문에 3개월 후에는 3개월의 주문을 일일 인수로 나누어 단일 요청으로 Taobao 데이터베이스의 기록 스캔 양을 줄여 효율성을 높이는 것이 좋습니다.

M taobao.trades.sold.increment.get 증분 주문 받기

n 입력 매개변수 사용 use_has_next= 진정한 페이징 방법은 각 API 요청에 대해 Taobao 데이터베이스에서 생성되는 카운트(*)를 방지하여 속도와 안정성을 크게 향상시킵니다.

n 증분 순서 인터페이스가 수정되었기 때문에 시간 필터링 , 수정 시간은 가변적이므로 주문 누락을 방지하려면 뒤에서 앞으로 페이지를 넘겨야 합니다. 페이지를 뒤에서 앞으로 넘기려면 마지막 페이지를 알아야 하므로 첫 번째 API 요청에서 use_has_next=false를 사용하여 총 주문 수를 계산하고, 총 페이지 수를 계산한 후 use_has_next=true를 설정하여 종료해야 합니다. 통계를 주문하고 페이지를 뒤에서 앞으로 넘깁니다.

n 인터페이스에서 반환된 필드가 충족될 수 없는 경우 애플리케이션 요구 사항 필요한 경우 fields=tid 필드만 얻은 다음 taobao.trade.fullinfo.get을 통해 주문 세부 정보를 얻는 것이 좋습니다.

M tid 필드만 얻기 위해 taobao.trades.sold.get/taobao.trades.sold.increment.get을 사용할 때, page_size를 최대값으로 설정하여 API 수를 줄이는 것이 좋습니다 요청하고 효율성을 향상시킵니다. 여러 필드를 얻을 경우 자신의 네트워크 상황에 맞게 page_size를 50 정도로 설정하는 것이 좋습니다.

예외 처리:

M 동기 주문은 일반적으로 다중 스레드 처리를 사용합니다. API 요청에는 APP에 대한 빈도 제한이 있으므로 스레드 풀 크기를 설정할 때 다음을 수행해야 합니다. 현재 제한으로 인해 애플리케이션이 오랫동안 API를 호출할 수 없는 것을 방지하려면 TOP에서 허용하는 API 호출 빈도에 따라 설정하세요.

M API에서 반환된 ISP 유형 오류 또는 네트워크 연결 오류의 경우 애플리케이션 스레드는 잠시 대기한 후 자동으로 다시 시도해야 합니다. API에서 반환된 ISV 유형 오류의 경우 애플리케이션은 향후 문제 해결을 위해 로그를 기록해야 하며 재시도하지 않아야 합니다.

FAQ

• 아직 이 문서에 대한 FAQ가 없습니다