APP 페이징 서버 설계

웹 개발에서 일반적으로 사용되는 페이징 방법은 페이지 번호를 기반으로 합니다. 당분간은 웹스타일 페이징이라고 합니다.

페이지네이션은 페이지 번호 pageIndex와 페이지 크기 pageSize를 기준으로 수행됩니다.

이 페이징 방식은 웹에서 사용하면 큰 문제가 되지 않는데, 앱 페이징에도 이 페이징 방식을 적용할 수 있나요?

성능 측면에서 앱의 페이징 방식은 기본적으로 더 많은 형태의 스트리밍 페이징을 로드하기 위한 풀업 방식입니다. 백그라운드 인터페이스가 여전히 웹 스타일 페이징에 따라 설계되면 다음과 같은 문제가 발생합니다.

a. 데이터 중복

b. c. 오프셋이 너무 높음 데이터 양이 많을 경우 쿼리 효율성이 낮음

MySQL의 제한은 페이징에 큰 편의를 제공하지만, 데이터 양이 많을 경우 제한 성능이 급격히 떨어집니다.

전통적인 웹 스타일 페이징 인터페이스는 앱 페이징에 적합하지 않음을 알 수 있습니다.

3. 앱 스트리밍 페이징 서버 설계

a. 커서 페이징

장점:

1) 데이터 중복/생략을 방지할 수 있습니다.

2). Limit 성능은 커서 값의 크기에 영향을 받지 않으며 성능이 안정적입니다.

단점:

1). 시간에 따라서만 추가 간단한 정렬 방법

b. 시간 샤딩을 기반으로 캐시

데이터의 전체 양이 아니라 일부 인기 있는 데이터만 너무 빨리 변하기 때문입니다. 캐시는 기간을 기준으로 생성될 수 있습니다. 데이터의 경우, 기간(5분)별로 캐시 샤드를 생성할 수 있습니다.

구체적인 과정은 다음과 같습니다.

여기서 타임스탬프 값은 1페이지의 데이터를 요청할 때 타임스탬프가 0으로 전달됩니다. 서버는 타임스탬프<=0을 확인하여 할당합니다. 현재 시스템 시간 타임스탬프가 반환됩니다. 데이터의 두 번째, 세 번째,...n 페이지를 요청할 때 시스템에서 반환된 타임스탬프가 전달됩니다.

캐시된 키는 타임스탬프를 기준으로 계산됩니다(예: 5분에 하나의 샤드, key=list_201605231700).

적용 시나리오

예를 들어 홈페이지의 인기 항목은 일부 인기 기사일 뿐이며 정렬이 다소 복잡하고 상대적으로 변경하기 쉽습니다.

현재 해당 주제에 대한 목록 정렬은 페이지네이션 요청순으로 정렬되어 있습니다.

정렬이 실시간 데이터이고 커서가 없기 때문에 중복된 데이터가 나타납니다. 따라서 이전 데이터는 로드된 데이터를 감지할 수 없습니다.

c. ID 목록을 앱에 한 번에 보냅니다.

1. 데이터의 첫 페이지를 요청하기 전에 모든 ID 목록을 캐시합니다.

2. 다음에 대한 데이터를 요청합니다. 각 페이지에서 관련 ID 목록 매개변수를 가져오기만 하면 됩니다.

이 방법은 Tencent News와 같이 ID 목록이 그다지 크지 않은(수백 개의 데이터) 비즈니스 시나리오에 적합합니다.