Последние четыре сценария последовательной базы данных
Что такое кэш
Скорость кэша отличается. Результатом является кэш-памятью низкой скорости, данные временно сохраняются в памяти на высокой скорости.
. Как показано на рисунке пирамиды больше памяти выше, следующий может быть использован в качестве кэш - памяти.
Мы в этой дискуссии, в основном для сценариев кэширования баз данных, как будет REDIS MySQL кеш для случая , чтобы быть.
Почему нам нужно кэшировать
Как обычно MySQL для хранения полностью поддерживает свойства ACID, из-за надежности, долговечности и других факторов. Производительность, как правило, не высокие, высокие параллельные запросы MySQL принесет давление, система баз данных нестабильности, а также склонны к задержкам.
В соответствии с принципом локальности, 80% до 20% от запроса горячих данных, чтения и записи меньше сценария, буферный слой увеличивается помощь, чтобы улучшить пропускную способность и надежность системы.
Существует проблема
Хранение данных может происходить с течением времени, и данные в кэше будут несовместимыми частность может терпеть время непоследовательности, конкретные бизнес анализа потребностей, но обычное дело, мы должны достичь окончательного соглашения.
Redis как кэш MySQL
Обычная модель развития, будет использовать MySQL в качестве кэш-памяти, и Redis в качестве кэш-памяти для ускорения и защиты MySQL. Тем не менее, когда MySQL обновление данных, Redis, как синхронизировать.
Сильная стоимость синхронизации консистенции слишком высока, если стремление к сильной консистенции, то нет необходимости использовать кэш, прямое использование MySQL обычно можно рассматривать является конечной последовательностью.
Решения
Вариант первый
По ключевому истечению времени, когда обновление MySQL, Redis не обновляется.
Таким образом, простого, но противоречивое очень долгое время. Если запрос на чтение очень часто, и истек в течение длительного времени, он будет производить много долгосрочных грязные данные.
Преимущества:
* 开发成本低,易于实现;
* 管理成本低,出问题概率会比较小.Недостатки:
* 完全依赖过期时间,时间太短容易缓存频繁失效,太长容易有长时间更新延迟(不一致).Вариант II
В одном варианте осуществления на основе расширения, через запасной срок действия ключа, и, при обновлении MySQL, при обновлении Redis.
Преимущества:
* 相对方案一,更新延迟更小Недостатки:
* 如果更新mysql成功,更新redis却失败,就退化到了方案一;
* 在高并发场景,业务server需要和mysql,redis同时进行连接.这样需要损耗双倍的连接资源,容易造成连接数过多的问题.Вариант третий
Redis выполняется для синхронной оптимизации записи программы два, увеличение очереди сообщений, обновление REDIS Кафки, обеспечить надежность очереди сообщений, а затем настроить службу потребителя асинхронно обновить Redis.
Преимущества:
* 消息队列可以用一个句柄,很多消息队列客户端还支持本地缓存发送,有效解决了方案二的连接过多问题;
* 使用消息队列,实现了逻辑上的解耦;
* 消息队列本身具有可靠性,通过手动提交等手段.可以至少一次消费到redis.Недостатки:
* 依旧解决不了时序性问题,如果多台业务服务器分别处理针对同一行数据的两条请求,举个例子,a=1;a=5;如果mysql中十第一条先执行,而进入kafka的顺序是第二条先执行,那么数据就会产生不一致.
* 引入了消息队列,同时要增加服务消费消息,成本较高,还有重复消费的风险.Вариант IV
Обновлено подписавшись Двоичным Redis, строить наши потребительские услуги, как ведомый MySQL, подписные Двоичный, разобрать из обновлений, а затем обновить до Redis.
Преимущества:
* 在mysql压力不大的情况下,延迟较低;
* 和业务完全解耦
* 解决了时序问题Недостатки:
* 要单独搭建一个同步服务,并且引入binlog同步机制,成本较大.резюме
программа подбора
Сначала убедитесь, что отсроченные требования к продукту, если задержка чрезвычайно требовательна, и данные могут измениться, не использовать кэш.
В целом, программа 1 достаточно, так как схема кэш обычно может прочитать написать небольшую сцену, в то время как бизнес имеет определенную с учетом задержки. Во-первых, нет затрат на разработку программы, на самом деле, более практичным.
Когда Своевременность Если вы хотите увеличить обновление, выберите вариант II, но не нужно делать, чтобы повторить подобное.
Сценарии 3 и 4 являются для задержки с требованием бизнеса, нажимная модель, режим тяги, в то время как опция IV с повышенной надежностью, так как много усилий готовы сделать логическую обработку сообщения, а не один шаг, с Сценарий 4.
В целом, достаточная программа.