Java의 높은 동시성 솔루션 및 고부하 최적화의 예
- 黄舟원래의
- 2017-07-27 10:51:141285검색
개인 웹사이트와 같은 작은 웹사이트는 가장 간단한 HTML 정적 페이지를 사용하여 구현할 수 있으며, 일부 사진을 사용하여 아름다운 효과를 얻을 수 있습니다. 이러한 웹사이트는 높은 시스템 아키텍처와 성능 요구 사항을 갖습니다. 매우 간단합니다. 인터넷 비즈니스가 지속적으로 풍부해지면서 웹 사이트 관련 기술은 수년간의 개발을 거쳐 매우 미세한 측면으로 세분화되었습니다. 특히 대규모 웹 사이트의 경우 사용되는 기술은 하드웨어부터 매우 높은 요구 사항을 갖습니다. 소프트웨어, 프로그래밍 언어, 데이터베이스, 웹 서버, 방화벽 등과 같은 다양한 분야에서 더 이상 원래의 단순한 HTML 정적 웹 사이트와 비교할 수 없습니다.
포털 등 대규모 웹사이트. 많은 수의 사용자 액세스와 높은 동시 요청에 직면하여 기본 솔루션은 고성능 서버, 고성능 데이터베이스, 고효율 프로그래밍 언어 및 고성능 웹 컨테이너를 사용하는 링크에 중점을 둡니다. 그러나 이러한 측면을 제외하면 대규모 웹사이트가 직면한 높은 부하 및 높은 동시성 문제에 대한 근본적인 해결책은 없습니다.
위에 제시된 여러 솔루션 아이디어는 어느 정도 더 큰 투자를 의미하기도 하며, 이러한 솔루션 아이디어는 병목 현상이 있고 확장성이 좋지 않습니다. 아래에서는 저비용, 고성능, 높은 확장성의 관점에서 논의하겠습니다. 내 경험에 대해 이야기해 주세요.
1. HTML 정적
사실, 가장 효율적이고 가장 적게 소비되는 것은 순전히 정적 HTML 페이지라는 것을 모두가 알고 있으므로 우리는 웹 사이트의 페이지에 정적 페이지를 사용하기 위해 최선을 다합니다. 실제로 가장 효과적인 방법입니다. 하지만 콘텐츠의 양이 많고 업데이트가 잦은 웹사이트의 경우 일일이 수동으로 구현할 수 없기 때문에 자주 방문하는 각종 포털 사이트의 뉴스 채널은 물론, 다른 포털 사이트의 뉴스 채널까지 공통 정보 게시 시스템인 CMS가 등장했습니다. 채널 관리, 정보 공개 시스템에 의해 관리 및 구현됩니다. 정보 공개 시스템은 가장 간단한 정보 입력을 실현할 수 있으며 채널 관리, 권한 관리, 자동 크롤링 등과 같은 기능도 가질 수 있습니다. 대규모 웹사이트에는 효율적이고 관리 가능한 CMS가 필수적입니다.
포털, 정보 게시형 웹사이트 외에도 상호작용성이 요구되는 커뮤니티형 웹사이트의 경우 최대한 정적인 상태를 유지하는 것도 커뮤니티의 게시물과 기사를 실시간으로 정적으로 만드는 것이 성능 향상에 도움이 될 수 있습니다. 업데이트 시 정적화는 NetEase 커뮤니티 등에서와 마찬가지로 Mop의 hodgepodge에서도 널리 사용되는 전략입니다.
동시에 html 정적화는 일부 캐싱 전략에서 사용되는 수단이기도 합니다. 데이터베이스 쿼리를 자주 사용하지만 콘텐츠 업데이트가 매우 적은 시스템의 애플리케이션의 경우 공개 설정 정보와 같은 html 정적화 사용을 고려할 수 있습니다. 포럼 정보는 현재 주류 포럼에서 관리하고 데이터베이스에 저장할 수 있습니다. 실제로 이 정보 중 많은 양이 프런트엔드 프로그램에서 호출되지만 업데이트 빈도는 매우 적습니다. 많은 양의 데이터베이스 액세스 요청을 피하기 위해 백그라운드를 업데이트할 때 콘텐츠가 정적입니다.
2. 이미지 서버 분리
아파치, IIS, 기타 컨테이너 등 웹 서버의 경우 이미지가 가장 많은 리소스를 소비하므로 페이지에서 이미지를 분리하는 것이 필요합니다. 기본 이는 대규모 웹사이트에서 사용하는 전략입니다. 모든 웹사이트에는 독립적인 이미지 서버가 있거나 여러 개의 이미지 서버가 있습니다. 이러한 아키텍처는 페이지 액세스 요청을 제공하는 서버 시스템에 대한 부담을 줄일 수 있으며, 그림 문제로 인해 시스템이 충돌하지 않도록 보장할 수 있습니다. 예를 들어, 아파치는 응용 프로그램 서버에서 수행할 수 있습니다. ContentType을 구성할 때 최선을 다해 지원하고 가능한 한 적은 수의 LoadModule을 사용하여 더 높은 시스템 소비와 실행 효율성을 보장하세요.
3. 데이터베이스 클러스터 및 데이터베이스 테이블 해싱
대형 웹사이트에는 복잡한 애플리케이션이 있으며, 이러한 애플리케이션은 데이터베이스를 사용해야 하며, 이 때 데이터베이스의 병목 현상이 빠르게 드러납니다. 하나의 데이터베이스는 곧 애플리케이션을 만족시킬 수 없게 되므로 데이터베이스 클러스터링이나 데이터베이스 테이블 해싱을 사용해야 합니다.
데이터베이스 클러스터의 경우, Oracle, Sybase 등이 좋은 솔루션을 갖고 있는 경우가 많습니다. MySQL에서 주로 사용하는 Master/Slave도 비슷한 솔루션을 사용하고 있으니 참고하시기 바랍니다. 해당 솔루션을 구현할 수 있습니다.
위에서 언급한 데이터베이스 클러스터는 아키텍처, 비용, 확장성 측면에서 사용되는 DB 유형에 따라 제한되므로 애플리케이션 관점에서 시스템 아키텍처 개선을 고려해야 합니다. 라이브러리 테이블 해싱은 일반적으로 가장 많이 사용됩니다. 효과적인 솔루션 계획. 우리는 데이터베이스를 분리하기 위해 애플리케이션에 비즈니스 및 애플리케이션 또는 기능 모듈을 설치한 다음 특정 전략을 사용하여 사용자 테이블과 같은 특정 페이지 또는 기능에서 더 작은 데이터베이스 해시를 수행합니다. 사용자 ID에 따른 테이블을 생성하여 저렴한 비용으로 시스템 성능을 향상시킬 수 있으며 확장성이 좋습니다. 소후의 포럼은 포럼의 사용자, 설정, 게시물, 기타 정보를 데이터베이스로 분리한 후 게시물과 사용자를 섹션과 ID에 따라 데이터베이스와 테이블로 해싱하는 구조를 채택하고 있으며, 마지막으로 구성에서 간단하게 구성할 수 있습니다. 이를 통해 시스템은 언제든지 저비용 데이터베이스를 추가하여 시스템 성능을 보완할 수 있습니다.
4. 캐싱
모든 기술 담당자는 캐시라는 단어를 접하게 되었으며 캐시는 여러 곳에서 사용됩니다. 웹 사이트 아키텍처 및 웹 사이트 개발에서 캐싱도 매우 중요합니다. 여기서는 먼저 가장 기본적인 두 가지 캐시에 대해 이야기합니다. 고급 및 분산 캐싱에 대해서는 나중에 설명합니다.
아키텍처 캐싱 측면에서 Apache에 익숙한 사람이라면 Apache가 자체 캐싱 모듈을 제공하거나 캐싱을 위해 추가 Squid 모듈을 사용할 수 있다는 것을 알 것입니다. 두 방법 모두 Apache의 액세스 응답 기능을 효과적으로 향상시킬 수 있습니다.
웹사이트 프로그램 개발 시 캐시(Cache)는 흔히 사용되는 캐시 인터페이스로 웹 개발에 사용할 수 있습니다. 예를 들어 Java로 개발할 때 일부 데이터를 캐시하고 통신하고 공유할 수 있도록 사용됩니다. 일부 대규모 커뮤니티에 의해. 또한 웹 언어 개발을 사용할 때 각 언어에는 기본적으로 자체 캐시 모듈과 메서드가 있습니다. PHP에는 Pear의 캐시 모듈이 있고 Java에는 더 많은 것이 있습니다. .net에는 익숙하지 않지만 분명히 있을 것이라고 생각합니다.
5. 미러링
미러링은 성능과 데이터 보안을 향상하기 위해 대규모 웹사이트에서 자주 사용하는 방법입니다. 미러링 기술은 ChinaNet과 EduNet 등 다양한 네트워크 액세스 공급자 및 지역으로 인한 사용자 액세스 속도 차이를 해결할 수 있습니다. 이들 사이의 차이점으로 인해 많은 웹사이트가 교육 네트워크 내에 미러 사이트를 구축하게 되었으며, 데이터는 정기적으로 또는 실시간으로 업데이트됩니다. 미러링의 세부 기술에 대해서는 여기서 너무 자세히 설명하지 않겠습니다. 선택할 수 있는 전문 기성 솔루션 아키텍처와 제품이 많이 있습니다. rsync 및 Linux의 기타 도구와 같은 소프트웨어를 통해 이를 구현하는 저렴한 방법도 있습니다.
6. 로드 밸런싱
로드 밸런싱은 대규모 웹사이트에서 높은 로드 액세스와 많은 수의 동시 요청을 해결하는 최고의 솔루션이 될 것입니다.
로드 밸런싱 기술은 수년 동안 개발되었으며 선택할 수 있는 전문 서비스 제공업체와 제품이 많이 있습니다. 저는 개인적으로 몇 가지 솔루션을 접했는데 그 중 두 가지를 참고로 사용할 수 있습니다.
1) 하드웨어 4계층 스위칭
4계층 스위칭은 3, 4계층 패킷의 헤더 정보를 이용하여 적용 구간에 따른 비즈니스 흐름을 파악하고, 전체 구간 세그먼트의 비즈니스 흐름을 적절한 위치에 할당한다. 처리를 위한 응용 프로그램 서버입니다. 레이어 4 스위칭 기능은 물리적 서버를 가리키는 가상 IP와 같습니다. 전송하는 서비스는 HTTP, FTP, NFS, Telnet 또는 기타 프로토콜을 포함한 다양한 프로토콜을 따릅니다. 이러한 서비스에는 물리적 서버를 기반으로 하는 복잡한 로드 밸런싱 알고리즘이 필요합니다. IP 세계에서 서비스 유형은 터미널 TCP 또는 UDP 포트 주소에 의해 결정됩니다. 레이어 4 스위칭에서는 응용 프로그램 범위가 소스 및 터미널 IP 주소, TCP 및 UDP 포트에 의해 결정됩니다.
하드웨어 4레이어 스위칭 제품 분야에는 Alteon, F5 등과 같이 선택할 수 있는 잘 알려진 제품이 있습니다. 이러한 제품은 비싸지만 그만한 가치가 있으며 매우 뛰어난 성능과 성능을 제공할 수 있습니다. 매우 유연한 관리 기능. Yahoo China는 3~4개의 Alteon을 사용하여 거의 2,000대의 서버를 처리했습니다.
2) 소프트웨어 4레이어 스위칭
하드웨어 4레이어 스위치의 원리를 모두가 알게 된 후, OSI 모델을 기반으로 한 소프트웨어 4레이어 스위칭이 등장했습니다. 이러한 솔루션의 원리는 동일하지만 성능은 동일합니다. 약간 더 나쁘다. 그러나 어느 정도의 부담은 여전히 충족하기 쉽습니다. 어떤 사람들은 실제로 소프트웨어 구현 방법이 더 유연하고 처리 능력은 전적으로 구성의 친숙성에 달려 있다고 말합니다.
Linux에서 일반적으로 사용되는 LVS를 사용하여 소프트웨어의 4계층 전환을 해결할 수 있습니다. LVS는 Linux 가상 서버로 하트비트 라인 기반의 실시간 재해 대응 솔루션을 제공하고 시스템의 견고성을 향상시킵니다. 유연한 가상 VIP 구성 및 관리 기능을 제공하여 분산 시스템에 필수적인 여러 애플리케이션 요구 사항을 동시에 충족할 수 있습니다.
일반적인 로드 밸런싱 전략은 소프트웨어 또는 하드웨어 4계층 전환을 기반으로 Squid 클러스터를 구축하는 것입니다. 이 아이디어는 검색 엔진을 포함한 많은 대규모 웹사이트에서 채택되고 있습니다. 이 아키텍처는 저비용, 고성능이며 확장성이 뛰어납니다. , 언제든지 아키텍처에 노드를 추가하거나 제거하는 것이 매우 쉽습니다. 이 구조를 자세히 정리해서 여러분과 논의해보겠습니다.
고동시성 및 고부하 웹사이트를 처리하기 위해 Java에서 데이터베이스를 설계하는 방법(Java 튜토리얼, Java 대용량 데이터 처리, Java 고부하 데이터)
1: 높은 동시성과 고부하를 강조하는 데이터베이스 로드가 많은 웹사이트
예, 첫 번째는 대부분의 애플리케이션이 직면하는 첫 번째 SPOF인 데이터베이스입니다. 특히 Web2.0 애플리케이션의 경우 데이터베이스의 응답을 먼저 해결해야 합니다.
일반적으로 MySQL이 가장 일반적으로 사용됩니다. 처음에는 데이터가 100만개 이상으로 증가하면 MySQL의 성능이 급격히 떨어집니다. 일반적인 최적화 방법은 쿼리와 작업이 서로 다른 서버에서 수행되는 동기 복제를 위한 M-S(마스터-슬레이브) 모드입니다. 제가 추천하는 방법은 M-M-Slave 방식으로, 2개의 마스터 Mysql과 여러 개의 슬레이브가 있습니다. 비록 2개의 마스터가 있지만 동시에 한 개만 활성화될 수 있다는 점에 유의해야 합니다. 두 개의 M을 사용하는 이유는 M이 다시 시스템의 SPOF가 되지 않도록 하기 위한 것입니다.
슬레이브는 추가로 로드 밸런싱을 수행할 수 있으며 LVS와 결합하여 다양한 슬레이브에 대한 선택 작업의 균형을 적절하게 맞출 수 있습니다.
위 아키텍처는 일정량의 부하를 감당할 수 있지만 사용자 수가 더욱 증가함에 따라 사용자 테이블 데이터가 1,000만 개를 초과하고 M이 SPOF가 됩니다. 슬레이브를 임의로 확장할 수 없습니다. 그렇지 않으면 복제 동기화 비용이 급등하게 됩니다. 어떻게 해야 합니까? 내 방법은 테이블 파티셔닝, 즉 비즈니스 수준에서 파티셔닝하는 것입니다. 가장 간단한 것은 사용자 데이터를 예로 들어보겠습니다. ID와 같은 특정 분할 방법에 따라 서로 다른 데이터베이스 클러스터로 분할됩니다.
메타데이터 쿼리에는 글로벌 데이터베이스가 사용됩니다. 단점은 쿼리할 때마다 한 번씩 추가된다는 점입니다. 예를 들어 nightsailer 사용자를 쿼리하려면 먼저 전역 데이터베이스 그룹으로 이동하여 nightsailer에 해당하는 클러스터 ID를 찾은 다음 해당 그룹으로 이동해야 합니다. nightsailer의 실제 데이터를 찾기 위해 지정된 클러스터를 사용합니다.
각 클러스터는 M-M 모드 또는 M-M-슬레이브 모드를 사용할 수 있습니다. 이는 부하가 증가함에 따라 새로운 mysql 클러스터를 추가하기만 하면 되는 확장 가능한 구조입니다.
주의할 점은 다음과 같습니다.
1. 모든 auto_increment 필드를 비활성화합니다.
2. ID는 공통 알고리즘을 사용하여 중앙에서 할당되어야 합니다.
3. mysql 호스트의 로드와 실행 상태를 모니터링하는 더 나은 방법이 있어야 합니다. 서비스. 30개가 넘는 mysql 데이터베이스를 실행하고 있다면 무슨 뜻인지 이해하실 것입니다.
4. 영구 링크를 사용하지 마십시오(pconnect를 사용하지 마십시오). 대신 sqlrelay와 같은 타사 데이터베이스 연결 풀을 사용하거나 직접 수행하십시오. 왜냐하면 php4의 mysql 연결 풀에는 종종 문제가 있기 때문입니다.
두 번째: 동시성 및 부하가 높은 웹사이트의 시스템 아키텍처에 대한 HTML 정적화
사실 가장 효율적이고 비용이 적게 드는 방법은 순수 정적화라는 사실은 모두가 알고 있습니다. http://www.ablanxue.com/shtml /201207/776 .shtml html 페이지이므로 우리 웹사이트의 페이지에는 정적 페이지를 사용하려고 최선을 다합니다. 이 간단한 방법이 실제로 가장 효과적인 방법입니다. 하지만 콘텐츠의 양이 많고 업데이트가 잦은 웹사이트의 경우 일일이 수동으로 구현할 수 없기 때문에 자주 방문하는 각종 포털 사이트의 뉴스 채널은 물론, 다른 포털 사이트의 뉴스 채널까지 공통 정보 게시 시스템인 CMS가 등장했습니다. 채널 관리, 정보 공개 시스템에 의해 관리 및 구현됩니다. 정보 공개 시스템은 가장 간단한 정보 입력을 실현할 수 있으며 채널 관리, 권한 관리, 자동 크롤링 등과 같은 기능도 가질 수 있습니다. 대규모 웹사이트에는 효율적이고 관리 가능한 CMS가 필수적입니다.
포털, 정보 게시형 웹사이트 외에도 상호작용성이 요구되는 커뮤니티형 웹사이트의 경우 최대한 정적인 상태를 유지하는 것도 커뮤니티의 게시물과 글을 실시간으로 정적으로 만드는 것이 성능 향상에 도움이 될 수 있습니다. 업데이트 시 정적화는 NetEase 커뮤니티 등에서와 마찬가지로 Mop의 hodgepodge에서도 널리 사용되는 전략입니다.
동시에 HTML 정적화는 일부 캐싱 전략에서 사용되는 수단이기도 합니다. 데이터베이스 쿼리를 자주 사용하지만 콘텐츠 업데이트가 매우 적은 시스템의 애플리케이션의 경우 공개와 같이 이를 달성하기 위해 HTML 정적화를 사용할 수 있습니다. 포럼의 설정 정보는 현재 주류 포럼에서 관리되고 데이터베이스에 저장될 수 있습니다. 실제로 이러한 정보 중 많은 양이 프런트엔드 프로그램에서 호출되지만 업데이트 빈도는 매우 적습니다. 많은 양의 정보가 동시에 발생하는 것을 방지하기 위해 백그라운드를 업데이트할 때 콘텐츠의 이 부분을 정적으로 만듭니다.
웹사이트 HTML 정적 솔루션
서블릿 리소스 요청이 웹 서버에 도달하면 지정된 JSP 페이지를 채워 요청에 응답합니다.
HTTP 요청---웹 서버---서블릿--비즈니스 로직 처리 -- 데이터 액세스--JSP 채우기--응답 요청
정적 HTML 이후:
HTTP 요청---웹 서버---서블릿--HTML--응답 요청
정적 액세스 요청은 다음과 같습니다
서블릿:
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if(request.getParameter("chapterId") != null){
String chapterFileName = "bookChapterRead_"+request.getParameter("chapterId")+".html";
String chapterFilePath = getServletContext().getRealPath("/") + chapterFileName;
File chapterFile = new File(chapterFilePath);
if(chapterFile.exists()){response.sendRedirect(chapterFileName);return;}//如果有这个文件就告诉浏览器转向
INovelChapterBiz novelChapterBiz = new NovelChapterBizImpl();
NovelChapter novelChapter = novelChapterBiz.searchNovelChapterById(Integer.parseInt(request.getParameter("chapterId")));//章节信息
int lastPageId = novelChapterBiz.searchLastCHapterId(novelChapter.getNovelId().getId(), novelChapter.getId());
int nextPageId = novelChapterBiz.searchNextChapterId(novelChapter.getNovelId().getId(), novelChapter.getId());
request.setAttribute("novelChapter", novelChapter);
request.setAttribute("lastPageId", lastPageId);
request.setAttribute("nextPageId", nextPageId);
new CreateStaticHTMLPage().createStaticHTMLPage(request, response, getServletContext(),
chapterFileName, chapterFilePath, "/bookRead.jsp");
}
}HTML 정적 페이지 생성을 위한 클래스:
package com.jb.y2t034.thefifth.web.servlet;
import java.io.ByteArrayOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;
/** * 创建HTML静态页面
* 功能：创建HTML静态页面
* 时间：2009年1011日
* 地点：home
* @author mavk
*
*/ public class CreateStaticHTMLPage {
/**
* 生成静态HTML页面的方法
* @param request 请求对象
* @param response 响应对象
* @param servletContext Servlet上下文
* @param fileName 文件名称
* @param fileFullPath 文件完整路径
* @param jspPath 需要生成静态文件的JSP路径(相对即可)
* @throws IOException
* @throws ServletException
*/
public void createStaticHTMLPage(HttpServletRequest request, HttpServletResponse response,ServletContext servletContext,String fileName,String fileFullPath,String jspPath) throws ServletException, IOException{
response.setContentType("text/html;charset=gb2312");//设置HTML结果流编码(即HTML文件编码)
RequestDispatcher rd = servletContext.getRequestDispatcher(jspPath);//得到JSP资源
final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();//用于从ServletOutputStream中接收资源
final ServletOutputStream servletOuputStream = new ServletOutputStream(){//用于从HttpServletResponse中接收资源
public void write(byte[] b, int off,int len){
byteArrayOutputStream.write(b, off, len);
}
public void write(int b){
byteArrayOutputStream.write(b);
}
};
final PrintWriter printWriter = new PrintWriter(new OutputStreamWriter(byteArrayOutputStream));//把转换字节流转换成字符流
HttpServletResponse httpServletResponse = new HttpServletResponseWrapper(response){//用于从response获取结果流资源(重写了两个方法)
public ServletOutputStream getOutputStream(){
return servletOuputStream;
}
public PrintWriter getWriter(){
return printWriter;
}
};
rd.include(request, httpServletResponse);//发送结果流
printWriter.flush();//刷新缓冲区，把缓冲区的数据输出
FileOutputStream fileOutputStream = new FileOutputStream(fileFullPath);
byteArrayOutputStream.writeTo(fileOutputStream);//把byteArrayOuputStream中的资源全部写入到fileOuputStream中
fileOutputStream.close();//关闭输出流，并释放相关资源
response.sendRedirect(fileName);//发送指定文件流到客户端 }
}3: 동시성이 높고 로드가 많은 웹사이트는 캐싱, 로드 밸런싱 및 저장에 중점을 둡니다
캐싱은 또 다른 큰 문제입니다. 일반적으로 memcached를 사용합니다. 일반적으로 약 10개의 캐시 클러스터가 배포됩니다(10g 메모리 풀). 한 가지 주의할 점은
swap을 사용해서는 안 된다는 것입니다. Linux 스왑을 끄는 것이 가장 좋습니다.
负载均衡/加速
可能上面说缓存的时候，有人第一想的是页面静态化，所谓的静态html，我认为这是常识，不属于要点了。页面的静态化随之带来的是静态服务的
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS b3c39e73f82b358bad409308ba9884dclighttped====>squid(s) ====lighttpd
上面是我经常用的。注意，我没有用apache，除非特定的需求，否则我不部署apache，因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。
squid的使用可以解决文件的同步等等问题，但是需要注意，你要很好的监控缓存的命中率，尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论，这里不赘述。
存储
存储也是一个大问题，一种是小文件的存储，比如图片这类。另一种是大文件的存储，比如搜索引擎的索引，一般单文件都超过2g以上。
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS，优点是应用透明，缺点是费用较高。我是指
你购买盘阵的问题。我的项目中，存储量是2-10Tb，我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余，这方面可以参考google的gfs的论文。
大文件的存储，可以参考nutch的方案，现在已经独立为hadoop子项目。(你可以google it)
其他：
此外，passport等也是考虑的，不过都属于比较简单的了。
四：高并发高负载网站的系统架构之图片服务器分离
大家知道，对于Web 服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他 们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用 服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule， 保证更高的系统消耗和执行效率。
利用Apache实现图片服务器的分离
缘由：
起步阶段的应用，都可能部署在一台服务器上（费用上的原因）
第一个优先分离的，肯定是数据库和应用服务器。
第二个分离的，会是什么呢？各有各的考虑，我所在的项目组重点考虑的节约带宽，服务器性能再好，带宽再高，并发来了，也容易撑不住。因此，我这篇文章的重点在这里。这里重点是介绍实践，不一定符合所有情况，供看者参考吧，
环境介绍：
WEB应用服务器：4CPU双核2G, 内存4G
部署：Win2003/Apache Http Server 2.1/Tomcat6
数据库服务器：4CPU双核2G, 内存4G
部署：Win2003/MSSQL2000
步骤：
步骤一：增加2台配置为：2CPU双核2G，内存2G普通服务器，做资源服务器
部署：Tomcat6，跑了一个图片上传的简单应用，（记得指定web.xml的682fa04e96c314670032152167ed6ade），并指定域名为res1.***.com,res2.***.com，采用ajp协议
步骤二：修改Apache httpd.conf配置
原来应用的文件上传功能网址为：
1、/fileupload.html
2、/otherupload.html
在httpd.conf中增加如下配置
<VirtualHost *:80>
ServerAdmin webmaster@***.com
ProxyPass /fileupload.html balancer://rescluster/fileupload lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3
ProxyPass /otherupload.html balancer://rescluster/otherupload.html lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3
#<!--负载均衡-->
<Proxy balancer://rescluster/>
BalancerMember ajp://res1.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat1
BalancerMember ajp://res2.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat2
</Proxy>
< /VirtualHost>步骤三，修改业务逻辑：
所有上传文件在数据库中均采用全url的方式保存，例如产品图片路径存成：http://res1.***.com/upload/20090101/product120302005.jpg
现在，你可以高枕无忧了，带宽不够时，增加个几十台图片服务器，只需要稍微修改一下apache的配置文件，即可。
五：高并发高负载网站的系统架构之数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并 且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者 功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的 架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系 统随时增加一台低成本的数据库进来补充系统性能。
集群软件的分类：
一般来讲，集群软件根据侧重的方向和试图解决的问题，分为三大类：高性能集群（High performance cluster，HPC）、负载均衡集群（Load balance cluster， LBC），高可用性集群（High availability cluster，HAC）。
高性能集群（High performance cluster，HPC），它是利用一个集群中的多台机器共同完成同一件任务，使得完成任务的速度和可靠性都远远高于单机运行的效果。弥补了单机性能上的不足。该集群在天气预报、环境监控等数据量大，计算复杂的环境中应用比较多；
负载均衡集群（Load balance cluster， LBC），它是利用一个集群中的多台单机，完成许多并行的小的工作。一般情况下，如果一个应用使用的人多了，那么用户请求的响应时间就会增大，机器的性能也会受到影响，如果使用负载均衡集群，那么集群中任意一台机器都能响应用户的请求，这样集群就会在用户发出服务请求之后，选择当时负载最小，能够提供最好的服务的这台机器来接受请求并相应，这样就可用用集群来增加系统的可用性和稳定性。这类集群在网站中使用较多；
高可用性集群（High availability cluster，HAC），它是利用集群中系统 的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务，等待故障机的维修和返回。最大限度的保证集群中服务的可用性。这类系统一般在银行，电信服务这类对系统可靠性有高的要求的领域有着广泛的应用。
2 数据库集群的现状
数据库集群是将计算机集群技术引入到数据库中来实现的，尽管各厂商宣称自己的架构如何的完美，但是始终不能改变Oracle当先，大家追逐的事实，在集群的解决方案上Oracle RAC还是领先于包括微软在内的其它数据库厂商，它能满足客户高可用性、高性能、数据库负载均衡和方便扩展的需求。
Oracle’s Real Application Cluster (RAC) Microsoft SQL Cluster Server (MSCS) IBM’s DB2 UDB High Availability Cluster(UDB) Sybase ASE High Availability Cluster (ASE) MySQL High Availability Cluster (MySQL CS)
基于IO的第三方HA(高可用性)集群
当前主要的数据库集群技术有以上六大类，有数据库厂商自己开发的；也有第三方的集群公司开发的；还有数据库厂商与第三方集群公司合作开发的，各类集群实现的功能及架构也不尽相同。
RAC（Real Application Cluster，真正应用集群）是Oracle9i数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。在很长一段时间里，甲骨文都以其实时应用集群技术(Real Application Cluster，RAC)统治着集群数据库市场
六：高并发高负载网站的系统架构之缓存
기술자라면 누구나 캐시라는 단어를 접하게 되었고, 캐시는 여러 곳에서 사용됩니다. 웹 사이트 아키텍처 및 웹 사이트 개발에서 캐싱도 매우 중요합니다. 여기서는 먼저 가장 기본적인 두 가지 캐시에 대해 이야기합니다. 고급 및 분산 캐싱에 대해서는 나중에 설명합니다.
아키텍처 캐싱과 관련하여 Apache에 익숙한 사람이라면 Apache가 자체 캐싱 모듈을 제공하거나 캐싱을 위해 추가 Squid 모듈을 사용할 수 있다는 것을 알 것입니다. 두 방법 모두 Apache의 액세스 응답 기능을 효과적으로 향상시킬 수 있습니다.
웹사이트 프로그램 개발 시 캐시, 리눅스에서 제공하는 메모리 캐시는 흔히 사용되는 캐시 인터페이스로, 예를 들어 자바로 개발할 때 메모리 캐시를 호출해 일부 데이터를 캐시하고 통신할 수 있다. 일부 대규모 커뮤니티에서 사용되는 구조입니다. 또한 웹 언어 개발을 사용할 때 각 언어에는 기본적으로 자체 캐시 모듈과 메서드가 있습니다. PHP에는 Pear의 캐시 모듈이 있고 Java에는 훨씬 더 많은 .net이 있지만 분명히 있을 것이라고 생각합니다.
Java 오픈 소스 캐싱 프레임워크
JBossCache/TreeCache JBossCache 는 엔터프라이즈 수준 애플리케이션 데이터를 캐시하여 성능을 향상시킬 수 있는 복제된 트랜잭션 캐시입니다. 캐시 데이터가 자동으로 복제되므로 Jboss 서버 간 클러스터 작업을 쉽게 수행할 수 있습니다. JBossCache는 Jboss Application Service 또는 기타 J2EE 컨테이너를 통해 MBean 서비스를 실행할 수 있습니다. 물론 독립적으로 실행할 수도 있습니다. JBossCache에는 TreeCache와 TreeCacheAOP라는 두 가지 모듈이 포함되어 있습니다. TreeCache - 트리 구조의 복제된 트랜잭션 캐시입니다. TreeCacheAOP -- AOP를 사용하여 POJO를 동적으로 관리하는 "객체 지향" 캐시입니다.
OSCache OSCache 태그 라이브러리는 기존 JSP 페이지를 사용할 수 있는 기능을 제공하는 획기적인 JSP 사용자 정의 태그 애플리케이션인 OpenSymphony에 의해 설계되었습니다. 내부에서 빠른 메모리 버퍼링 기능을 구현합니다. OSCache는 널리 채택된 고성능 J2EE 캐싱 프레임워크로 모든 Java 애플리케이션에 대한 공통 캐싱 솔루션으로 사용할 수 있습니다. OSCache에는 다음과 같은 특징이 있습니다. 모든 개체를 캐시하고, JSP 페이지 또는 HTTP 요청의 일부를 제한 없이 캐시할 수 있으며, 모든 Java 개체를 캐시할 수 있습니다. 포괄적인 API 보유 - OSCache API는 모든 OSCache 기능을 제어할 수 있는 포괄적인 프로그램을 제공합니다. 영구 캐시 - 캐시는 마음대로 디스크에 기록될 수 있으므로 애플리케이션을 다시 시작해도 생성 비용이 많이 드는 데이터를 캐시된 상태로 유지할 수 있습니다. 클러스터링 지원 - 코드 수정 없이 클러스터 캐시 데이터를 개별적으로 구성할 수 있습니다. 캐시 레코드 만료 - 플러그형 새로 고침 전략(기본 성능에 필요하지 않은 경우)을 포함하여 캐시된 개체의 만료를 최대한 제어할 수 있습니다.
JCACHE JCACHE는 객체 생성, 공유 액세스, 스풀링, 무효화, 각 JVM의 일관성 등을 포함하여 Java 객체를 메모리에 일시적으로 캐싱하는 방법을 설명하는 곧 출시될 표준 사양(JSR 107)입니다. 제품 카탈로그 및 가격 목록과 같이 JSP 내에서 가장 자주 읽는 데이터를 캐시하는 데 사용할 수 있습니다. JCACHE를 사용하면 캐시된 데이터를 통해 대부분의 쿼리에 대한 응답 시간이 가속화됩니다(내부 테스트에 따르면 응답 시간은 약 15배 더 빠릅니다).
Ehcache Ehcache는 Hibernate에서 왔으며 Hibernate에서 데이터 캐싱 솔루션으로 사용됩니다.
Java 캐싱 시스템 JCS는 자카르타 프로젝트 Turbine의 하위 프로젝트입니다. 복합 버퍼 도구입니다. 개체는 메모리와 하드 디스크에 버퍼링될 수 있습니다. 버퍼 개체 시간 만료 설정이 있습니다. 또한 JCS를 통한 버퍼링을 통해 분산 아키텍처를 구축하여 고성능 애플리케이션을 구현할 수도 있습니다. 자주 액세스해야 하고 액세스할 때마다 많은 리소스를 소비해야 하는 일부 객체의 경우 임시로 버퍼에 저장하여 서비스 성능을 향상시킬 수 있습니다. 그리고 JCS는 좋은 버퍼링 도구입니다. 버퍼링 도구는 쓰기 작업보다 읽기 작업이 훨씬 더 많은 애플리케이션의 성능을 크게 향상시킬 수 있습니다.
SwarmCache SwarmCache는 간단하면서도 강력한 분산 캐싱 메커니즘입니다. 캐시된 인스턴스 간에 효율적으로 통신하기 위해 IP 멀티캐스트를 사용합니다. 클러스터된 웹 애플리케이션의 성능을 빠르게 향상시키는 데 이상적입니다.
ShiftOne ShiftOne 개체 캐시이 Java 라이브러리는 기본 개체 캐싱 기능을 제공합니다. 구현된 전략은 선입선출(FIFO), 최근 사용(LRU), 최소 빈도 사용(LFU)입니다. 모든 전략은 요소의 크기를 최대화하고 생존 시간을 최대화합니다.
WhirlyCache Whirlycache는 메모리에 존재하는 객체에 대한 빠르고 구성 가능한 캐시입니다. 데이터베이스나 기타 비용이 많이 드는 프로세스를 쿼리하여 구축해야 하는 개체를 캐싱하여 웹 사이트나 애플리케이션의 속도를 높일 수 있습니다.
Jofti Jofti는 캐시 계층(EHCache, JBossCache 및 OSCache 지원) 또는 맵 인터페이스를 지원하는 스토리지 구조에서 객체를 색인화하고 검색할 수 있습니다. 프레임워크는 또한 인덱스의 개체 추가, 삭제 및 수정에 대한 투명성과 사용하기 쉬운 검색 쿼리 기능을 제공합니다.
cache4j 캐시4j는 간단한 API와 빠른 구현을 갖춘 Java 객체 캐시입니다. 그 기능은 다음과 같습니다: 멀티 스레드 환경을 위해 설계된 메모리 캐싱, 두 가지 구현: 동기화 및 차단, 다중 캐시 지우기 전략: LFU, LRU, FIFO, 강력한 참조(강한 참조) 및 소프트 참조(소프트 참조) 저장소 사용 물체.
Open Terracotta HTTP 세션 복제, 분산 캐싱, POJO 클러스터링 및 JVM을 제공하는 JVM 수준 오픈 소스 클러스터링 프레임워크로 분산 애플리케이션 조정을 달성하기 위해(코드 주입을 사용하므로 어떤 수정도 필요하지 않음) ).
sccache SHOP.COM에서 사용하는 객체 캐싱 시스템입니다. sccache는 프로세스 내 캐시이자 두 번째 수준의 공유 캐시입니다. 캐시된 개체를 디스크에 저장합니다. 관련 키, 모든 크기의 키, 모든 크기의 데이터를 지원합니다. 자동으로 가비지 수집을 수행하는 기능.
Shoal Shoal은 내결함성이 있고 안정적이며 사용 가능한 Java 애플리케이션을 구축하기 위한 인프라 지원을 제공하는 Java 기반의 확장 가능한 동적 클러스터링 프레임워크입니다. 이 프레임워크는 특정 통신 프로토콜에 연결되기를 원하지 않지만 클러스터 및 분산 시스템 지원이 필요한 모든 Java 제품에 통합될 수도 있습니다. Shoal은 GlassFish 및 JonAS 애플리케이션 서버용 클러스터링 엔진입니다.
Simple-Spring-Memcached Simple-Spring-Memcached는 MemCached에 대한 호출을 캡슐화하여 MemCached 클라이언트 개발을 매우 간단하게 만듭니다.
위 내용은 Java의 높은 동시성 솔루션 및 고부하 최적화의 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!