SpringCloud 큰 파일 분할 단점 업로드 실현 원리

배경
사용자 로 컬 에 txt 또는 csv 파일 이 있 습 니 다.비 즈 니스 데이터 베 이 스 를 내 보 내 든 다른 경로 로 가 져 오 든 개미의 빅 데이터 분석 도 구 를 사용 하여 데이터 가공,발굴 과 공동 창작 응용 을 해 야 할 때 먼저 로 컬 파일 을 ODPS 에 업로드 해 야 합 니 다.일반적인 작은 파일 은 브 라 우 저 를 통 해 서버 에 업로드 하고 중간 전환 을 하면 이 루어 집 니 다.그러나 이 문서 가 10GB 급 에 이 르 렀 을 때 우 리 는 다른 형식의 기술 방안,즉 본 고 에서 논술 하고 자 하 는 방안 을 생각해 야 한다.
기술 요 구 는 주로 다음 과 같은 몇 가지 가 있다.
빅 데 이 터 량,10G 레벨 이상 지원
안정성:네트워크 이상 제거 100%성공
정확성:데이터 분실 없 음,읽 기와 쓰기 정확성 100%
효율:1G 파일 분 급,10G 파일 시간 급
체험:실시 간 진도 감지,네트워크 이상 정지점 전송,맞 춤 형 문자 특수 처리
2 파일 업로드 선택
파일 을 ODPS 에 업로드 하 는 기본 적 인 사 고 는 먼저 파일 을 특정한 중간 구역 에 업로드 한 다음 에 ODPS 에 동기 화 하 는 것 이다.저장 매체 에 따라 두 가지 로 나 눌 수 있 는데 하 나 는 서버 디스크 를 응용 하 는 것 이 고 다른 하 나 는 중간 미디어 이다.OSS 는 아 리 클 라 우 드 가 추천 하 는 대량의 안전 하고 원가 가 낮은 클 라 우 드 저장 서비스 이 며 풍부 한 API 지원 이 있어 중간 미디어 의 최 우선 선택 이 된다.한편,파일 을 OSS 에 업로드 하 는 것 은 웹 직접 전송 과 sdk 업로드 두 가지 방안 으로 나 뉘 기 때문에 업로드 방안 은 다음 과 같은 세 가지 가 있 고 상세 한 장단 점 은 다음 과 같다.

개미의 텍스트 업로드 기능 이 발전 하 는 과정 에서 첫 번 째,두 번 째 방안 을 모두 실천 하고 단점 이 뚜렷 하 다.상기 표 에서 말 한 것 처럼 업무 수 요 를 만족 시 키 지 못 하기 때문에 큰 파일 업로드 최종 방안 은 방안 3 이다.
3 전체 방안
다음은 방안 3 의 전체 과정 설명도 다.

요청 절 차 는 다음 과 같 습 니 다.
사용 자 는 응용 서버 에 업로드 policy 와 리 셋 설정 을 가 져 옵 니 다.
서버 를 사용 하여 업로드 policy 와 리 셋 을 되 돌려 줍 니 다.
사용자 가 직접 OSS 에 파일 업로드 요청 을 보 냅 니 다.
파일 데이터 가 업로드 되면 OSS 가 사용자 에 게 Response 를 주기 전에 OSS 는 사용자 의 리 셋 설정 에 따라 사용자 의 서버 를 요청 합 니 다.응용 서버 가 성공 적 으로 되 돌아 오 면 사용자 에 게 성공 하고 응용 서버 가 실패 하면 OSS 도 사용자 에 게 실패 로 돌아 갑 니 다.이렇게 해서 사용자 업로드 성공 을 확 보 했 고 응용 서버 는 이미 통 지 를 받 았 다.
응용 서버 가 OSS 에 되 돌려 줍 니 다.
OSS 는 서버 가 되 돌려 준 내용 을 사용자 에 게 되 돌려 줍 니 다.
배경 동기 화 엔진 을 시작 하여 oss 에서 odps 까지 의 데이터 동기 화 를 실행 합 니 다.
실시 간 진 도 를 응용 서버 에 되 돌려 주 고 사용자 에 게 보 여 줍 니 다.
4 기술 방안
4.1 업로드
OSS 는 다양한 SDK 를 제공 합 니 다.간단 한 업로드,폼 업로드,정지점 전송 등 이 있 습 니 다.초대형 파일 에 제공 하 는 업로드 기능 은 정지점 전송 방식 을 사용 하 는 것 을 권장 합 니 다.장점 은 큰 파일 에 대해 필름 을 나 누 어 업로드 할 수 있 고 OSS 의 병행 처리 능력 을 이용 하여 중간 정지 도 현재 위치 에서 계속 업로드 할 수 있 으 며 네트워크 환경 영향 을 최소 화 할 수 있 습 니 다.
4.2 다운로드
OSS 파일 다운로드 역시 여러 가지 방식 이 있 습 니 다.일반 다운로드,스 트림 다운로드,정지점 전송 다운로드,범위 다운로드 등 이 있 습 니 다.로 컬 에 직접 다운로드 하면 정지점 전송 다운 로드 를 권장 합 니 다.그러나 우리 의 수 요 는 파일 로 컬 저장 소 를 다운로드 하 는 것 이 아니 라 파일 을 읽 는 것 입 니 다.OSS 에서 ODPS 까지 동기 화 되 기 때문에 중간 저장 소 를 하지 않 고 직접 읽 고 쓰 는 것 입 니 다.한편 으로 는 OSS 스 트림 으로 읽 고,한편 으로 는 ODPS tunnel 로 업로드 하 며,다 중 스 레 드 읽 기와 쓰기 방식 으로 동기 화 속 도 를 높 인 다.
4.3 2 단계 데이터 이전
파일 은 로 컬 에서 ODPS 까지 두 단계 로 나 눌 수 있 습 니 다.첫 번 째 단 계 는 전단 에서 세 션 으로 나 누 어 로 컬 파일 을 OSS 에 업로드 하고 두 번 째 단 계 는 백 엔 드 스 트림 으로 데 이 터 를 OSS 에서 ODPS 로 동기 화 합 니 다.아래 그림 과 같 습 니 다.

관련 기술 포인트:
4.3.1 전단,js sdk 테이프 STS token 안전 업로드
업로드 해 야 할 파일 이 클 때 멀 티 파 트 업로드 인 터 페 이 스 를 통 해 필름 을 나 누 어 업로드 할 수 있 습 니 다.블록 버스터 업로드 의 장점 은 하나의 큰 요청 을 여러 개의 작은 요청 으로 나 누 어 실행 하 는 것 이다.그러면 일부 요청 이 실패 한 후에 전체 파일 을 다시 업로드 하지 않 고 실패 한 블록 버스터 만 업로드 하면 된다.일반적으로 100 MB 이상 의 파일 에 대해 서 는 필름 을 나 누 어 업로드 하 는 방법 을 권장 하 며,매번 필름 을 나 누 어 업로드 할 때마다 새로운 OSS 인 스 턴 스 를 다시 시작 하 는 것 을 권장 합 니 다.
아 리 클 라 우 드 분할 업로드 프로 세 스 는 주로 3 개의 api 를 호출 합 니 다.
Initiate Multipart Upload,분할 작업 초기 화 인터페이스.
Upload Part,단독 분할 업로드 인터페이스.
Complete Multipart Upload,분할 업로드 완료 후 작업 완료 인터페이스
임시 방문 증빙 은 알 리 클 라 우 드 시 큐 리 티 토 큰 서비스(STS)를 통 해 권한 을 부여 하 는 방식 이다.그 실현 은 STS 자바 SDK 를 참조 하 십시오.임시 방문 증명서 의 절 차 는 다음 과 같다.
클 라 이언 트 가 서버 측 에 권한 수 여 를 요청 합 니 다.서버 에서 클 라 이언 트 의 합 법성 을 먼저 검증 합 니 다.합 법 적 인 클 라 이언 트 라면 서버 측은 자신의 AccessKey 를 사용 하여 STS 에 권한 을 요청 하 는 요청 을 할 것 입 니 다.구체 적 으로 방문 통 제 를 참고 할 수 있 습 니 다.
서버 에서 임시 증명 서 를 가 져 와 클 라 이언 트 에 게 되 돌려 줍 니 다.
클 라 이언 트 는 가 져 온 임시 증명 서 를 사용 하여 OSS 에 업로드 요청 을 합 니 다.더 자세 한 요청 구 조 는 임시 권한 수여 방문 을 참고 할 수 있 습 니 다.클 라 이언 트 는 이 증명 서 를 캐 시 하여 업로드 할 수 있 으 며,증빙 이 효력 을 잃 을 때 까지 서버 측 에 새로운 증명 서 를 요청 할 수 있 습 니 다.
4.3.2 백 엔 드,다 중 스 트림 읽 기
OSS 엔 드:다운로드 할 파일 이 너무 크 거나 한꺼번에 다운로드 하 는 데 시간 이 너무 오래 걸 리 면 다 중 스 트림 으로 다운로드 하여 파일 다운로드 가 완 료 될 때 까지 한 번 에 일부 내용 을 처리 할 수 있 습 니 다.
ODPS 단:tunnel sdk 는 OSS 스 트림 데 이 터 를 직접 기록 합 니 다.완전한 데이터 기록 절 차 는 보통 다음 과 같은 절 차 를 포함 합 니 다.
먼저 데 이 터 를 구분한다.
모든 데이터 블록 에 block id 를 지정 합 니 다.즉,openRecordWriter(id)를 호출 합 니 다.
그 다음 에 하나 이상 의 스 레 드 로 각각 이 block 을 올 리 고 특정한 block 업로드 에 실패 한 후에 전체 block 을 다시 전송 해 야 합 니 다.
모든 block 을 업로드 한 후,서버 에 업로드 에 성공 한 blockid list 를 제공 하여 검사 합 니 다.즉,session.comit([1,2,3,...])를 호출 합 니 다.
한편,서버 가 block 관리,연결 시간 초과 등에 대한 제한 으로 인해 업로드 과정 논리 가 복잡 해 졌 고 업로드 과정 을 간소화 하기 위해 SDK 는 더욱 고 급 스 러 운 RecordWriter―Tunnel BufferWriter 를 제공 했다.
총화
실측 결과 에 따 르 면 본 고의 업로드 방안 은 제1 절 에 제 시 된 몇 가지 기술 요 구 를 실현 했다.다음 과 같다.
초대형 데 이 터 량,10G 등급 이상 을 지원 하 는 데 아무런 부담 이 없고 주로 전단 에서 필름 업로드 에 필름 한 도 를 설정 하면 된다(최대 10000 편,필름 당 최대 100 G).현 재 는 필름 당 1M 를 설정 하여 10G 수 요 를 만족 시 키 고 있다.
안정성:실측 관찰 네트워크 이상 상황 이 비교적 적 고 파일 내용 이 정상 적 인 상황 에서 100%성공 합 니 다.
정확성:실측 데 이 터 를 잃 어 버 리 지 않 고 읽 기와 쓰기 의 정확성 은 100%입 니 다.
효율:사무 용 네트워크 대역 폭 1.5M/s 의 경우 1G 파일 분 급,10G 파일 시간 급,실제 속 도 는 사용자 측의 현재 네트워크 대역 폭 변화 에 따라 달라 집 니 다.
체험:실시 간 진도 감지,네트워크 이상 단점 전송,맞 춤 형 문자 특수 처리 등 고급 기능 은 사용자 체험 을 향상 시 킬 수 있다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.