방금 동급생 Wu Lei에게서 장바구니에 대한 몇 가지 아이디어를 봤습니다. 저는 우연히 전자상거래의 이러한 측면을 잘 알고 있기 때문에 제 부끄러움을 일부 동료들에게 보여주기 위해 뛰쳐나왔습니다. 원래는 다음과 같이 답글을 달고 싶었는데, 작성하는 데 시간이 많이 걸리기 때문에 그냥 여기에 쓰는 것이 좋을 것 같습니다. 앞으로는 직접 찾아보는 것이 더 쉬울 것 같습니다. 하하 . 장바구니에 담긴 데이터를 데이터베이스에 저장해야 합니까?
특히 실제 소프트웨어 엔지니어가 실제 프로젝트에서 이 문제에 대해 어떻게 생각하는지 알고 싶습니다. Google에서 검색한 결과 우리 정원에 있는 한 네티즌의 기사를 발견했습니다. 장바구니는 데이터를 임시로 저장하는 모듈이어야 하며 이를 Session 개체에 저장했습니다. 이 네티즌이 한 말은 일리가 있지만 저는 이런 접근 방식이 마음에 들지 않습니다. 모든 사람이 이를 Session 개체에 저장하고 수천 명의 사용자가 함께 쇼핑한다면 ASP.NET 서버는 확실히 엄청난 부하를 감당하게 될 것입니다. 어쩌면 국내 웹사이트가 더 나을 수도 있지만 Amazon과 같은 웹사이트에서는 어떻게 해야 할까요? Joyo의 웹사이트인 Amazon China 웹사이트는 Session 객체에 저장하지 않습니다. 왜냐하면 이번에 장바구니에 담은 상품을 주문하지 않으면 로그인 후에도 해당 상품이 계속 장바구니에 남아 있기 때문입니다. 다음 시간에. 그래서 나는 그들이 장바구니의 데이터를 데이터베이스에 저장하고 있을 것이라고 생각했습니다.
답변: 세션에 장바구니를 저장하는 기능은 대학의 코스 설계나 아무도 관심을 두지 않는 일부 인턴십 프로젝트에만 존재하는 것 같습니다. 실제로 거의 모든 전자상거래 웹사이트는 장바구니 데이터를 데이터베이스에 저장합니다. 다음은 몇 가지 설명과 설계 고려 사항입니다.
1. 세션은 많은 양의 데이터를 저장하는 데 적합하지 않습니다. 사용자가 많을 경우 필연적으로 서버 성능에 영향을 미치므로 피해야 합니다.
2. 실수로 세션이 손실되는 문제가 있거나, 사용자가 실수로 브라우저를 닫은 경우 장바구니에 있는 모든 항목이 손실되어 매우 나쁜 사용자 경험을 초래하는 문제가 있습니다.
3. 쿠키는 위 항목의 세션 문제를 해결할 수 있으나, 쿠키의 길이 제한, 쿠키 사용 시 통신 오버헤드, 보안상의 고려 사항 등으로 인해 장바구니에는 적합하지 않습니다.
4. 더 나은 사용자 경험은 사용자의 로그인 여부에 관계없이 특정 기간 내에 장바구니 상태를 기록할 수 있다는 것입니다. 이를 위해서는 데이터베이스의 장바구니가 사용자와 연결될 수 없습니다.
5. 장바구니에 담는 상품은 일반적으로 구매 의도가 있는 상품이지만 반드시 실제 주문이 되는 것은 아닙니다. 이때 이 데이터를 보관하는 것은 데이터 마이닝 및 비즈니스 분석에 중요한 역할을 합니다.
질문: 2. 동시성에 대해서요?
제가 모의 웹사이트를 개발할 때 다음과 같은 질문을 한 번 생각해 본 적이 있습니다. 고객이 웹사이트의 장바구니에 책을 넣으면 이 책의 수를 재고에서 빼야 할까요? 그게 내가 한 일이야. 이때 다른 사용자가 허위 재고 수량을 보는 것을 방지하기 위해 장바구니에 담긴 해당 도서의 수량을 데이터베이스에서 차감합니다(차감하지 않으면 다른 사용자가 구매할 수 있습니다. 예: 재고는 10개입니다. 이 책을 고객 A는 장바구니에 10권을 담았고, 고객 B도 장바구니에 10권을 담았습니다. 그러면 이 책을 누가 구매할 것인지 갈등이 생길 것입니다. 하지만 이렇게 해보니 결과적으로 고객이 장바구니를 업데이트할 때마다 데이터베이스와 통신이 발생하게 되어 데이터 서버의 부담이 커지게 됩니다. Amazon.cn은 이와 관련하여 그다지 좋은 성과를 거두지 못하고 있습니다. 귀하께서 "운영 체제 심층 이해" 책을 구매하셨을 때 처음 주문하셨으나 이에 대한 안내를 받은 문제가 발생한 적이 있을 것입니다. 다음날 품절이었다는 것. 이 사건은 실제로 Amazon.cn의 신뢰성에 큰 영향을 미쳤습니다. 이제 그들의 시스템이 이 문제를 해결했는지는 모르겠지만 "운영 체제에 대한 심층적 이해"라는 책의 Joyo 가격은 예전과 다릅니다. . 전문가들이 이 문제를 어떻게 해결했는지 모르겠습니다. 귀하의 성공적인 경험을 댓글에 적어주세요.
답변: 먼저 데이터베이스 서버의 부담에 대해 말씀드리겠습니다. 페이지에 액세스할 때마다 데이터베이스에 몇 번 액세스해야 하는지 생각해보고, 한 번의 추가 작업을 교환하는 데 몇 번이나 걸리는지 생각해 보세요. 장바구니(접속 횟수는 주로 웹 사이트 사용 편의성에 따라 다름) 디자인, 이는 또 다른 주제입니다. 따라서 여기에서 디자인을 수정하면 데이터베이스 부담을 어느 정도 줄일 수 있지만 여기서는 병목 현상이 발생하지 않는다고 생각합니다. 여기에 너무 많은 관심을 기울일 필요가 없습니다.
현재 장바구니에 담긴 상품이 즉시 재고에서 차감되지 않는 것이 일반적인 관행입니다. 이는 주로 누군가가 장바구니를 통해 상품을 악의적으로 점유하는 것을 방지하기 위한 것입니다. 또한, 대부분의 경우 중복 금액이 제공됩니다. 장바구니에 담긴 상품은 최종 주문이 완료되면 즉시 재고에서 차감되지 않습니다. 장바구니는 판매에 영향을 미칠 수 없습니다. 일반적으로 주문이 성공적으로 제출되면 재고가 차감됩니다. 즉, 사용자가 주문을 제출하면 사용자에게 재고가 없음을 다시 알릴 수 있는 기회가 있으므로 주문 시 재고를 차감할 필요가 없습니다. 장바구니. 성공적인 주문의 경우, 사용자가 제출한 모든 주문이 성공적인 주문으로 간주되는 것은 아닙니다. 이 프로그램은 작성하기 어렵지만 실제로는 이전 데이터 분석, 사용자 행동, 사용자 평판 등을 기반으로 매우 중요합니다. 데이터는 몇 분 내에 주문 검토를 자동으로 완료하는 시스템에서 제공됩니다. 검토 강도는 업계와 관련이 있으며, 이는 대부분의 가짜 주문을 제거할 수 있으며 일부는 수동 검토로 전환될 수 있습니다. 자동 검토 시스템.
여기에는 특별한 상황이 있습니다. 콘서트 티켓과 같은 일부 특별 상품의 경우 온라인 좌석 선택이 있을 수 있습니다. 이 경우, 현재는 장바구니를 담은 후 좌석을 예약하는 것이 더 유용합니다. 장바구니를 담은 후 즉시 해제되지만, 10분 등 일정 시간 내에 실제 주문이 되지 않으면 자동으로 해제됩니다. 비록 악성 좌석 점유를 완전히 제거할 수는 없지만 대부분의 문제를 해결할 수 있습니다. 요즘 발권업계의 온라인 좌석지정 성공 여부를 판단하는 기준은 결제 성공 여부로, 결제하지 않으면 10분만 예약이 가능하다.
질문: 3. 주문과 주문 세부정보 및 장바구니 간의 관계
내 생각엔 이 문제가 그러한 웹사이트들에게는 항상 큰 문제였을 수도 있다고 생각합니다! 이틀 전 CSTP의 Chen 선생님께서 이 질문에 대해 전화 인터뷰를 하셨습니다. 당시 저는 매우 긴장했고 질문에 대한 답변이 명확하지 않았습니다. 실제로 이 문제는 간단하게 생각하기 어렵지 않습니다. 주문과 세부정보라는 두 개의 테이블이 있습니다. 주문 테이블의 각 열은 세부정보 테이블의 해당 열을 가리킵니다. 외래 키는 주문 테이블의 주문 번호입니다.
답변: 이 질문은 비교적 간단합니다. 하나는 장바구니에 담아 주문으로 처리하는 것입니다. 이 상태에서 주문을 수정하고 장바구니를 주문 시스템에 병합할 수 있습니다. 사용자 로그인 및 비로그인 상태 처리에 주의) 두 번째는 주문이 최종 제출되면 장바구니에 있는 정보가 주문 및 주문 세부정보 테이블에 복사되는 것입니다. 후자가 더 일반적으로 사용되며 구체적인 선택은 산업 및 제품 속성에 따라 다릅니다.
질문: 4. 세부 목록에서 주문 번호를 어떻게 생성하나요?
이 질문은 질문 3에서 상속되었습니다. 아직 이 문제를 해결하는 방법을 모르겠습니다. 두 가지 솔루션이 있습니다. 하나는 트리거를 사용하고 다른 하나는 프로그래밍입니다. 전자는 고객이 장바구니에 상품을 담을 때마다 세부정보를 추가하고, 구매 확인 후 주문을 생성하며, 세부 테이블에서 구매 상태를 변경하여 트리거가 발생하고 주문번호가 생성됩니다(물론 이는 주문 번호는 트리거 프로그래밍에서 주문 테이블의 주문 번호 열을 설정하여 자동으로 일련 번호를 생성하는 것일 수도 있습니다. 후자는 주문 번호를 판단한 다음 여기에 1을 추가하여 새 주문 번호를 생성합니다. 하지만 저는 항상 이 두 가지 해결책이 매우 나쁘다고 생각하며, 상용 웹사이트에서 주문 번호가 어떻게 처리되는지 알고 싶습니다.
답변: 우선 저는 개인적으로 트리거 솔루션이 바람직하지 않다고 생각합니다. 이유에 대해서는 자세히 설명하지 않겠습니다. 그렇지 않으면 또 다른 큰 혼란이 될 것입니다. 여기에도 두 가지 방법이 있습니다. 하나는 주문을 생성할 때 먼저 주문 번호를 검색한 다음 주문 세부정보 테이블을 업데이트하는 것입니다. 비즈니스 규칙에 따라 주문 번호를 알면 먼저 주문 기록이나 세부 기록을 생성할 수 있지만 마지막에 세부 기록에 주문 기록이 있어야 합니다. 그렇지 않으면 오류가 발생합니다. 이상한 세부 사항이 많이 있습니다. 후자의 방법에는 두 가지가 있는데, 하나는 일반적으로 임시 테이블을 사용하여 데이터베이스에서 주문 번호를 생성하는 것입니다. 다른 하나는 주문 번호를 모든 기업에서 보편적으로 사용할 수 있다는 것입니다. GUID는 프로그램을 생성할 때 사용할 수 있지만 더 좋은 방법은 주문 시간에 식별 값을 추가하는 것입니다. 데이터의 양에 따라 세분성의 크기가 결정됩니다. 식별 부분은 순서대로 번호가 매겨져 있습니다. 다른 사람이 귀하의 비즈니스 볼륨을 대략적으로 계산하지 않도록 시간 세분성도 고려해야 합니다(땀 ~~ 이것도 또 다른 문제입니다. 상황에 따라 다르겠지만 주문번호 생성에 대한 글은 나중에 써보도록 할게요.. 정보는 충분할 것 같습니다.