Решение с высокой степенью параллелизма для системы Java

Java задняя часть
Решение с высокой степенью параллелизма для системы Java

Небольшой веб-сайт, такой как личный веб-сайт, может быть реализован с использованием простейшей статической страницы html, с некоторыми изображениями для достижения эффекта украшения, все страницы хранятся в каталоге, такой веб-сайт предъявляет очень высокие требования к системной архитектуре и производительности. , с непрерывным обогащением интернет-услуг, технологии, связанные с веб-сайтами, были подразделены на очень тонкие аспекты после многих лет разработки.Особенно для крупных веб-сайтов используются очень обширные технологии, начиная от аппаратного обеспечения до программного обеспечения, языков программирования, баз данных, веб-сервера, брандмауэры и другие поля имеют высокие требования, которые не сравнимы с исходным простым статическим веб-сайтом html.

Крупные веб-сайты, такие как порталы. Перед лицом большого количества обращений пользователей и большого количества одновременных запросов базовые решения сосредоточены на следующих связях: использование высокопроизводительных серверов, высокопроизводительных баз данных, высокоэффективных языков программирования и высокопроизводительных веб-контейнеров. Но помимо этих аспектов не существует фундаментального решения проблем высокой нагрузки и параллелизма, с которыми сталкиваются крупные веб-сайты.

Несколько решений, представленных выше, также в определенной степени требуют больших инвестиций, и такие решения имеют узкие места и не обладают хорошей масштабируемостью.Позвольте мне рассказать об этом с точки зрения низкой стоимости, высокой производительности и высокой масштабируемости.Расскажите мне о некоторых из моих опыт.

1. Статический HTML

На самом деле, мы все знаем, что чистые статические html-страницы являются наиболее эффективными и наименее затратными, поэтому мы стараемся использовать статические страницы для реализации страниц на нашем веб-сайте.Этот самый простой метод на самом деле является наиболее эффективным методом. Однако для веб-сайтов с большим объемом контента и частыми обновлениями мы не можем вручную внедрить их все по одному, поэтому появляется наша общая система публикации информации CMS, например новостные каналы различных сайтов-порталов, которые мы часто посещаем, и даже их другие каналы. Он управляется и реализуется системой выпуска информации. Система выпуска информации может реализовать простейший ввод информации и автоматически генерировать статические страницы. Она также может иметь такие функции, как управление каналами, управление полномочиями и автоматическое сканирование. Для большого веб-сайт, он имеет набор эффективных, управляемая CMS имеет важное значение.

В дополнение к порталам и информационно-публикационным типам веб-сайтов, для веб-сайтов типа сообщества с высокими требованиями к интерактивности как можно более статичные также являются необходимым средством повышения производительности.Посты и статьи в сообществе делаются статическими в режиме реального времени, и Рестатизация также является стратегией, которая иногда широко используется.Сборная солянка Mop использует такую ​​стратегию, как и сообщество NetEase.

В то же время html-статизация также является средством, используемым некоторыми стратегиями кэширования.Для приложений, которые часто используют запросы к базе данных в системе, но обновление контента невелико, вы можете рассмотреть возможность использования html-статизации для достижения этого, например, общедоступной информации о настройках. форума в форуме.Эта информация в настоящее время Все основные форумы могут управляться в фоновом режиме и храниться в базе данных.На самом деле большая часть этой информации вызывается программой переднего плана,но частота обновления очень мала.Вы можно рассмотреть возможность сделать эту часть контента статической, когда она обновляется в фоновом режиме, чтобы избежать большого количества запросов на доступ к базам данных.

2. Разделение серверов изображений

Как мы все знаем, для веб-серверов, будь то Apache, IIS или другие контейнеры, изображения являются наиболее ресурсоемкими, поэтому нам необходимо отделить изображения от страниц.Это в основном стратегия, которую будут использовать крупные веб-сайты. серверы изображений или даже несколько серверов изображений. Такая архитектура может снизить нагрузку на серверную систему, которая предоставляет запросы на доступ к странице, и может гарантировать, что система не выйдет из строя из-за проблем с изображением.На сервере приложений и сервере изображений могут выполняться различные оптимизации конфигурации.Например, apache Можно попытаться максимально настроить ContentType. Меньше поддержки и как можно меньше LoadModules обеспечивают более высокое потребление системы и эффективность выполнения.

3. Кластеризация базы данных и хеширование таблиц базы данных

Большие веб-сайты имеют сложные приложения, и эти приложения должны использовать базы данных.При большом количестве доступов скоро появится узкое место в базе данных.В это время база данных скоро не сможет удовлетворить приложение, поэтому нам необходимо используйте хэш таблицы кластера базы данных или библиотеки.

С точки зрения кластеризации баз данных, многие базы данных имеют свои собственные решения.Хорошие решения есть у Oracle, Sybase и т. д. Широко используемое ведущее/ведомое устройство, предоставляемое MySQL, также является аналогичным решением.Какую БД вы используете, пожалуйста, обратитесь к соответствующему решение, решение для реализации.

Кластер базы данных, упомянутый выше, ограничен типом используемой БД с точки зрения архитектуры, стоимости и масштабируемости, поэтому нам необходимо рассмотреть возможность улучшения архитектуры системы с точки зрения приложения.Хеширование библиотечных таблиц является наиболее часто используемым и наиболее эффективное решение. . Мы устанавливаем бизнес- и прикладные или функциональные модули в приложении, чтобы разделить базу данных, разные модули соответствуют разным базам данных или таблицам, а затем выполняем меньший хеш базы данных для страницы или функции в соответствии с определенной стратегией, такой как пользовательская таблица, хеширование таблицы в соответствии с идентификатором пользователя, что позволяет повысить производительность системы при небольших затратах и ​​имеет хорошую масштабируемость. Форум Sohu принимает такую ​​структуру, которая отделяет пользователей форума, настройки, сообщения и другую информацию от базы данных, а затем хеширует базу данных и таблицы для сообщений и пользователей в соответствии с разделом и идентификатором, и, наконец, может быть просто настроен в конфигурации. Недорогая база данных может быть добавлена ​​в систему в любое время для повышения производительности системы.

4. Кэш

Термин кеш был затронут технологией, и кеш используется во многих местах. Кэширование в архитектуре веб-сайтов и разработке веб-сайтов также очень важно. Вот самые основные два типа кешей. Расширенное и распределенное кэширование описано ниже. Что касается кэширования с точки зрения архитектуры, те, кто знаком с Apache, могут знать, что Apache предоставляет свой собственный модуль кэширования, а также может использовать дополнительный модуль Squid для кэширования, оба из которых могут эффективно улучшить возможности ответа на доступ Apache. Для кэширования разработки программ веб-сайта Memory Cache, предоставляемый в Linux, является широко используемым интерфейсом кэширования, который можно использовать в веб-разработке.Например, при разработке на Java вы можете вызвать MemoryCache для кэширования и совместного использования некоторых данных.Некоторые большие сообщества используют такую ​​структуру. Кроме того, при разработке веб-языков различные языки в основном имеют свои собственные модули и методы кэширования, в PHP есть модуль кэширования Pear, в Java их больше, а .net не очень знаком, я считаю, что они должны быть.

5. Зеркало

Зеркалирование — это метод, который часто используется крупными веб-сайтами для повышения производительности и безопасности данных.Технология зеркалирования может устранить разницу в скорости доступа пользователей, вызванную разными поставщиками сетевого доступа и регионами.Например, разница между ChinaNet и EduNet побудила многие веб-сайты В образовательной сети встроен зеркальный сайт, и данные обновляются регулярно или в режиме реального времени. Что касается подробной технологии зеркалирования, я не буду здесь слишком подробно останавливаться, есть много профессиональных готовых архитектур решений и продуктов на выбор. Есть также дешевые идеи реализации программного обеспечения, такие как такие инструменты, как rsync в Linux.

6. Балансировка нагрузки

Балансировка нагрузки станет оптимальным решением для крупных веб-сайтов, позволяющим решить проблему доступа с высокой нагрузкой и большого количества одновременных запросов.

Технология балансировки нагрузки разрабатывалась в течение многих лет, и есть много профессиональных поставщиков услуг и продуктов на выбор.Я лично сталкивался с некоторыми решениями, и есть две архитектуры для вашего ознакомления.

1) Аппаратная четырехуровневая коммутация

Коммутация уровня 4 использует информацию заголовков пакетов уровней 3 и 4 для идентификации потоков услуг в соответствии с интервалом приложения и распределяет поток обслуживания всего сегмента интервала на соответствующий сервер приложений для обработки. Функция переключения четвертого уровня похожа на виртуальный IP-адрес, указывающий на физический сервер. Бизнес, который он передает, подчиняется множеству протоколов, включая HTTP, FTP, NFS, Telnet или другие протоколы. Эти сервисы основаны на физических серверах и требуют сложных алгоритмов балансировки нагрузки. В мире IP тип службы определяется адресом TCP- или UDP-порта терминала, а диапазон приложений при коммутации уровня 4 определяется IP-адресами источника и терминала, TCP- и UDP-портами.

В области аппаратных продуктов для четырехуровневой коммутации есть несколько хорошо известных продуктов, таких как Alteon, F5 и т. д. Эти продукты дороги, но имеют хорошее соотношение цены и качества и могут обеспечить отличную производительность и гибкие возможности управления. Yahoo China использовала три или четыре Alteon для своих почти 2000 серверов.

2) Четырехуровневая программная коммутация

После того, как всем известен принцип работы аппаратного коммутатора уровня 4, на свет появляется программный коммутатор уровня 4, основанный на модели OSI, принцип такого решения тот же, но производительность немного хуже. Тем не менее, выдержать определенное давление по-прежнему легко.Некоторые люди говорят, что метод реализации программного обеспечения на самом деле более гибкий, а вычислительная мощность полностью зависит от знакомства с вашей конфигурацией.

Мы можем использовать LVS, обычно используемый в Linux, для решения проблемы четырехуровневого переключения программного обеспечения.LVS — это виртуальный сервер Linux.Он предоставляет решение для реагирования на бедствия в режиме реального времени на основе сердцебиения, которое повышает надежность системы и предоставляет гибкие виртуальные виртуальные IP-адреса. функции настройки и управления могут одновременно удовлетворять потребности нескольких приложений, что очень важно для распределенных систем.

Типичной стратегией использования балансировки нагрузки является построение кластера squid на основе программной или аппаратной четырехуровневой коммутации.Эта идея используется во многих крупных веб-сайтах, в том числе в поисковых системах.Эта архитектура отличается низкой стоимостью, высокой производительностью и надежностью. Очень легко добавлять или удалять узлы в архитектуре в любое время. Я собираюсь потратить некоторое время, чтобы подробно разобраться в такой структуре и обсудить ее с вами.

1: База данных, представляющая интерес для веб-сайтов с высокой степенью параллелизма и высокой нагрузкой.

Правильно, первая — это база данных, которая является первой SPOF, с которой сталкивается большинство приложений. Особенно в приложении Web2.0 ответ базы данных — это первое, что нужно решить. Вообще говоря, чаще всего используется MySQL, и поначалу это может быть хост MySQL.Когда данные увеличиваются до более чем 1 миллиона, производительность MySQL резко падает. Обычно используемой мерой оптимизации является режим M-S (ведущий-ведомый) для синхронной репликации, когда запросы и операции выполняются на разных серверах. Что я рекомендую, так это метод M-M-Slaves с 2 мастерами Mysql и несколькими рабами.Следует отметить, что хотя мастеров 2, только 1 активен одновременно, и мы можем переключаться в определенное время. Причина использования 2 M состоит в том, чтобы гарантировать, что M больше не станет SPOF системы. Ведомые устройства могут быть дополнительно сбалансированы по нагрузке и могут быть объединены с LVS для правильной балансировки операций выбора для различных ведомых устройств. Вышеупомянутая архитектура может выдерживать определенную нагрузку, но по мере дальнейшего увеличения числа пользователей данные вашей пользовательской таблицы превышают 10 миллионов, и тогда M становится SPOF. Нельзя расширять Slaves произвольно, иначе резко возрастут накладные расходы на репликацию и синхронизацию.Что делать? Мой подход — разбиение таблиц, разбиение на бизнес-уровень. Самое простое, взять пользовательские данные в качестве примера. Согласно определенному методу сегментации, например id, он делится на разные кластеры базы данных.

Глобальная база данных используется для запросов метаданных. Недостатком является то, что каждый запрос будет увеличиваться один раз, например, если вы хотите проверить пользователя nightsailer, вы должны сначала перейти в группу глобальной базы данных, чтобы найти идентификатор кластера, соответствующий nightsailer, а затем перейти к указанному кластеру, чтобы найти фактические данные nightsailer. Каждый кластер может использовать режим m-m или режим m-m-slaves. Это масштабируемая структура, по мере увеличения нагрузки в нее можно просто добавлять новые кластеры mysql.

Следует отметить, что: 1. Отключите все поля auto_increment 2. Идентификатор должен быть выделен централизованно с использованием общего алгоритма 3. Необходимо иметь лучший метод для мониторинга загрузки хоста mysql и рабочего состояния сервис. Если у вас запущено более 30 баз данных mysql, вы поймете, что я имею в виду. 4. Не используйте постоянные ссылки (не используйте pconnect), вместо этого используйте пул ссылок сторонней базы данных, такой как sqlrelay, или просто сделайте это самостоятельно, потому что пул ссылок mysql в php4 часто имеет проблемы.Второе: Статизация HTML системной архитектуры веб-сайтов с высоким параллелизмом и высокой нагрузкой

На самом деле, все мы знаем, что наиболее эффективным и наименее потребляемым является чистыйСтатический woohoo.ablanche.com/ — это HTML/20120…HTML страницы, поэтому мы делаем все возможное, чтобы реализовать страницу на нашем сайте, это самый простой способ на самом деле является наиболее эффективным способом. Но для большого количества контента и часто обновляемых веб-сайтов, мы не можем вручную перейти к реализации, поэтому мы имеем общую систему информации релиз CMS, как все части мы часто посещаем. Канал новостей, и даже другие каналы управляются и реализуются через систему распределения информации. Система распределения информации может достигнуть простейшей информацию для автоматического создания статической страницы, но и канал управления, управления разрешений, автоматический захват и т.д. Функции, для большой веб-сайт, имеет эффективные и управляемые CMS. В дополнение к типу портала и информации типа публикации, для веб - сайта типа сообщества с высокими интерактивными требованиями, как статические также необходимые средства улучшения производительности, а также посты в сообществе, статья является статическим, и обновляется он также staticization большого количества статических историй, чтобы повторно статика, как hordeli использование швабры в таких стратегиях, NetEase сообществ и т.д. В то же время, HTML staticization также средство определенных стратегий кэширования. Для приложений, где запросы к базе данных часто используются в системе, обновление контента мало, можно рассмотреть возможность использования HTML staticization, такие как информация о государственном учреждении форума в форум, эта информация в настоящее время является основным форумом можно управлять в управлении фоном и магазин репутации, которая фактически называется передней программой, но частота обновления мала, можно рассмотреть статический , когда эта часть фона обновляется, что позволяет избежать много запросов доступа к базе данных высоки.

Статическое HTML-решение веб-сайта Когда запрос ресурса сервлета поступает на веб-сервер, мы заполняем указанную страницу JSP, чтобы ответить на запрос:

HTTP-запрос --- веб-сервер --- сервлет -- обработка бизнес-логики -- доступ к данным -- заполнение JSP -- ответ на запрос

После статического HTML:

HTTP-запрос --- веб-сервер --- сервлет -- HTML -- запрос ответа

Статический доступ выглядит следующим образом

Servlet:

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);//发送指定文件流到客户端   
    }  
} 

Третье: кэширование, балансировка нагрузки и хранение проблем с высоким параллелизмом и высокой нагрузкой веб-сайтов.

Кэширование — еще одна большая проблема.Я обычно использую memcached в качестве кэш-кластера.Вообще говоря, развертывание около 10 единиц примерно одинаково (пул памяти 10g). Следует отметить, что вы не должны использовать своп, лучше всего закрыть своп Linux.

Балансировка/ускорение нагрузки Может быть, когда дело доходит до кэширования, первое, о чем думают некоторые люди, это сделать страницу статической.Так называемый статический html, я думаю, что это здравый смысл, а не точка. Статизация страницы обеспечивает балансировку нагрузки и ускорение статического сервиса. Я думаю, что Lighttped+Squid — лучший способ. LVS lighttped====>squid(s) ====lighttped

Выше это то, что я часто использую. Обратите внимание, что я не использую apache.Если нет особых требований, я не развертываю apache, потому что я обычно использую php-fastcgi с lighttpd, и производительность намного выше, чем у apache+mod_php.

Использование squid может решить такие проблемы, как синхронизация файлов и т.д., но следует отметить, что нужно хорошо следить за частотой попадания в кэш и максимально увеличивать ее более чем на 90%. У Squid и lighttped тоже есть много тем для обсуждения, поэтому я не буду их здесь повторять.

Хранилище Хранение также является большой проблемой, одна из них — хранение небольших файлов, таких как изображения. Другой — это хранение больших файлов, таких как индекс поисковых систем.Как правило, размер одного файла превышает 2 г. Самый простой способ хранить небольшие файлы — использовать для распространения lighttpd. Или просто используйте GFS Redhat, преимущество в том, что приложение прозрачно, а недостаток в том, что стоимость выше. Я имею в виду ваш вопрос о покупке дискового массива. В моем проекте емкость хранилища составляет 2-10Тб, и я использую распределенное хранилище. Дублирование файлов и избыточность рассматриваются здесь. Таким образом, каждый файл имеет разную избыточность, в этом отношении вы можете обратиться к документу Google gfs. Для хранения больших файлов вы можете обратиться к решению nutch, которое теперь является независимым подпроектом Hadoop. (можно погуглить Это)

Другое: Кроме того, паспортные и т. д. также рассматриваются, но они относительно просты.Четвертое: разделение серверов изображений в системной архитектуре веб-сайтов с высокой степенью параллелизма и высокой нагрузкойКак мы все знаем, для веб-серверов, будь то Apache, IIS или другие контейнеры, изображения являются наиболее ресурсоемкими, поэтому необходимо отделять изображения от страниц.Это в основном стратегия, которую примут крупные веб-сайты. иметь независимые серверы изображений или даже несколько серверов изображений. Такая архитектура может снизить нагрузку на серверную систему, которая предоставляет запросы на доступ к странице, и может гарантировать, что система не выйдет из строя из-за проблем с изображением.На сервере приложений и сервере изображений могут выполняться различные оптимизации конфигурации.Например, apache можно попытаться максимально настроить ContentType.меньше поддержки, как можно меньше LoadModule, Обеспечьте более высокое потребление системы и эффективность выполнения.

Используйте Apache для разделения серверов образов. Причина: приложения на начальном этапе могут быть развернуты на одном сервере (по соображениям экономии). В первую очередь необходимо разделить базу данных и сервер приложений. Какой будет вторая разлука? У каждого свои соображения.Моя проектная группа сосредоточена на экономии пропускной способности.Независимо от того, насколько хороша производительность сервера, независимо от того, насколько высока пропускная способность, ее легко не поддерживать. Поэтому в центре внимания моей статьи находится здесь. Основное внимание здесь уделяется внедрению практики, которая может не соответствовать всем ситуациям, для справки зрителей Введение в среду: Сервер веб-приложений: 4 процессора, двухъядерный 2G, память 4G Развертывание: Win2003/Apache Http Server 2.1/Tomcat6 Сервер базы данных: 4-ядерный процессор 2G, память 4G. Развертывание: Win2003/MSSQL2000. сервер ресурсов Развертывание: Tomcat6 , запустил простое приложение для загрузки изображений (не забудьте указать из web.xml) и укажите доменное имя как res1.***.com, res2.***.com , используя протокол ajp Шаг 2. Измените конфигурацию Apache httpd.conf Исходный URL-адрес функции загрузки файла приложения: 1. /fileupload.html 2. /otherupload.html Добавьте следующую конфигурацию в httpd.conf

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 BalancerMember ajp://res1.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat1 BalancerMember ajp://res2.** *.ком:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat2 Шаг 3, измените бизнес-логику: все загруженные файлы сохраняются в базе данных с полными URL-адресами, такими как изображения продуктов Путь сохраняется как: http://res1.***.com/upload/20090101/product120302005.jpg

Теперь можно сесть и расслабиться, когда пропускной способности не хватает, можно добавить десятки серверов изображений, и нужно лишь немного изменить конфигурационный файл apache.

Пять: кластер базы данных и хеширование таблиц базы данных системной архитектуры высококонкурентных и высоконагруженных веб-сайтов.

Большие веб-сайты имеют сложные приложения, и эти приложения должны использовать базы данных.При большом количестве доступов скоро появится узкое место в базе данных.В это время база данных скоро не сможет удовлетворить приложение, поэтому нам необходимо используйте хэш таблицы кластера базы данных или библиотеки. С точки зрения кластеризации баз данных, многие базы данных имеют свои собственные решения.Хорошие решения есть у Oracle, Sybase и т. д. Широко используемое ведущее/ведомое устройство, предоставляемое MySQL, также является аналогичным решением.Какую БД вы используете, пожалуйста, обратитесь к соответствующему решение, решение для реализации. Кластер базы данных, упомянутый выше, ограничен типом используемой БД с точки зрения архитектуры, стоимости и масштабируемости, поэтому нам необходимо рассмотреть возможность улучшения архитектуры системы с точки зрения приложения. и самое эффективное решение. Мы устанавливаем бизнес- и прикладные или функциональные модули в приложении, чтобы разделить базу данных, разные модули соответствуют разным базам данных или таблицам, а затем выполняем меньший хеш базы данных для страницы или функции в соответствии с определенной стратегией, такой как пользовательская таблица, хеширование таблицы в соответствии с идентификатором пользователя, что позволяет повысить производительность системы при небольших затратах и ​​имеет хорошую масштабируемость. Форум Sohu принимает такую ​​структуру, которая отделяет пользователей форума, настройки, сообщения и другую информацию от базы данных, а затем хеширует базу данных и таблицы для сообщений и пользователей в соответствии с разделом и идентификатором, и, наконец, может быть просто настроен в конфигурации. Недорогая база данных может быть добавлена ​​в систему в любое время для повышения производительности системы.

Классификация кластерного программного обеспечения. Вообще говоря, кластерное программное обеспечение делится на три категории в зависимости от направления деятельности и проблемы, которую оно пытается решить: высокопроизводительный кластер (HPC), кластер с балансировкой нагрузки (LBC), кластер высокой доступности (High Availability). кластер, ВАК). Высокопроизводительный кластер (HPC), который использует несколько машин в кластере для совместного выполнения одной и той же задачи, так что скорость и надежность задачи намного выше, чем эффект от работы одной машины. Компенсируйте отсутствие автономной работы. Кластер широко используется в средах с большими объемами данных, таких как прогноз погоды и мониторинг окружающей среды, а также сложные расчеты; Кластер балансировки нагрузки (LBC), который использует несколько отдельных компьютеров в кластере для выполнения множества параллельных небольших заданий. В обычных условиях, если больше людей используют приложение, время ответа на запросы пользователей будет увеличиваться, а также будет затронута производительность машины.Если используется кластер балансировки нагрузки, любая машина в кластере может ответить на запрос пользователя. , Таким образом, после того, как пользователь отправит запрос на обслуживание, кластер выберет компьютер с наименьшей нагрузкой в ​​это время и сможет предоставить лучший сервис для принятия запроса и соответствующего ответа, так что кластер можно использовать для увеличения доступность и стабильность системы. Этот тип кластера больше используется на веб-сайтах Кластер высокой доступности (кластер высокой доступности) кластер, HAC), он использует избыточность системы в кластере.Когда машина в системе повреждена, другие резервные машины могут быстро взять ее на себя, чтобы запустить службу, ожидая ремонта и возврата неисправной машины. Максимально увеличить доступность сервисов в кластере. Такие системы, как правило, широко используются в банковской сфере, телекоммуникационных услугах и других сферах, предъявляющих повышенные требования к надежности системы. 2 Текущее состояние кластеризации баз данных Кластеризация баз данных реализуется за счет внедрения в базу данных технологии кластеризации компьютеров.Хотя разные производители заявляют о совершенстве своих архитектур, они не могут изменить того факта, что Oracle является первым, за которым все гонятся.Что касается кластерных решений, Oracle RAC также опережает других поставщиков баз данных, включая Microsoft, и может удовлетворить потребности клиентов в высокой доступности, высокой производительности, балансировке нагрузки базы данных и легком расширении. Oracle Real Application Cluster (RAC) Microsoft SQL Cluster Server (MSCS) IBM DB2 UDB High Availability Cluster (UDB) Sybase ASE High Availability Cluster (ASE) MySQL High Availability Cluster (MySQL CS) Сторонняя система высокой доступности на основе ввода-вывода (High Availability) кластер В настоящее время основные технологии кластеризации баз данных включают шесть вышеуказанных категорий, которые разрабатываются самими производителями баз данных, некоторые из них разрабатываются сторонними кластерными компаниями, а некоторые разрабатываются производителями баз данных в сотрудничестве со сторонними кластерными компаниями. функции и архитектуры, реализованные различными кластерами, тоже не совсем точны. RAC (Real Application Cluster, настоящий кластер приложений) — это новая технология, принятая в базе данных Oracle9i, а также основная технология базы данных Oracle, поддерживающая среду распределенных вычислений. Его появление решает важную проблему, стоящую перед традиционными приложениями баз данных: противоречие между высокой производительностью, высокой масштабируемостью и низкой ценой. Долгое время Oracle доминировала на рынке кластерных баз данных благодаря своей технологии Real Application Cluster (RAC).

Шестое: Кэш системной архитектуры веб-сайтов с высокой параллельной работой и высокой нагрузкой.

Термин кеш был затронут технологией, и кеш используется во многих местах. Кэширование в архитектуре веб-сайтов и разработке веб-сайтов также очень важно. Вот самые основные два типа кешей. Расширенное и распределенное кэширование описано ниже. Что касается кэша с точки зрения архитектуры, те, кто знаком с Apache, могут знать, что Apache предоставляет свой собственный модуль кэширования, а также может использовать дополнительный модуль Squid для кэширования, оба из которых могут эффективно улучшить возможности ответа на доступ Apache. Для кэширования разработки программ веб-сайта Memory Cache, предоставляемый в Linux, является широко используемым интерфейсом кэширования, который можно использовать в веб-разработке.Например, при разработке на Java вы можете вызвать MemoryCache для кэширования и совместного использования некоторых данных. сообщества типов используют такую ​​структуру. Кроме того, при разработке веб-языков различные языки в основном имеют свои собственные модули и методы кэширования, в PHP есть модуль Pear's Cache, в Java их больше, а .net не очень знаком, я считаю, что они должны быть.

Java Open Source Cache Framework JBossCache/TreeCache JBossCache — это реплицированный транзакционный кэш, который позволяет кэшировать данные корпоративных приложений для повышения производительности. Данные кэша автоматически реплицируются, что позволяет легко кластеризовать работу между серверами Jboss. JBossCache может запускать службу MBean через Jboss Application Services или другие контейнеры J2EE и, конечно же, может работать независимо. JBossCache включает в себя два модуля: TreeCache и TreeCacheAOP. TreeCache — это реплицированный транзакционный кэш с древовидной структурой. TreeCacheAOP -- это "объектно-ориентированный" кеш, который использует AOP для динамического управления POJO. OSCache Библиотека тегов OSCache, разработанная OpenSymphony. Это новаторское приложение пользовательских тегов JSP, которое обеспечивает быстрое кэширование в памяти в рамках существующей функции страниц JSP. OSCache — это широко используемая высокопроизводительная среда кэширования J2EE, которую можно использовать как обычное решение кэширования для любого Java-приложения. OSCache имеет следующие функции: Кэшировать любой объект, вы можете неограниченно кэшировать часть jsp-страниц или HTTP-запросов, любой java-объект может быть кэширован. Имеет комплексный API--OSCache API дает вам полный программный контроль над всеми функциями OSCache. Постоянные кэши. Кэши можно произвольно записывать на диск, что позволяет сохранять в кэше дорогостоящие данные, даже допуская перезапуск приложений. Поддержка кластеров — данные кэша кластера могут быть параметризованы индивидуально без изменения кода. Срок действия кэшированных записей. Вы можете максимально контролировать срок действия кэшированных объектов, включая подключаемые политики обновления (если это не требуется для производительности по умолчанию). JCACHE JCACHE — это будущая стандартная спецификация (JSR 107), описывающая метод временного кэширования объектов Java в памяти, включая создание объектов, общий доступ, буферизацию, аннулирование, согласованность отдельных JVM и т. д. Его можно использовать для кэширования наиболее часто читаемых данных в JSP, таких как каталоги продуктов и прайс-листы. Благодаря JCACHE время ответа на большинство запросов ускоряется за счет кэширования данных (внутренние тесты показывают, что время ответа примерно в 15 раз быстрее). Ehcache Ehcache происходит от Hibernate, который используется в качестве решения для кэширования данных в Hibernate. Система кэширования Java JCS является подпроектом Джакартского проекта Turbine. Это составной буферный инструмент. Объекты можно буферизовать в память, на жесткий диск. Имеет параметры истечения срока действия объекта буфера. Также возможно построить распределенную архитектуру с буферизацией через JCS для достижения высокой производительности приложений. Для некоторых объектов, к которым требуется частый доступ и которые потребляют много ресурсов каждый раз, когда к ним обращаются, они могут быть временно сохранены в буфере, что может повысить производительность службы. А JCS — хороший буферный инструмент. Средство буферизации может значительно повысить производительность приложений, в которых операций чтения гораздо больше, чем операций записи. SwarmCache SwarmCache — это простой и мощный механизм распределенного кэширования. Он использует IP-многоадресную рассылку для эффективной связи между кэшированными экземплярами. Он идеально подходит для быстрого повышения производительности кластерных веб-приложений. ShiftOne ShiftOne Object Cache Эта библиотека Java предоставляет базовые возможности кэширования объектов. Реализованные политики: «первым пришел — первым обслужен» (FIFO), последним использованным (LRU), наименее часто используемым (LFU). Все стратегии максимизируют размер элемента и максимизируют время его выживания. WhirlyCache Whirlycache — это быстрый, настраиваемый кэш объектов в памяти. Он может ускорить веб-сайт или приложение за счет кэширования объектов, которые в противном случае пришлось бы создавать, запрашивая базу данных или другой дорогостоящий обработчик. Jofti Jofti может индексировать и искать объекты на уровне кэша (поддерживает EHCache, JBossCache и OSCache) или объекты в структурах хранения, поддерживающих интерфейс Map. Платформа также предоставляет прозрачные функции для добавления, удаления и изменения объектов в индексе, а также простые в использовании функции запросов для поиска. cache4j cache4j — это быстрый кеш объектов Java с простым API и реализацией. Его особенности включают в себя: кэширование в памяти, предназначенное для многопоточных сред, две реализации: синхронизация и блокировка, несколько стратегий очистки кеша: LFU, LRU, FIFO, строгая ссылка (strong reference) и мягкая ссылка (soft ссылка) объект хранения. Open Terracotta Инфраструктура кластеризации с открытым исходным кодом на уровне JVM, которая обеспечивает: репликацию HTTP-сеансов, распределенное кэширование, кластеризацию POJO и распределенную координацию приложений между JVM в разных кластерах (при внедрении кода, поэтому вам не нужно ничего изменять). sccache Система кэширования объектов, используемая SHOP.COM. sccache — это внутрипроцессный кеш и вторичный общий кеш. Он сохраняет кэшированные объекты на диск. Поддерживает связанные ключи, ключи любого размера и данные любого размера. Возможность автоматизации сбора мусора. Shoal Shoal — это масштабируемая динамическая кластерная среда на основе Java, которая обеспечивает поддержку инфраструктуры для создания отказоустойчивых, надежных и доступных приложений Java. Фреймворк также можно интегрировать в любой продукт Java, который не хочет быть привязанным к определенному протоколу связи, но требует поддержки кластера и распределенной системы. Shoal — это механизм кластеризации для серверов приложений GlassFish и JonAS. Simple-Spring-Memcached Simple-Spring-Memcached, который инкапсулирует вызовы MemCached, делает разработку клиента MemCached невероятно простой.