요구 사항 설명:
주변 플랫폼은 인터페이스를 호출하여 휴대폰 번호를 기반으로 사용자의 노래 목록 추천 정보를 쿼리합니다. 각 사용자는 약 천 개의 추천 정보를 갖게 되며, 각 추천 정보에는 다음이 포함됩니다. 歌曲ID、歌曲名称、版权ID、试听地址字段.
여러 테이블을 쿼리해야 합니다. 각 쿼리는 쿼리가 완료된 후 인터페이스로 돌아가기 전에 데이터를 조립해야 합니다.
반환 형식은 json입니다. 이 경우 인터페이스 반환 속도가 느려집니다.
미리 Redis 클러스터에 데이터를 넣어볼까도 생각했지만, 나중에 사용자 수가 500만 명 정도이고, 사용자당 권장 정보 크기가 200kb 정도라서 Redis를 저장하면 메모리가 많이 소모되기 때문에 거부했습니다. 나는 그것을 거부했다. 하지만 다른 좋은 해결책이 생각나지 않습니다. 그러한 요구를 처리하는 방법에 대한 좋은 제안이 있는지 알려주시겠어요? 고마워하는!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
병목 현상은 많은 테이블을 쿼리하는 데 4초가 걸린다는 것입니다. 여기 로직에 최적화할 수 있는 지점이 있나요? 그렇지 않은 경우에는 이 4초를 소비해야 합니다. 다른 데이터 전송 형식의 경우 네트워크 통신 시간은 아무리 최적화되어도 4초 미만일 수 없습니다.
사용자가 인지하지 못하는 사이에 클라이언트가 추천 요청을 보내거나 쿼리 로직이 최적화됩니다.
연결된 목록 쿼리의 경우 SQL을 별도로 게시해 보세요. SQ에서 많은 시간을 보내시는 것 같아요
1. 한 번에 천 개의 품목을 반품하시겠습니까? 한 번에 50개 항목을 수행하는 것이 더 빠를까요? 다중 페이징 요청은 어떻습니까?
2. 캐싱 솔루션을 직접 비활성화하는 것은 부적절하다고 생각합니다. 500W 이상의 모든 사용자가 활성 사용자 수를 추정하는 데 허용되는 것은 아닙니다.
3
[추천 정보]에 ID 속성을 추가하고 Redis에 저장하세요. 이 양은 크지 않아야 합니다.
사용자별 추천정보도 redis에 저장되는데, [추천정보]는 1,000개의 ID만 저장됩니다.
이 경우 각 사용자의 추천 정보는 200kb가 되지 않습니다.