用户您好!请先登录!

分类目录缓存框架

Redis的高可用机制:哨兵和集群

我们在讨论分布式系统的时候,曾经谈过分布式系统要解决的是高并发、大数量和快速响应的问题。事实上,在互联网中,大部分的业务还是以查询数据为主,而非更改数据为主。在互联网出现高并发的时刻,查询关系数据库,会造成关系数据库的压力增大,容易导致系统宕机的严重后果。为了解决这个问题,一些开发者提出了数据缓存技术,数据缓存和关系数据库最大的不同在于,缓存的数据是保存在计算机内存上的,而关系数据库的数据主要保存在磁盘上。计算机检索内存的速度是远超过检索磁盘的,所以缓存技术可以在很大程度上提高整个系统的性能,降低数据库的压力。

使用缓存技术最大的问题是数据的一致性问题,缓存中存储的数据是关系数据库中数据的副本,因为缓存机制与数据库机制不同,所以它们的数据未必是同步的。虽然我们可以使用弱一致性去同步数据,但是现实很少会那么做,因为在互联网系统中,往往查询是可以允许部分数据不实时的,甚至是失真的,例如,一件商品的真实库存是100件,而现在显示是99件,这并不会妨碍用户继续购买。如果使用弱一致性,一方面会造成性能损失,另外一方面也会造成开发者工作量的大量增加。

阅读更多

Apache Ignite那点事

Ignite是什么?

Apache Ignite为开发人员提供了实时处理大数据和内存计算的方便易用的解决方案。主要有以下几点功能:

  1. Data grid 数据网格
  2. Compute grid 计算网格
  3. Service grid 服务网格
  4. Bigdata accelerator 大数据加数器
  5. Streaming grid 数据流网格

Apache Ignite核心技术特点如下:

  1. 开源
  2. 纯Java编写
  3. 基于Spring框架
  4. 支持.Net、C++和PHP语言

阅读更多

分布式缓存设计那点事

在高并发的分布式的系统中,缓存是必不可少的一部分。没有缓存对系统的加速和阻挡大量的请求直接落到系统的底层,系统是很难撑住高并发的冲击,所以分布式系统中缓存的设计是很重要的一环。下面就来聊聊分布式系统中关于缓存的设计以及过程中遇到的一些问题。

缓存的收益与成本

使用缓存我们得到以下收益:

  • 加速读写。因为缓存通常是全内存的,比如Redis、Memcache。对内存的直接读写会比传统的存储层如MySQL,性能好很多。举个例子:同等配置单机Redis QPS可轻松上万,MySQL则只有几千。加速读写之后,响应时间加快,相比之下系统的用户体验能得到更好的提升。
  • 降低后端的负载。缓存一些复杂计算或者耗时得出的结果可以降低后端系统对CPU、IO、线程这些资源的需求,让系统运行在一个相对资源健康的环境。

阅读更多

推荐:缓存使用的正确策略

响应时间长,遇到性能瓶颈时,开发者第一个想到的总是性能优化。《什么技能产品经理不会提,但技术人必须懂?》讲到了什么时候需要使用缓存。但缓存的用法是什么?一旦缓存使用不当,或稍有不注意,反而会翻车,导致系统投入更多的维护成本,陡增更高的复杂度。今天,科怀就来讲讲缓存的正确使用姿势。

1. 常见概念

在合理应用缓存前,需要了解缓存领域里相关的几个常用术语:

  • 缓存命中:表示数据能够从缓存中获取,不需要回源;
  • Cache miss:表示没有命中缓存,如果缓存内存中还有内存空间的话,会将数据加入到缓存中;
  • 存储成本:当没有命中缓存时,回源获取后会将数据放置到存储中,整个将数据放置到存储空间所需要的时间以及空间称之为存储成本;
  • 缓存失效:当源数据发生变更后,意味着缓存中的数据失效;
  • 缓存污染:将不经常访问的数据放置到缓存存储空间中,以至于高频访问的数据无法放置到缓存中;
  • 替代策略:当数据放置到缓存空间时,由于空间不足时,就需要从缓存空间中去除已有的数据,选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些:
    • Least-Recently-Used(LRU)
    • Least-Frequently-Used(LFU)
    • SIZE
    • First in First Out(FIFO)

阅读更多

Redis哨兵模式和高可用集群解析

Redis 的 主从复制 模式下,一旦 主节点 由于故障不能提供服务,需要手动将 从节点 晋升为 主节点,同时还要通知 客户端 更新 主节点地址,这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵机制 来解决这个问题。

1. Redis高可用概述

在 Web 服务器中,高可用 是指服务器可以 正常访问 的时间,衡量的标准是在 多长时间 内可以提供正常服务(99.9%、99.99%、99.999% 等等)。在 Redis 层面,高可用 的含义要宽泛一些,除了保证提供 正常服务(如 主从分离快速容灾技术 等),还需要考虑 数据容量扩展数据安全 等等。

阅读更多

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

一、缓存雪崩

缓存雪崩我们可以简单的理解为:由于原有缓存失效,新缓存未到期间(例如:我们设置缓存时采用了相同的过期时间,在同一时刻出现大面积的缓存过期),所有原本应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃。

缓存正常从Redis中获取,示意图如下:

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

阅读更多

常见的缓存策略(Common Caching Strategies)

我们都知道,提高系统性能的最简单也最流行的方法之一其实就是使用缓存。我们引入缓存,相当于对数据进行了复制。每当系统数据更新时,保持缓存和数据源(如 MySQL 数据库)同步至关重要,当然,这也取决于系统本身的要求,看系统是否允许一定的数据延迟。

这里分享几种最常见的缓存策略、它们的优缺点以及使用场景。

Cache-Aside 策略

Cache-Aside 可能是最常用的缓存策略。在这种策略下,应用程序(Application)会与缓存(Cache)和数据源(Data Source)进行通信,应用程序会在命中数据源之前先检查缓存。如下图所示:

一文带你搞懂“缓存策略”

我们来看一次请求数据的过程:

  • 首先,应用程序先确定数据是否保留在缓存中;
  • 如果数据在缓存中,也即 Cache hit ,称作“缓存命中”。数据直接从缓存中读取并返回给客户端应用程序;
  • 如果数据不在缓存中,也即 Cache miss,称作“缓存未命中”。应用程序会从数据存储的地方,如 MySQL 数据源中读取该数据,并将数据存储在缓存中,然后将其返回给客户端。

阅读更多

KeyDB: Low TCO Redis™ Compatible Key Value Store

What is KeyDB?

KeyDB is an in-memory, high performance database with support for numerous data types, on-disk persistence and high availability. Compatible with Redis™ API and protocols, KeyDB is a drop-in replacement for your existing Redis™ deployments with numerous enhancements, higher performance, and lower Total Cost of Ownership (TCO).

Designed for use as both a cache as well as use as a primary database, KeyDB is a fast and versatile NOSQL database useful in many applications. Its low resource requirements and high-speed mean fewer instances to manage and much lower costs. KeyDB looks to fully utilize the hardware provided to your instances enabling a higher throughput and efficiency.

阅读更多

缓存使用那点事

按照现在流行的互联网分层架构模型,最简单的架构当属Web响应层+DB存储层的架构。从最开始的单机混合部署Web和DB,到后来将二者拆分到不同物理机以避免共享机器硬件带来的性能瓶颈,再随着流量的增长,Web应用变为集群部署模式,而DB则衍生出主从机来保证高可用,同时便于实现读写分离。这一连串系统架构的升级,本质上是为了追求更高的性能,达到更低的延时。

本文将提及的缓存技术则是提升性能的另一把利刃。然而任何技术都是有可为有可不为,没有最好的技术只有最适合的技术,因此在使用缓存之前,我们也需要了解下引入缓存模块所带来的好处和坏处。

缘起:为何使用缓存

在应用对外提供服务时,其稳定性受到诸多因素影响,其中比较重要的有CPU、内存、IO(磁盘IO、网络IO)等,这些硬件资源十分宝贵,因此对于那些需要经过复杂计算才能得到结果的,或者需要频繁读取磁盘数据的,最好将结果缓存起来,避免资源的重复消耗。

CPU瓶颈

如果项目中有很多正则表达式计算,或者某个计算结果是多次中间结果合并后才得出的,且CPU的使用率一直居高不下,那么就可以考虑是否应该将这些结果缓存起来,根据特定Key直接获取Value结果,减少中间链路的传递过程,减少CPU的使用率。

阅读更多