Redis — главное хранилище? Что за хрень?!
Redis это размещаемое в памяти хранилище ключ-значение, обычно используемое для кэшей и подобных механизмов ускорения сетевых приложений. Мы, тем не менее, храним все наши данные в Redis — в нашей главной базе данных.
Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.
Прежде всего, я хотел бы подчеркнуть что большинство приложений вовсе не должны обращать внимания на костыли использованные, что бы пойти таким путём. Это было важно для нашего сценария использования, но мы можем быть граничным случаем.
Redis как хранилище данных
Redis быстр. Когда я говорю быстр, я имею в виду Быстр с заглавной буквы Б. Это по существу memcached с более продуманными типами данных, нежели просто строковые значения. Даже некоторые продвинутые операции такие, как пересечение множеств, выборка диапазонов zset, ослепительно быстры. Есть все поводы использовать Redis для быстроменяющихся активно запрашиваемых данных. Он довольно часто используется в качестве кэша, который может быть перестроен по данным из резервной базы данных. Это мощная замена memcached предоставляющая более продвинутое кэширование для различных видов хранимых вами данных.
Как и в memcached, всё находится в памяти. Redis сохраняется на диск, но он не сохраняет данные синхронно с тем как вы записываете их. Есть две причины из-за которых Redis в качестве главного хранилища — отстой:
— Вы вынуждены умещать все свои данные в памяти, и…
— Если сервер откажет между двумя синхронизациями с диском — вы потеряете всё что сидело в памяти.
Из-за этих двух проблем Redis обосновался в компактной нише в качестве временного кэша для данных которыми вы можете пожертвовать, но не главного хранилища данных. Предоставляя быстрый доступ к часто необходимым данным с возможностью перестроения при необходимости.
Недостаток использования более традиционных хранилищ за Redis заключается в затыке с производительностью этих хранилищ. Вам приходится жертвовать производительностью чтобы убедиться, что данные сохранены на диск. Совершенно нормальная сделка для почти каждого приложения. Вы можете получить великолепную производительность по чтению и «хорошую» производительность по записи. Я должен пояснить, что «хорошая» для меня вполне вероятно может быть безумно быстрая для большинства людей. Достаточно сказать, что «хорошая» производительность по записи должна удволетворить большинство, кроме самых высоко нагруженных приложений.
Я полагаю, что вы можете выполнить запрос на запись в Redis а потом сохраниться при помощи реляционного хранилища, но тогда остаются те же риски падения Redis и потери данных очереди записи.
Что нам нужно?
Moot предлагается как полностью бесплатный продукт. Нам, таким образом, необходимо иметь возможность обрабатывать крупные нагрузки на очень небольшом количестве железа. Если нам нужна куча больших баз данных для форума обслуживающего несколько миллионов пользователей в месяц, то нет никаких способов остаться бесплатным сервисом. Поскольку мы хотим, что бы Moot был и бесплатным и неограниченным, мы вынуждены были оптимизировать до предела.
Мы могли бы просто избежать этого установив какие-нибудь ограничения на бесплатные сервисы и брать деньги за просмотр страниц или постов. Не знаю как вы, но я, в общем, не люблю продукты, которые бесплатны «пока вы не раскрутитесь». Скажем, вы настроили форум, а потом что-то на вашем сайте станет вирусным. Внезапно, вас ошарашат счётом за превышение бесплатного уровня. И вот то, что начиналось как развлечение, из-за внезапной популярности вашего блога о теории заговоров, превращается в ужас грядущего счёта. Вас наказывают за ваш успех. Это то, чего мы хотели бы избежать.
Мы так же могли бы решить монетизироваться размещая рекламу, и позволив себе более высокие эксплуатационные расходы. Это, тем не менее, полностью расходится с нашим базовыми ценностями как бизнеса. По нашему мнению, если кто-то собирается размещать рекламу на вашем сайте, это должны быть вы а не мы. Moot должен предлагаться без условий, ограничений и приписок.
Принимая во внимание всё вышесказанное, необходимо достичь непревзойдённой производительности для постинга и чтения не взирая на инженерные сложности. Это базис для нашей возможности работать. У нас была изначальная цель, чтобы все вызовы API обрабатывались менее чем за 10мс даже под высокой нагрузкой, и даже тогда, когда обрабатываются большие сложные списки или поиски. Redis, очевидно, может обеспечить нам такую производительность, но две большие проблемы никуда не делись: Как, блин, мы сможем использовать Redis, если у нас могут быть сотни гигабайт данных, и что делать с падением сервера?
Что же теперь делать?
Так началось наше исследование способов проектирования с учётом этих ограничений. У нас с самого начала было точное понимание какими будут задачи у Moot, и наших ценностей как компании, поэтому нам повезло иметь возможность обдумать эти особенности до написания первых строчек кода. Я полагаю что эти проблемы были бы чрезмерно сложны, если бы мы решили пойти этим путём, имея множество готового кода.
Все данные в памяти. Блин.
Это самая сложна из двух проблем. Количество памяти, которое может быть на одном компьютере, конечно. Наибольшее количество на EC2 это 244-гигабайтный сервер. Хотя это по прежнему конечный объём, это довольно хороший лимит для начала. К сожалению, при этом ваш 16-ядерный сервер будет использовать только одно ядро для Redis. Что ж, как на счёт добавления по подчинённому процессу Redis на каждое ядро? Тогда у вас осталось по 15 ГБ памяти на каждый экземпляр. Опять фигня! Это плохое ограничение, если вы хотите иметь возможность выжать из сервера мощность. Это не достаточно данных для сервиса хостинга.
Мы решили спроектировать наше Redis-хранилище с самого начала разделённым среди множества Redis кластеров. Мы хэшируем и разделяем данные в блоки содержащие все структуры, относящиеся к данному сегменту данных. Данные сильно разделены с самого начала и мы можем по необходимости создавать новые блоки быстро и просто.
Для разбивки данных мы храним таблици хэшей и адресов примерно так:
Когда поступают данные, мы вычисляем хэш на основе наших требований к связности данных, потом мы проверяем в shards.map был ли он назначен какому-нибудь блоку, и если да — мы можем направить вызовы на тот блок.
Если хэш ещё не приписан к какому либо блоку, мы создаём список доступных блоков множа их в соответствии с весом. Если например выполнить:
Список будет выглядеть как-то так:
После этого мы назначаем случайный блок из списка, сохраняем в карту распределения и идём далее.
Применяя такую схему мы можем легко контролировать сколько данных поступает в блоки, добавлять новые блоки или даже исключать блоки из рассмотрения, если видим, что они заполнены.
Реально мы начали с сотен блоков так что нечего беспокоиться о нагрузке на сервера и ограничениях памяти.
Отдельные блоки остаются очень малыми. Один сервер содержит много блоков в базах данных Redis и, если эти блоки увеличиваются в размерах, мы легко можем разделить базы Redis на независимые экземпляры. Скажем у нас экземпляр Redis с 100 блоками, мы видим, что некоторые блоки увеличиваются в размере и мы разделяем Redis на два экземпляра по 50 блоков каждый. Мы можем точно настроить веса чтобы поддерживать распределение между блоками в реальном времени.
Самая сложная часть, это точно определить то, как вы сегментируете ваши данные. Это очень специфично и наш вариант сегментации, возможно, тема для отдельного поста.
Такая стратегия хранения должна разрабатываться в приложении с самого начала. Часто люди пытаются разделять данные, которые так не спроектированы, в этом то и загвоздка для их использования Redis. Поскольку мы чётко знали, что ограничение памяти будет проблемой, мы смогли спроектировать решение в самом ядре нашей системы управления данными, ещё до того как мы написали хоть одну строчку кода.
Падения сервера
Разобраться с отказами оказалось, смешно сказать, легче. У нас для кластера Redis было 3 разные роли:
— Мастер, где происходили почти все операции на запись,
— Подчинённый, гда происходили почти все чтения,
— Хранитель, выделенный для сохранения данных.
Мастер и подчинённый работают в общем как и любые другие в кластере Redis. В этом нет ничего интересного. Что мы сделали нового, это то что в каждом кластере есть по 2 сервера, используемых в качестве хранителей. Эти сервера:
— Не принимают никаких входящих соединений и не несут никакой нагрузки Redis запросов, кроме простой репликации
— Хранение AOF в ежесекундном режиме
— Ежечасный снимок RDB
— Синхронизируют AOF и RDB в S3
В виду того, что параметры производительности для хранения могут несколько различаться, один сервер хранитель может обработать различное количество блоков. Мы просто запускаем по одному экземпляру на каждый блок, который должен храниться. Другими словами, нет необходимости в отношении 1 к 1 между блоками и серверами с ролью хранителя.
У нас два этих сервера расположены в различных зонах доступности, так что даже если одна из зон выходит из строя, у нас есть работающий актуальный сервер-хранитель.
Таким образом, чтобы нам потерять данные необходим довольно большой отказ в EC2 и даже тогда, мы потеряем только около секунды данных.
Если вы рассматриваете сценарий нарушения связности сети, когда мастер может быть изолирован от подчинённых, его можно нивелировать проверкой репликации подчинённых(установить произвольный ключ в произвольное значение и проверить, обновились ли данные у подчинённого) Если мастер изолирован, мы останавливаем запись: Согласованность и Устойчивость к потере связности за счёт Доступности. Redis Sentinel тоже мог бы помочь нам с этим, но Sentinel был выпущен позже того, как мы реализовали большую часть системы. Мы не исследовали, как Sentinel мог бы вписаться бы в наше уравнение.
Конечный результат
В конце концов, мы смогли построить систему, которая под нагрузкой выполняет вызовы API за приблизительно 2 мс.
Значение 2 мс — при обслуживании нашего самого тяжёлого API-вызова, инициализационного API-вызова.
Многие наши запросы обслуживаются гораздо быстрее ( лайки например часто за 0.6-0.7 мс). Мы можем исполнять 1000 API запросов в секунду на одном API сервере. И для построения страницы требуется один API вызов. В замер включены все наши проверки данных, управление блоками, аутентификация, управление сессиями, соединениями, сериализация JSON и так далее.
Серверы API, которые позволяют работать с такой нагрузкой, стоят всего $90 в месяц, так что мы можем поддерживать и горизонтально масштабировать довольно большие нагрузки по очень маленькой цене. Другая побочная польза от сильно разделённых на блоки данных, это то что горизонтальное масштабирование выполняется тривиально.
Многое из этого заслуга не только ЭТИХ решений для Redis. Есть ещё несколько трюков для того, чтобы система производительно работала под высокой параллельной нагрузкой. Один из этик трюков в том, что почти половина нашего кода написана на Lua и работает прямо в Redis. Это другая вещь, которую в общем говорят не делать. Что касается того, как и почему у нас тысячи строк кода на Lua — подождите следующего поста о нашем применении Redis.
Взгляните на нашу реальную производительность, мы запустились пару дней назад, и получили неплохой начальный всплеск. Мы обслуживали 50 API вызовов в секунду и процессор нашего главного API сервера (мы до сих пор посылаем весь трафик на один) был полностью в простое. Вот графики, начиная с нашего запуска до момента написания поста.
Во время наших пиковых нагрузок всё тихо. Вы можете заметить пару всплесков, когда мы накатывали хотфиксы, но в остальном ни шороха. Более поздние всплески соответствуют обновлениям системы, исправлениям и другим проводимым системным работам. Общая нагрузка так же включает увеличенные накладные расходы на логгирование которое мы вели в период начального бета теста.
Пояснение: я ссылаюсь на API сервер как на замеряемый, так как наш сервер приложений и Redis сервер это одно и тоже. API сервер несёт на себе как несколько блоков, так и приложение. Идея была в том, чтобы маршрутизировать трафик на сервер где в основном расположен этот блок, чтобы воспользоваться unix-сокетами для подключения к Redis. Это позволят избегать излишнего сетевого трафика поэтому нет особого различия между Сервером приложений, Redis мастером и Redis подчинённым. Любой API сервер может обработать любой запрос, просто мы даём гораздо больший приоритет мастер серверу задействованного сегмента данных. Все серверы — серверы приложений, и все серверы — мастера для каких-то блоков и подчинённые для других.
tl;dr
Есть множество причин не использовать Redis как главное хранилище на жёстком диске, но если, по каким-то причинам, ваш вариант использования требует этого, вам необходимо начинать с самого начала. Вам стоит проектировать ваши данные разделёнными и помнить о дополнительной стоимости выделенных серверов хранения.
ПОПРАВКА
Я только что понял, что я посчитал стоимость отдельного сервера и забыл добавить амортизированную единовременную стоимость зарезервированных экземпляров. Должно быть $213.
Microsoft Visual C++ что это за программа и нужна ли она?
Привет пипл Сегодня будем узнавать что такое Microsoft Visual C++ и для чего это нужно, а также можно ли удалить. Я думаю что у вас на компе установлено как минимум десять программ, а то и больше, некоторые из них для вас очень важны, другие не очень, а третьи вы вообще не устанавливали, и такое бывает
Не все программы готовы к работе, ну, это я в каком смысле — в том что после установке в Windows также должны быть дополнительные компоненты, которые используются несколькими программами. Именно по этой причине они как бы не должны идти вместе с каждой программой, но так как часто этих компонентов нет на компе, то они как раз и идут в программе как отдельный компонент
А впрочем покажу на примере. Вот есть такая программа как фаервол Outpost, при его установке устанавливается не только сам Outpost но и еще компоненты Microsoft Visual C++, которые нужны ему для работы. То есть понятно, да, что если удалить эти компоненты потом, то некоторые ваши программы могут перестать работать, так что возьмите это себе на заметку
Вот например у меня они тоже стоят, несколько, у вас может быть больше или меньше:
Ну что, вы сделали вывод что такое Microsoft Visual C++? Если вы это видите в списке установленного софта, то удалять не стоит! Если они там есть значит они нужны какой-то программе или нескольким, соответственно если удалите — будут неприятности Кстати, вот игры когда вы ставите, то также устанавливаются и эти Microsoft Visual C++, помимо DirectX.
Но есть и второй вариант ответа на вопрос что такое Microsoft Visual C++ — это студия. IDE или студия для разработки программ на языке программирования C++, то есть это редактор такой себе, там программисты пишут код и потом проверяют как что работает. В общем пишут программы, функции, библиотеки.
Ну, вполне логично, что студия стоит у программистов. Так что если вы великий программист, то сносить эту студию просто нет смысла, ну это и так понятно думаю
Примерно так выглядит студия разработки (IDE), примерно потому что есть разные версии и они внешне немного все же отличаются:
Но я думаю, что у вас скорее всего стоит не студя разработки, а именно дополнительные компоненты для нормальной работы программ.
Еще могу сказать, что в некоторых случаях бывает и обратная сторона — вы ставите программу, а она говорит, мол так и сяк, у вас нет Microsoft Visual C++, поэтому установите, иначе я не установлюсь (в таком случае придется искать их на сайте Microsoft). Но, такое бывает редко, как уже писал, программы обычно уже в себе имеют компоненты Microsoft Visual C++ и ставят их при инсталляции.
Распространение файлов Visual C++
Вы находитесь здесь, так как ищете скачивание одного из файлов среды выполнения Visual C++? Перейдите на страницу последних поддерживаемых Распространяемый компонент Visual C++ скачивания.
Распространяемые файлы и лицензирование
При развертывании приложения необходимо также развернуть файлы, поддерживающие это приложение. Если какой-либо из этих файлов предоставляется корпорацией Майкрософт, проверьте, разрешено ли повторно распространять их. Вы найдете ссылку на условия лицензии Visual Studio в интегрированной среде разработки. Используйте ссылку «Условия лицензии» в диалоговом окне «О Microsoft Visual Studio». Также можно скачать соответствующие EULA и лицензии из каталога лицензий Visual Studio.
Чтобы просмотреть список REDIST, на который ссылается раздел «Распространяемый код» Visual Studio 2022 условия лицензионного соглашения на использование программного обеспечения Майкрософт, см. раздел «Файлы распространяемого кода» для Microsoft Visual Studio 2022 г.
Чтобы просмотреть список REDIST, на который ссылается раздел «Распространяемый код» условий лицензионного соглашения на Visual Studio 2019 г., см. раздел «Файлы распространяемого кода» для Microsoft Visual Studio 2019 г.
Чтобы просмотреть список REDIST, на который ссылается раздел «Распространяемый код» Visual Studio 2017 условий лицензионного соглашения на использование программного обеспечения Майкрософт, см. раздел «Файлы распространяемого кода» для Microsoft Visual Studio 2017 года.
Чтобы просмотреть список REDIST, на который ссылается раздел «Распространяемый код» Visual Studio 2015 условий лицензионного соглашения на использование программного обеспечения Майкрософт, см. раздел «Файлы распространяемого кода» для Microsoft Visual Studio 2015 года.
Дополнительные сведения о распространяемых файлах см. в разделе «Определение библиотек DLL для распространения и примеров развертывания».
Поиск распространяемых файлов
Для развертывания распространяемых файлов можно использовать распространяемые пакеты, установленные Visual Studio. В версиях Visual Studio с 2017 года эти файлы называются vc_redist.arm64.exe и vc_redist.x64.exe vc_redist.x86.exe . В Visual Studio 2015, 2017 и 2019 годах они также доступны под именами vcredist_x86.exe , vcredist_x64.exe и (только 2015). vcredist_arm.exe
Самый простой способ найти распространяемые файлы — использовать переменные среды, заданные в командной строке разработчика. В Visual Studio 2022 распространяемые файлы находятся в папке %VCINSTALLDIR%Redist\MSVC\v143 . В последней версии Visual Studio 2019 вы найдете распространяемые файлы в папке %VCINSTALLDIR%Redist\MSVC\v142 . В Visual Studio 2017 и Visual Studio 2019, они также находятся в %VCToolsRedistDir% . В Visual Studio 2015 эти файлы можно найти в %VCINSTALLDIR%redist\<locale> <locale> расположении языкового стандарта распространяемых пакетов.
В Visual Studio 2022 и 2019 файлы модулей слияния являются частью дополнительно устанавливаемого компонента с именем распространяемых MSM версии> C++ < в Visual Studio Installer. Модули слияния устанавливаются по умолчанию как часть установки C++ в Visual Studio 2017 и Visual Studio 2015. При установке в Visual Studio 2022 вы найдете распространяемые модули слияния в %VCINSTALLDIR%Redist\MSVC\v143\MergeModules . В последней версии Visual Studio 2019 распространяемые модули слияния находятся в %VCINSTALLDIR%Redist\MSVC\v142\MergeModules . В обоих Visual Studio 2019 и Visual Studio 2017 года они также находятся в %VCToolsRedistDir%MergeModules . В Visual Studio 2015 года они находятся в Program Files [(x86)]\Common Files\Merge Modules .
Установка распространяемых пакетов
Распространяемые пакеты Visual C++ позволяют устанавливать и регистрировать все библиотеки Visual C++. Если вы используете его, запустите его в качестве необходимого компонента в целевой системе перед установкой приложения. Рекомендуется использовать эти пакеты для развертываний, поскольку они включают функцию автоматического обновления библиотек Visual C++. Пример использования этих пакетов см. в разделе Пошаговое руководство. Развертывание приложения Visual C++ с помощью распространяемого пакета Visual C++.
Каждый пакет Распространяемый компонент Visual C++ проверяет наличие более новой версии на компьютере. Если найдена более поздняя версия, пакет не будет установлен. В Visual Studio 2015 или более поздней версии распространяемые пакеты отображают сообщение об ошибке о том, что установка завершилась сбоем. Если пакет выполняется с помощью флага /quiet , сообщение об ошибке не отображается. В любом случае ошибка записывается установщиком Майкрософт, а результат ошибки возвращается вызывающему объекту. В Visual Studio 2015 и более поздних версиях эту ошибку можно избежать, проверив реестр, чтобы узнать, установлена ли более поздняя версия. Текущий установленный номер версии хранится в HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\VisualStudio\14.0\VC\Runtimes\
Установка распространяемых модулей слияния
Модули слияния ( .msm файлы) для Распространяемый компонент Visual C++ файлов устарели. Мы не рекомендуем использовать их для развертывания приложений. Вместо этого рекомендуется централизованное развертывание пакета Распространяемый компонент Visual C++. Централизованное развертывание распространяемым пакетом позволяет корпорации Майкрософт обслуживать файлы библиотеки среды выполнения независимо. Кроме того, удаление приложения не может повлиять на другие приложения, которые также используют централизованное развертывание. При использовании распространяемого пакета для централизованного развертывания вы не несете ответственности за отслеживание и обслуживание библиотек среды выполнения. В противном случае обновление файлов библиотеки среды выполнения требует обновления и повторного развертывания установщика .msi . Ваше приложение может быть уязвимо к ошибкам или проблемам безопасности до тех пор, пока вы не сделаете это.
Распространяемые модули слияния должны быть включены в пакет установщика Windows (или аналогичный пакет установки), используемый для развертывания приложения. Дополнительные сведения см. в разделе «Распространение с помощью модулей слияния». Пример см. в пошаговом руководстве. Развертывание приложения Visual C++ с помощью проекта установки.
Установка отдельных распространяемых файлов
Также можно напрямую установить распространяемые библиотеки DLL в локальной папке приложения. Локальная папка приложения — это папка, содержащая исполняемый файл приложения. По соображениям обслуживания мы не рекомендуем использовать это расположение установки.
Потенциальные ошибки во время выполнения
Если Windows не удается найти одну из библиотек DLL распространяемой библиотеки, необходимых вашему приложению, может отобразиться примерно следующее сообщение: «Не удалось запустить это приложение, так как библиотека.dll не найдена. Переустановка приложения может устранить эту проблему».
Чтобы устранить эту ошибку, убедитесь, что установщик приложения выполняет сборку правильно. Убедитесь, что распространяемые библиотеки правильно развернуты в целевой системе. Дополнительные сведения см. в разделе Основные сведения о зависимостях приложения Visual C++.
Связанные статьи
Распространение с помощью модулей слияния
Описывает, как использовать модули слияния Распространяемый компонент Visual C++ для установки библиотек среды выполнения Visual C++ в качестве общих библиотек DLL в папке %windir%\system32\ .
Распространение элементов управления ActiveX в Visual C++
Описание процедуры повторного распространения приложения, которое использует элементы управления ActiveX.
Распространение библиотеки MFC
Описание процедуры повторного распространения приложения, которое использует MFC.
Повторное распространение приложения ATL
Описание способа распространения приложения, которое использует ATL. В Visual Studio 2012 и более поздних версиях библиотека ATL не требуется.
Примеры развертывания
Ссылки на примеры, демонстрирующие развертывание приложений Visual C++.
Развертывание классических приложений
Представлены технологии развертывания Visual C++ и связанные понятия.