Рубрика «redis» - 5

в 10:40, , рубрики: ehcache, Hazelcast, Ignite, java, redis, tarantool, Анализ и проектирование систем, Блог компании Sportmaster Lab, высокая производительность, для начинающих, истории, ит-системы, кеширование, психология программирования, Разработка веб-сайтов

Привет! Меня зовут Алексей Пьянков, я разработчик в компании Спортмастер. В этом посте я рассказал, как начиналась работа над сайтом Спортмастер в 2012 году, какие инициативы удалось «протолкнуть» и наоборот, какие грабли мы собрали.

Сегодня я хочу поделиться мыслями, которые следуют за другим сюжетом – выбор системы кеширования для java-бэкенда в админке сайта. Этот сюжет имеет особое значение для меня – хотя история разворачивалась всего 2 месяца, но эти 60 дней мы работали по 12-16 часов и без единого выходного. Никогда раньше не думал и не представлял, что можно так много работать.

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

Как мы в Спортмастере выбирали систему кеширования. Часть 1 - 1
Читать полностью »

в 10:35, , рубрики: devops, kubernetes, kubernetes operator, nosql, redis, Администрирование баз данных, Блог компании Флант

Одна история с оператором Redis в K8s и мини-обзор утилит для анализа данных этой БД - 1

Что будет, если использовать всем известное in-memory-хранилище ключей и значений в качестве персистентной базы данных, не используя TTL? А если оно запущено с помощью надёжного, казалось бы, оператора в Kubernetes? А если в процессе увеличения реплик Redis мы внесём ещё одно маленькое и безобидное изменение?.. Отвечая на эти вопросы в данной статье, мы попутно расскажем, какие утилиты помогут найти пути к оптимизации размеров большой БД в Redis.

Проблемный кейс

Redis у нас используется внутри кластера Kubernetes в разных проектах. Для удобства управления и применения единых практик в рамках компании мы остановились на операторе от Spotahome. По нашему опыту, это наиболее стабильный вариант, хотя и у него есть свои проблемы, некоторые из которых будут затронуты далее в статье.Читать полностью »

в 16:00, , рубрики: nosql, redis

Вторая часть цикла переводов «Redis Best Practices» от Redis Labs, и в ней рассмотрены паттерны взаимодействия и паттерны хранения данных.

Redis Best Practices, часть 2 - 1

Читать полностью »

в 12:44, , рубрики: Amazon RDS, CDN, Digital Ocean Managed Database, Elasticache, google cloud, heroku, memcached, Memorystore, miran, Miran.ru, mysql, paas, postgresql, read replicas, redis, балансировщик нагрузки, Блог компании Дата-центр «Миран», вертикальное масштабирование, горизонтальное масштабирование, масштабирование, облачные сервисы, партиционирование, Разработка веб-сайтов, реплики чтения, Серверное администрирование, СУБД, хостинг, шардирование

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

Это приятная проблема, но в Сети мало чёткой информации, как аккуратно масштабировать веб-приложение с нуля до сотен тысяч пользователей. Обычно встречаются или пожарные решения, или устранение узких мест (а часто и то, и другое). Поэтому люди используют довольно шаблонные приёмы по масштабированию своего любительского проекта в нечто действительно серьёзное.

Попытаемся отфильтровать информацию и записать основную формулу. Мы собираемся пошагово масштабировать наш новый сайт для обмена фотографиями Graminsta с 1 до 100 000 пользователей.

Запишем, какие конкретные действия необходимо сделать при увеличении аудитории до 10, 100, 1000, 10 000 и 100 000 человек.
Читать полностью »

в 8:25, , рубрики: KeyDB, nosql, open source, redis, Администрирование баз данных, Блог компании Флант, системное администрирование

На хабре не нашлось обзоров «более быстрой альтернативы Redis» — KeyDB. Получив достаточно свежий опыт его использования, хочется восполнить этот пробел.

KeyDB как [потенциальная] замена Redis - 1

Предыстория достаточно банальна: однажды с большим наплывом трафика была зафиксирована значительная деградация производительности приложения (а именно — времени ответа). На тот момент, к сожалению, не удалось провести нормальную диагностику происходящего, поэтому впоследствии запланировали ряд нагрузочных тестирований. После их проведения удалось обнаружить узкое место, коим стал кэш базы данных в Redis. Как это часто бывает, проблему нельзя было решить сию секунду и правильным путём — силами разработчиков (изменением логики работы). Поэтому включилось любопытство и желание побороть ситуацию обходным путём. Так и появилась эта статья.Читать полностью »

в 9:42, , рубрики: Facebook API, facebook messenger, Lua, nginx, php, PHP Russia, php-fpm, ReactPHP, redis, webhook, Блог компании ManyChat, Блог компании Конференции Олега Бунина (Онтико), вебхуки, высокая производительность

Скорее всего, рассказывать, что такое вебхуки (webhooks) — никому не нужно. Но на всякий случай: вебхуки — это механизм оповещения о событиях во внешней системе. Например, о покупке в интернет-магазине через онлайн-кассу, отправке кода в GitHub-репозиторий или действиях пользователей в чатах. В типичном API нужно постоянно опрашивать сервер, написал ли пользователь что-нибудь в чате. С помощью механизма вебхуков можно «подписаться» на оповещения, и сервер сам отправит HTTP-запрос, когда произойдет событие. Это удобнее и быстрее, чем постоянно запрашивать новые данные на сервере.

Эволюция обработки вебхуков Facebook: с нуля до 25 000 в секунду - 1

ManyChat — это платформа, которая помогает бизнесу общаться со своими клиентами через чаты в мессенджерах. Вебхуки — одна из важных частей ManyChat, потому что именно через них бизнес общается с клиентами. А общаются они много — например, через систему бизнесы отправляют своим клиентам миллиарды сообщений в месяц.

Основная масса сообщений отправляется через Facebook Messenger. У него есть особенность — медленный API. Когда клиент пишет сообщение, чтобы заказать пиццу, Facebook отправляет в ManyChat вебхук. Платформа его обрабатывает, отправляет запрос обратно и пользователь получает сообщение. Из-за медленного API некоторые запросы идут несколько секунд. Но когда платформа долго не отвечает, бизнес теряет клиента, а Facebook может отключить приложение от вебхуков.

Поэтому обработка вебхуков — это одна из главных инженерных задач платформы. Чтобы решить проблему, в ManyChat за три года работы несколько раз меняли архитектуру обработки с простого контроллера в Yii до распределенной системы с «Галактиками». Подробнее об этом под катом расскажет Дмитрий Кушников (cancellarius).
Читать полностью »

в 11:46, , рубрики: nosql, redis

В серии из нескольких статей я приведу свой адаптированный перевод раздела Redis Best Practices с официального сайта Redis Labs.

Redis Best Practices, часть 1 - 1

Читать полностью »

в 22:28, , рубрики: diy или сделай сам, php, queues, redis, redis stream, Streams, symfony, symfony-messenger, очереди, распределенные системы, шина

Перевод PHP бэкенда на шину Redis streams и выбор независимой от фреймворков библиотеки - 1

Предисловие

Мой сайт, которым я занимаюсь в качестве хобби, предназначен для хранения интересных домашних страниц и персональных сайтов. Эта тема стала интересовать меня в самом начале моего пути в программировании, в тот момент меня восхищало нахождение больших профессионалов, которые пишут о себе, своих увлечениях и проектах. Привычка открывать их для себя осталась и сейчас: почти на каждом коммерческом и не очень сайте я продолжаю заглядывать в футер в поисках ссылок на авторов.
Читать полностью »

в 18:46, , рубрики: Go, redis
Cинхронизаци кэша через Redis для сервиса на Go - 1

Введение

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

Читать полностью »

в 17:20, , рубрики: Amazon Web Services, Ansible, celery, DataDog, django, elasticsearch, Listen Notes, nginx, postgresql, python3, RabbitMQ, React, redis, slack, uwsgi, звук, поисковые технологии, Разработка веб-сайтов, Серверное администрирование, скука

Скучный технологический стек интернет-компании из одного человека - 1
Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.
Читать полностью »

1...456...10...15
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js