친구를 초대하려면 웹사이트에 기능적인 모듈이 필요합니다. 프로세스는 다음과 같습니다.
사용자 센터는 A인별로 초대 링크를 생성하고, 초대 대상자(B)가 등록을 클릭한 후 B의 등록 필드 뒤에 A의 ID가 태그로 삽입됩니다.
현재는 이 방법으로 각 사람이 초대한 친구 목록을 셀 수 있지만 앞으로는 다음과 같은 문제가 발생할 수 있습니다.
초대자 B가 처음 주문할 때 A는 포인트 보상의 10%를 받게 됩니다. 첫 번째 주문이 아니면 보상이 없습니다
(이것은 내 어리석은 생각입니다. 모든 사용자는 주문을 하면 먼저 우월한 사용자 A가 있는지 확인해야 하며, 우월한 사용자 A가 없으면 직접 주문해야 합니다. 처음으로 주문할지 여부를 다시 판단해야 합니다. , 그리고 상위에 포인트를 추가하는 동시에 사용자 B)
그럼 문제는 내 어리석은 방법이 각 사용자의 모든 주문에 대해 첫 번째 주문을 판단해야 한다는 것입니다. 이것이 너무 번거롭고 문제가 발생하기 쉽다고 생각합니다. 마스터가 어떤 최적화 아이디어를 가지고 있는지 궁금합니다.
이렇게 하면 될 것 같아요:
친구관계: 별도의 테이블을 생성할 수 있습니다.
好友关系表
,里面存两个字段uid
(用户ID),contact_uid
(연관된 친구 ID)처음 주문인지, 친구 추천 포인트 추가: 주문 여부(위에서도 언급) 사용자 관련 테이블에 필드를 추가할 수 있으며, 기본값은 0입니다. 주문을 하지 않은 경우, 주문을 할 때마다 이 필드가 먼저 쿼리됩니다.
1
인 경우 일반 주문 논리를 따르며, 0인 경우 주문한 적이 없음을 의미합니다. 사용자에게 추천인이 있는지 여부, 추천인에 포인트를 추가하는 등 사용할 로직이 실행됩니다.이렇게 하지 마세요. 성능에 영향을 미치게 됩니다.
통계 포인트는 매일 아침 계산됩니다.
이 테이블에는 id, B의 id, C의 id가 있으며 buystate 값은 1 또는 0일 수 있습니다. 0은 첫 번째 구매가 아님을 의미하고 1은 첫 번째 구매를 의미합니다.
필드를 직접 추가하면 이전에 주문한 적이 있는지 여부에 관계없이 기본값은 0입니다. 어쨌든 주문할 때 사용자 정보를 얻을 수 있습니다. 그런데 0인지 판단하면 알 수 있습니다. 첫 번째 주문. 포인트적으로 성능이 걱정된다면 Redis에 저장하고 정해진 시간에 데이터베이스를 수정하는 것도 고려해 볼 수 있습니다.
아이디어 괜찮은 것 같아요
한 가지 말씀드릴 점은, 보상 포인트는 주문할 때가 아니라 주문이 완료된 후에 주어야 한다는 것입니다.
사용자 테이블에 필드를 추가하면 과거 완료된 주문 수를 표시할 수 있습니다. 나중에 수요가 변경되면 처음 N번에 대한 포인트를 쉽게 반환할 수 있습니다. 그리고 일반적으로 주문을 하거나 주문을 완료하는 과정에서는 사용자 테이블을 쿼리해야 하는데 이는 복잡하지 않습니다.