Иногда интервьюер не предполагает никаких ответов на свои вопросы, пока мысли кандидата ясны, а логика непротиворечива, даже если предложенное решение может быть не самым лучшим, оно может заставить людей сиять в глазах. При принятии технических решений и выборе технологий необходимо идти на компромисс, исходя из потребностей бизнеса.
Соображения по выбору:
- Вам нужен сложный выбор структуры данных? Если это так, используйте Redis в качестве хранилища, в противном случае можно рассматривать как Redis, так и MC. Если есть только простые запросы на получение/установку и требуются высокие требования к производительности, вместо Redis можно использовать MC.
- Вам нужно выполнить постоянное хранение данных, и данные не могут быть потеряны? Если да, используйте Redis для хранения данных и укажите, что он должен использоваться в качестве хранилища вместо кэша при подаче заявки на услугу, и вам необходимо включить постоянное хранилище и регулярное резервное копирование данных.
- Требуется ли механизм Master/Slave для обеспечения высокой доступности службы? Если это так, используйте Redis для хранения данных, и платформа по умолчанию развернет подчиненные библиотеки для всех служб Redis, чтобы обеспечить механизм ведущий/подчиненный.
- Это служба подсчета? Если вы используете Redis в качестве хранилища, включите aof, обеспечив при этом производительность, чтобы данные не были потеряны.
- Вам нужно несколько сегментов для распределенного развертывания? Если это так, используйте Twemproxy для развертывания службы. При использовании Redis в качестве хранилища необходимо учитывать степень поддержки команд. Некоторые команды Redis не поддерживаются в Twemproxy; в противном случае используйте автономный Redis или MC в качестве хранилища или выполните это самостоятельно на стороне клиента.Операции шардинга. Когда платформа использует для развертывания Twemproxy+MC, она автоматически удаляет нештатные экземпляры службы, чтобы обеспечить качество службы в целом. Механизм Redis Master/Slave: когда Master выходит из строя, Slave автоматически обновляется для обеспечения качества обслуживания.
Типичные сценарии использования:
Мемкэш:
- Хранилище сеансов: сервис сеансов для всего сайта, мобильный WAP-сеанс
- Мобильный MAPI-бизнес
Редис:
- счетная служба
- Служба очереди: очередь сообщений
- Данные списка сеансов (hashset, хранить все продукты в рамках определенного сеанса через hashset)
- Дедупликация коллекций: Redis, который используется PMS для отправки SMS, использует несколько коллекций для дедупликации, чтобы предотвратить получение одним и тем же пользователем нескольких SMS-сообщений, вызывающих домогательства.
Memcached
Преимущества Memcached
- Memcached может использовать преимущества многоядерности, а пропускная способность одного экземпляра чрезвычайно высока, что может достигать сотен тысяч запросов в секунду (в зависимости от размера байта ключа и значения и производительности оборудования сервера пиковый показатель запросов в секунду в ежедневной среде составляет около 4-6 Вт). Для максимальной грузоподъемности.
- Поддерживает прямую настройку в качестве дескриптора сеанса.
- Есть немного ям.
Ограничения Memcached:
- Поддерживаются только простые структуры данных «ключ-значение», в отличие от Redis, который может поддерживать расширенные типы данных.
- Его нельзя сохранить, резервное копирование данных невозможно, его можно использовать только для кэширования, и все данные теряются после перезапуска.
- Синхронизация данных не может быть выполнена, и данные в MC не могут быть перенесены в другие экземпляры MC.
- Распределение памяти Memcached использует механизм Slab Allocation для управления памятью.Если распределение размера значения сильно отличается, использование памяти будет уменьшено, и такие проблемы, как отбрасывание, все еще будут возникать при низком использовании. Пользователи должны обратить внимание на дизайн ценности.
Redis
Преимущества Редис:
- Поддержка различных структур данных, таких как string (строка), list (двухсвязный список), dict (хеш-таблица), set (набор), zset (набор сортировки), hyperloglog (оценка кардинальности)
- Он поддерживает постоянные операции и может сохранять данные aof и rdb на диск, чтобы выполнять такие операции, как резервное копирование или восстановление данных, что является лучшим средством предотвращения потери данных.
- Он поддерживает репликацию данных посредством репликации.Благодаря механизму ведущий-ведомый синхронная репликация данных может выполняться в режиме реального времени, а также поддерживаются многоуровневая репликация и инкрементная репликация.Механизм ведущий-ведомый является важным средством Redis для выполнения HA .
- Однопоточные запросы, все команды выполняются последовательно, и вопросы согласованности данных не нужно учитывать в случае параллелизма.
- Поддержка механизма подписки на сообщения pub/sub, который можно использовать для подписки на сообщения и уведомлений.
- Он поддерживает простые требования к транзакциям, но в отрасли существует несколько сценариев использования, и он не является зрелым.
Ограничения Redis:
- Redis может использовать только один поток, и его производительность ограничена производительностью ЦП, поэтому ЦП с одним экземпляром может достигать максимум 5-6wQPS в секунду (в зависимости от структуры данных, размера данных и производительности оборудования сервера пиковое значение QPS в повседневных условиях составляет примерно 1-2 ч).
- Он поддерживает простые требования к транзакциям, но в отрасли мало сценариев использования, и он незрелый, что является как преимуществом, так и недостатком.
- Redis потребляет много памяти для строкового типа.Вы можете использовать dict (хеш-таблицу) для сжатия и хранения, чтобы уменьшить потребление памяти.
Twemproxy
Преимущества распределенного решения Twemproxy:
- Простое распределенное решение, бизнес-стороне нужно использовать только одно сопоставление IP/PORT (онлайн-развертывание с использованием LVS+VIP+VPORT), а весь доступ к сегментированным данным осуществляется внутри через Twemproxy.
- И Redis, и Memcached могут использовать Twemproxy в качестве собственного распределенного решения.
- Поддержка различных алгоритмов хеширования, меньшая потеря производительности.
- Проблему низкой одноточечной производительности и высокой доступности на среднем уровне можно решить расширением Twemproxy (онлайн-бизнес обычно использует 5-10 Twemproxy, балансировку нагрузки и отказоустойчивость через LVS)
- Twemproxy поддерживает простую внутреннюю схему аварийного переключения хранилища.Например, если серверный экземпляр MC не работает, запросы, направляемые на MC, могут быть переданы другим экземплярам MC. Внутренняя настраиваемая версия Twemproxy в сочетании с кластером Sentinel поддерживает отказоустойчивость схемы Redis master-slave.Если мастер Redis выйдет из строя, запрос будет перенаправлен на подчиненный.
- Он может легко и удобно выполнять такие операции, как миграция и расширение серверных сервисов.Он больше не зависит от DNS или конфигурации сервиса.Все изменения конфигурации могут быть выполнены на LVS и Twemproxy, что прозрачно для сервисов и не требует заботиться о бизнесе, который удобен для эксплуатации и обслуживания.
Ограничения распределенной схемы Twemproxy:
- При использовании Redis в качестве серверного хранилища многие собственные запросы команд Redis будут ограничены, а сам Twemproxy не поддерживает это.
- Twemproxy является решением среднего уровня.Добавление уровня увеличит задержку сервисных запросов, а сам Twemproxy как промежуточный уровень может стать узким местом службы, таким как проблемы с процессором или трафиком.Конечно, это можно решить, добавив Twemproxy. экземпляры, но увеличение ответа Стоимость ввода сервера.
- Возрастает сложность развертывания службы, а также возрастают стоимость и сложность управления.Требуется быстрое и простое автоматизированное решение для развертывания службы и управления, а также возрастают требования к персоналу, занимающемуся эксплуатацией и обслуживанием.
- Распределенные мультиузлы среднего уровня Twemproxy нуждаются в поддержке LVS.Ограничения производительности самого LVS могут вызвать узкие места в обслуживании.Ранее уже существовала проблема потери пакетов сетевой карты LVS, и с тех пор была проведена крупномасштабная оптимизация и разделение.