Java에서 높은 동시성을 해결하는 방법-java지도 시간-php.cn

Java의 높은 동시성 문제 해결 방법: 1. 코드 최적화 2. 정적 HTML 3. 서버에서 이미지 분리 4. 데이터베이스 클러스터 7. CDN 가속 기술

Java에서 높은 동시성을 해결하는 방법

높은 동시성은 항상 Java에서 해결해야 할 문제였는데, 어떻게 해결해야 할까요? 참고할 수 있는 몇 가지 방법은 다음과 같습니다.

(추천 튜토리얼: java 강좌)

Java의 높은 동시성 해결 방법:

1. 가장 기본적인 것부터 시작하여 우리가 작성한 코드를 최적화하고 불필요한 리소스 낭비를 줄입니다.

a. 전체 애플리케이션에 하나의 인스턴스만 필요한 클래스의 경우 싱글톤 패턴을 사용할 수 있습니다. 문자열 연결 작업의 경우 도구 클래스의 정적 메서드를 통해 액세스할 수 있는 StringBuffer 또는 StringBuilder를 사용합니다.

b. 잘못된 방법을 사용하지 말고 조건부 판단을 위해 instanceof를 사용하지 마십시오. Vector보다 성능이 뛰어난 ArrayList와 같은 효율적인 Java 클래스를 사용하세요.

2. HTML static

링크 주소를 통해 접속합니다. 이 링크 주소를 통해 서버의 해당 모듈이 요청을 처리하고 해당 jsp 페이지로 이동하여 최종적으로 원하는 데이터를 생성합니다. 하지만 요청이 수천만 건이고 동시 요청이 너무 많으면 서버에 부담이 가중되고 최악의 경우 서버가 다운되는 경우도 있습니다. 그렇다면 이런 상황을 피하려면 어떻게 해야 할까요? test.do에 대한 초기 요청의 결과를 html 파일에 저장하고, 사용자가 매번 이 html 파일에 액세스하여 더 이상 서버에 액세스할 필요가 없게 된다면 서버에 부담이 되지 않을까요? 줄인?

정적 페이지를 자동으로 생성하는 방법은 무엇입니까? 사용자가 방문하면 test.html이 자동으로 생성되어 사용자에게 표시됩니다.

3. 이미지 서버 분리

웹 서버의 경우 이미지가 가장 많은 리소스를 소모하므로 페이지와 이미지를 분리하는 것이 필요합니다. 이러한 아키텍처는 페이지 액세스 요청을 제공하는 서버 시스템에 대한 부담을 줄이고 이미지 문제로 인해 시스템이 충돌하지 않도록 보장할 수 있습니다. 이미지 서버에서는 다양한 구성을 최적화할 수 있습니다.

4. 캐싱

제가 특히 접하게 된 캐싱 메커니즘은 Hibernate의 캐싱 메커니즘입니다. 매번 데이터베이스에서 데이터를 가져오는 것을 방지하기 위해 사용자가 자주 액세스하는 데이터를 메모리에 저장합니다. 캐시가 매우 큰 경우에도 메모리에 있는 캐시를 하드 디스크에 저장할 수 있습니다. 또한 시스템의 스트레스 저항성을 높일 수 있는 고급 분산 캐시 데이터베이스를 사용합니다.

5. 일괄 전송

특정 프로젝트를 진행할 때 한 번에 너무 많은 매개변수가 전송되었는데, 데이터베이스에 한 번에 전송할 수 있는 최대 매개변수 수가 30,000개라고 명시되어 있었습니다. 당시 기록이 50,000개인데 어떻게 전송하나요? 결국, 엘리베이터가 한 번에 너무 많은 사람을 수용할 수 없으면 과체중 버그를 보고하므로 사람들이 일괄적으로 전송됩니다.

또 시험 시스템에서 너무 많은 수험생이 동시에 데이터베이스에 제출하면 데이터베이스에 대한 부담이 커지고 때로는 다운되기도 했습니다. 그 당시 사용된 방법은 기다리지 않고 Ajax 비동기 전송을 사용하는 것이었습니다. 전원이 켜지면 응시자의 답변이 자동으로 제출되므로 갑작스런 정전으로 인해 이전에 답변했던 문제가 손실되는 것을 방지할 수 있습니다.

6. 데이터베이스 클러스터

복잡한 애플리케이션과 많은 수의 사용자가 이에 액세스하는 경우 하나의 데이터 세트로는 곧 수요를 충족할 수 없으므로 데이터베이스 클러스터 또는 데이터베이스 테이블 해싱을 사용해야 합니다.

애플리케이션에 비즈니스 및 애플리케이션 또는 기능 모듈을 설치하여 데이터를 분리합니다. 서로 다른 모듈은 서로 다른 데이터베이스 또는 테이블에 해당하며 특정 전략에 따라 특정 페이지 또는 기능에 대해 더 작은 데이터베이스 해싱을 수행합니다.

7. DB 최적화

a. 데이터베이스를 설계할 때 향후 유지 관리를 고려해야 합니다. 데이터베이스를 설계할 때 따라야 할 원칙은 세 가지입니다.

b. 인덱스 설정: 테이블이 쿼리에 자주 사용되고 추가 및 수정에 거의 사용되지 않는 경우 추가, 수정 및 삭제를 위해 인덱스를 설정할 수 있습니다. 지수는 지수가 우리에게 제공하는 효율성을 크게 초과합니다.

c. 테이블 필드의 유형 선택에는 필드 길이, 유형 등이 적절하게 포함되어야 합니다. 선택은 실제 저장된 데이터를 기반으로 해야 합니다. 길이가 너무 길어서는 안 됩니다. 그렇지 않으면 효율성에 영향을 미칩니다.

d. 기본 키는 이 테이블을 나타내고 외래 키는 테이블을 연결하는 테이블 그룹을 나타내기 때문에 주의해서 사용해야 합니다.

e. 데이터베이스 작업에서는

prepareStatement가 미리 컴파일되어 있으므로 prepareStatement를 사용하고 더 적은 문을 사용해 보세요.

연결은 읽기 전용으로 설정되어 있습니다. 연결은 라이브러리에 대한 연결이므로 그냥 사용할 수 있습니다.

연결 풀을 사용하면 데이터베이스의 기본 연결 수를 수정할 수 있습니다.

8. 로드 밸런싱

로드 밸런싱은 대규모 웹사이트에서 높은 로드 액세스와 다수의 동시 요청을 해결하는 고급 솔루션이 될 것입니다.

로드 밸런싱 기술은 수년 동안 개발되었으며 선택할 수 있는 전문 서비스 제공업체와 제품이 많이 있습니다. 저는 개인적으로 몇 가지 솔루션을 접했는데 그 중 두 가지를 참고로 사용할 수 있습니다.

(1) 하드웨어 4계층 스위칭

Layer-4 스위칭은 3계층과 4계층 정보 패킷의 헤더 정보를 이용하여 적용 간격에 따른 업무 흐름을 파악하고, 전체 업무 흐름을 할당한다. 처리를 위해 적절한 애플리케이션 서버에 간격 세그먼트를 보냅니다.

4번째 레이어 전환 기능은 가상 IP와 같아서 물리적 서버를 가리킵니다. 전송하는 서비스는 HTTP, FTP, NFS, Telnet 또는 기타 프로토콜을 포함한 다양한 프로토콜을 따릅니다. 이러한 서비스에는 물리적 서버를 기반으로 하는 복잡한 로드 밸런싱 알고리즘이 필요합니다. IP 세계에서 서비스 유형은 터미널 TCP 또는 UDP 포트 주소에 의해 결정됩니다. 레이어 4 스위칭에서는 응용 프로그램 범위가 소스 및 터미널 IP 주소, TCP 및 UDP 포트에 의해 결정됩니다.

하드웨어 4레이어 스위칭 제품 분야에는 Alteon, F5 등과 같이 선택할 수 있는 잘 알려진 제품이 있습니다. 이러한 제품은 비싸지만 그만한 가치가 있으며 매우 뛰어난 성능과 성능을 제공할 수 있습니다. 매우 유연한 관리 기능. "Yahoo China"는 원래 2,000대에 가까운 서버를 보유하고 있었지만 이를 완료하는 데 3~4개의 Alteon만 사용했습니다.

(2) 소프트웨어 4레이어 스위칭

하드웨어 4레이어 스위치의 원리를 모두가 알게 된 후, OSI 모델을 기반으로 한 소프트웨어 4레이어 스위칭이 등장했습니다. 이러한 솔루션의 원리는 동일하지만 성능은 동일합니다. 약간 더 나쁩니다. 그러나 어느 정도의 압박은 여전히 충족하기 쉽습니다. 어떤 사람들은 소프트웨어 구현 방법이 실제로 더 유연하며 처리 능력은 전적으로 구성의 친숙성에 달려 있다고 말합니다.

Linux에서 일반적으로 사용되는 LVS를 사용하여 소프트웨어의 4계층 전환을 해결할 수 있습니다. LVS는 Linux 가상 서버로 하트비트 라인 기반의 실시간 재해 대응 솔루션을 제공하고 시스템의 견고성을 향상시킵니다. 유연한 가상화를 제공하며 VIP 구성 및 관리 기능은 분산 시스템에 필수적인 여러 애플리케이션 요구 사항을 동시에 충족할 수 있습니다.

일반적인 로드 밸런싱 전략은 소프트웨어 또는 하드웨어 4계층 전환을 기반으로 Squid 클러스터를 구축하는 것입니다. 이 아이디어는 검색 엔진을 포함한 많은 대규모 웹사이트에서 채택되고 있습니다. 이 아키텍처는 저비용, 고성능이며 확장성이 뛰어납니다. , 언제든지 아키텍처에 노드를 추가하거나 제거하는 것이 매우 쉽습니다.

대규모 웹사이트의 경우 위에서 언급한 각 방법을 동시에 사용할 수 있습니다. 여기서 소개하는 내용은 비교적 간단합니다. 구체적인 구현 과정에는 모든 사람이 점차 익숙해지고 이해해야 할 세부 사항이 많이 있습니다. 때로는 작은 오징어 매개변수나 아파치 매개변수 설정이 시스템 성능에 큰 영향을 미칠 수 있습니다.

9. 미러링

미러링은 성능과 데이터 보안을 향상하기 위해 대규모 웹사이트에서 자주 사용하는 방법입니다. 미러링 기술은 ChinaNet과 EduNet 등 다양한 네트워크 액세스 공급자와 지역으로 인한 사용자 액세스 속도 차이를 해결할 수 있습니다. 이들 사이의 차이점으로 인해 많은 웹사이트가 교육 네트워크 내에 미러 사이트를 구축하게 되었으며, 데이터는 정기적으로 또는 실시간으로 업데이트됩니다. 미러링의 세부 기술에 대해서는 여기서 너무 자세히 설명하지 않겠습니다. 선택할 수 있는 전문 기성 솔루션 아키텍처와 제품이 많이 있습니다. rsync 및 Linux의 기타 도구와 같은 소프트웨어를 통해 이를 구현하는 저렴한 방법도 있습니다.

10. 최신: CDN 가속 기술

CDN이란 무엇인가요?

CDN의 정식 명칭은 콘텐츠 유통 네트워크입니다. 그 목적은 기존 인터넷에 새로운 네트워크 아키텍처 계층을 추가하여 웹 사이트의 콘텐츠를 사용자에게 가장 가까운 네트워크 "에지"에 게시하여 사용자가 근처에서 필요한 콘텐츠를 얻고 응답 속도를 향상시킬 수 있도록 하는 것입니다. 사용자의 웹사이트 액세스.

CDN은 미러링보다 더 똑똑하기 때문에 미러링과 다릅니다. 또는 CDN = 더 스마트한 미러링 + 캐싱 + 트래픽 전환이라는 비유를 사용할 수 있습니다. 따라서 CDN은 인터넷 네트워크의 정보 흐름 효율성을 크게 향상시킬 수 있습니다. 기술적으로는 작은 네트워크 대역폭, 대규모 사용자 방문, 불균등한 콘센트 분포로 인해 발생하는 문제를 종합적으로 해결하고 사용자의 웹 사이트 액세스 응답 속도를 향상시킬 것입니다.

CDN 유형 특성:

CDN 구현은 미러링, 캐싱, 전용선의 세 가지 범주로 구분됩니다.

미러 사이트는 가장 일반적이며 콘텐츠를 직접 게시할 수 있으며 정적 및 준동적 데이터 동기화에 적합합니다. 그러나 새로운 서버를 구입하고 유지하는 데 드는 비용이 상대적으로 높으며, 관리 및 유지 관리를 위해서는 다양한 지역에 미러 서버를 설치하고 전문 기술자를 배치해야 합니다. 대규모 웹사이트의 경우 업데이트를 위한 대역폭 비용도 크게 증가합니다.

캐싱, 저렴한 비용, 정적 콘텐츠에 적합합니다. 인터넷 통계에 따르면 80% 이상의 사용자가 웹 사이트 콘텐츠의 20%에 자주 액세스하는 것으로 나타났습니다. 이 규칙에 따라 캐시 서버는 대부분의 고객의 정적 요청을 처리할 수 있는 반면, 원래 서버는 논스톱 요청의 약 20%만 처리하면 됩니다. 요청 및 동적 요청을 캐싱하면 클라이언트 요청의 응답 시간이 크게 단축되고 원래 서버의 로드가 줄어듭니다.

CDN 서비스는 일반적으로 전국 주요 노드에 캐시 서버를 배치합니다.

전용 회선을 통해 사용자는 데이터 소스에 직접 액세스하고 데이터를 동적으로 동기화할 수 있습니다.