По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.
Основой любого сайта является HTML. Это первое, что видят люди. Без него сайта бы не существовало.
Поэтому так важно придерживаться правильных методов написания кода. Если этого не делать, то посетители вашего сайта получат плохой пользовательский опыт.
В HTML всегда есть, чему поучиться. Причем не важно, новичок вы в программировании или опытный специалист.
В данной статье мы поговорим о лучших практиках HTML. Давайте начнем.
Лучшие практики HTML – это набор правил, помогающих создавать сайты, одинаково удобные для чтения и сопровождения.
При создании сайта на HTML необходимо придерживаться следующих принципов:
Используйте только один элемент <h1> для страницы
В HTML доступно 6 различных тегов заголовков – от <h1> до <h6>. Тегом <h1> отмечается основной заголовок (название веб-страницы), а тег <h6> используется для наименее важного заголовка.
Тег <h1> крупнее <h2>, <h2> крупнее <h3> и так до тега <h6>. Размер каждого заголовка уменьшается по степени его важности.
Очень важно не добавлять более одного элемента <h1> на странице.
Не делайте так:
<main>
<div>
<h1>Писать код – это весело?</h1>
<p>Чем больше вы пишете, тем опытнее становитесь</p>
</div>
<div>
<h1>Писать код – это весело</h1>
<p>Лучше писать код с удовольствием</p>
</div>
</main>
В примере выше мы используем тег <h1> в первом и втором блоке <div>. Такой код, конечно же, заработает, но это не самый правильный вариант оформления.
Лучше вот так:
<main>
<div>
<h1>Писать код – это весело?</h1>
<p>Чем больше вы пишете, тем опытнее становитесь</p>
</div>
<div>
<h2>Писать код – это весело</h2>
<p>Лучше писать код с удовольствием</p>
</div>
</main>
Кроме того, наличие одного элемента <h1> на странице – крайне важно для поисковой оптимизации (SEO). Через этот тег поисковики понимают, что находится на странице (главная мысль страницы).
Не забывайте про иерархию заголовков в HTML
Когда вы пользуетесь тегами заголовков, важно следовать установленной иерархии: после <h1> идет <h2>, за <h3> следует <h4> и т.д...
Не перескакивайте от <h1> к <h3>. Некоторые посетители сайта используют средства чтения с экрана. И таким пользователям бывает трудно понять содержимое вашей страницы при нарушенной иерархии элементов.
Средства чтения с экрана – это одна из специальных возможностей, помогающая людям получать доступ к цифровому содержимому (сайтам или приложениям) и взаимодействовать с ним через звуки и касания. Основные пользователи данной технологии – слабовидящие или незрячие люди.
Не делайте так:
<h1>Писать код – это весело</h1>
<h3>Лучше писать код с удовольствием</h3>
<h5>Постоянство – это ключ</h5>
Лучше вот так:
<h1>Писать код – это весело?</h1>
<h2>Чем больше вы пишете, тем опытнее становитесь</h2>
<h3>Писать код – это весело</h3>
Добавляйте подписи к изображениям через элемент figure
Добавлять подписи к изображениям рекомендуется через элемент <figure>. А чтобы все заработало, нужно прописать не только <figure>, но и <figcaption>.
Не делайте так:
<div>
<img src=“a-man-coding.jpg” alt=“Мужчина за компьютером”>
<p>Это изображение мужчины, который работает за компьютером</p>
</div>
С точки зрения кода, пример выше написан хорошо. Но лучше сделать все иначе. Если изображение не загрузилось, отображается содержимое alt, и на экране показывается текст из элемента <p>. Но посетитель, использующий средства чтения с экрана, не сможет отличить тексты в <p> и alt.
Помните: даже если ваш код работает, это еще не значит, что вы делаете все правильно.
Лучше сделать вот так:
<figure>
<img src=“a-man-coding.jpg” alt=“ Мужчина за компьютером”>
<figcaption>Это изображение мужчины, который работает за компьютером</figcaption>
</figure>
Пример выше – отличный способ, как можно добавить подписи к изображениям.
Почему важно добавлять подписи к изображениям именно так:
Поисковая оптимизация. Ваши изображения легче найти в поисковых системах.
Посетителям, использующим средства чтения с экрана, проще понять содержимое вашей страницы.
Не используйте div для шапки и подвала; для этого подходят семантические элементы
Семантические элементы HTML используются для логической разметки структуры документа на странице. Кроме того, они нужны для правильной сборки страницы.
Откажитесь от <div> в пользу семантики. Не используйте <div> для обозначения шапки и подвала страницы. Для этих целей есть семантические элементы <header> и <footer>.
Элемент <header> показывает навигацию или вводную часть страницы.
В элементе <footer> размещается информация об авторских правах или ссылки для перехода на страницы.
Не делайте так:
<div class="header">
<a href="index.html">Главная</a>
<a href="#">О нас</a>
<a href="#">Контакты</a>
</div>
<div class="footer">
<a href="index.html">Главная</a>
<a href="#">О нас</a>
<a href="#">Контакты</a>
</div>
В примере выше тег <div> используется в качестве контейнера для <header> и <footer>. Такой код будет работать, но это не самый правильный способ реализации.
Лучше вот так:
<header>
<h1></h1>
</header>
<footer>
<a href="index.html">Главная</a>
<a href="#">О нас</a>
<a href="#">Контакты</a>
</footer>
Лучше всего добавлять <footer> и <header> на страницу именно так.
Почему важно добавлять <footer> и <header> с помощью семантических элементов HTML:
Использование семантических элементов для шапки и подвалаупрощает чтение кода.
Такой способ предлагает более качественный пользовательский опыт. Посетителям, использующим средства чтения с экрана, будет проще понять содержимое страницы.
Не используйте <b> и <i> для выделения текста на странице
Теги <b> и <i> выделяют текст жирным шрифтом (b) или курсивом (i). Но не стоит ими пользоваться на сайте, поскольку оба тега не несут семантической нагрузки. Для выделения текста лучше подходит свойство CSS font-weight, либо теги <strong> и <em>.
Тегом <strong> отмечают важный текст на странице. Он выделяет текст или делает его жирным. Тег <em> подчеркивает текст или добавляет курсив (точно также, как <i>).
Не делайте так:
<p><i>Пишите код в своем собственном темпе</i><p>
<p><b>пишите код в своем собственном темпе </b><p>
В этом примере текст выделяется жирным и курсивом. Но пользователи со средствами для чтения с экрана не заметят разницы. Данные теги не несут семантического значения.
Спецификация HTML 5 рекомендует нам использовать теги <b> и <i> только в самых крайних случаях и при отсутствие альтернативных вариантов.
Лучше делайте так:
<p><strong>Пишите код в своем собственном темпе</strong><p>
<p><em>пишите код в своем собственном темпе</em><p>
Не используйте блочные элементы внутри строчных
Блочные элементы начинают новую строку на странице. По умолчанию действие этих элементов распространяется на всю строку – от ее начала до конца. Вы не сможете добавить строчные элементы внутри блочных без CSS.
К блочным элементам относятся <p>, <h1> – <h6> и <div>.
Строчные элементы действуют на небольшую часть страницы. Они не начинаются с новой строки.
К строчным элементам относятся <span>, <em> и <a>.
Вы не можете добавить блочные элементы внутри строчных.
Не делайте так:
<a href="#" >
<p>Посетите merion</p>
</a>
У вас не получится добавить <p> внутрь элемента <a>, поскольку <p> относится к блочным элементам, а <a> – к строчным.
Лучше сделать так:
<p>
Посетите <a href="wiki.merionet.ru" target="_blank">Merion</a>
для изучения IT
</p>
Это отличный пример того, как можно вложить строчные элементы внутри блочных.
Важно помнить, что:
Блочный элемент нельзя вложить внутри строчного.
Строчный элемент можно вложить внутри блочного.
Строчный и блочный элемент можно вложить внутри блочного.
Небольшое уточнение: «вложить» что-то в данном случае означает «добавить внутрь». Так что, говоря «это нельзя вложить», я имею ввиду, что вы не сможете добавить один такой элемент внутрь другого.
Надеюсь, вы запомнили 3 простых правила для вложения элементов.
Кроме того, CSS позволяет преобразовать блочные элементы в строчные. Для этого используется display: inline-block и display: inline.
А еще важно помнить простую истину: даже если ваш код работает, это еще не значит, что вы делаете все правильно.
Именно поэтому я всегда рекомендую пользоваться валидатором разметки W3C и дополнительно проверять свой код.
Этот валидатор отслеживает правильность разметки веб-документов в HTML, XHTML, SMIL, MathML и т.д.
Для проверки кода можно скопить его URL и добавить на сайт, либо загрузить сам файл HTML.
Заключение
Надеемся, что данная статья помогла вам узнать что-то новое о лучших практиках в HTML. Мы постарались включить в нее самые полезные советы, которыми можно начинать пользоваться уже сегодня.
Конфигурация вашей сети Cisco хранится в двух основных местах: одно находится в ОЗУ, а другое - в текущей конфигурации (running configuration). Когда вы вводите команды, они активируются немедленно и сохраняются в текущей конфигурации, которая хранится в ОЗУ.
Поэтому при выключении питания конфигурация теряется. Чтобы сохранить эту конфигурацию, скопируйте ее в загрузочную конфигурацию (startup-configuration), что означает, что она хранится в энергонезависимой ОЗУ (NVRAM), чтобы конфигурация сохранялась при выключении питания.
Вы можете использовать две команды для сохранения вашей конфигурации: команду записи или команду копирования. Команда записи устарела, но будет выглядеть так:
Router#write memory
Building configuration...
[OK]
Более новая версия команды - это команда копирования, которая выглядит как:
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Команда копирования предлагает больше гибкости и возможностей. Вы можете не только скопировать данные текущей конфигурации в файл начальной конфигурации, но и скопировать их в файл на флэш-памяти или на TFTP-сервер в вашей сети.
Для любой команды вам нужно набрать столько букв, сколько требуется IOS для однозначной идентификации команды. Например:
copy run sta