分布式缓存

1.Redis 缓存和 MySQL 数据如何实现一致性 需求起因 缓存和数据库一致性解决方案 　　在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。 　　读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。 　　不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。 　　举一个例子： 1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。 2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况 。 　　因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 　　如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。 缓存和数据库一致性解决方案 1.第一种方案：采用延时双删策略 　　在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。 伪代码如下 public void write(String key,Object data){ redis

概述 互联网应用发展到今天，从单体应用架构到SOA以及今天的微服务，随着微服务化的不断升级进化，服务和服务之间的稳定性变得越来越重要，分布式系统之所以复杂，主要原因是分布式系统需要考虑到网络的延时和不可靠，微服务很重要的一个特质就是需要保证服务幂等，保证幂等性很重要的前提需要分布式锁控制并发，同时缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 随着业务不断的发展，按业务域的划分子系统越来越多，每个业务系统都需要缓存、限流、分布式锁、幂等工具组件，distributed-tools组件(暂未开源)正式包含了上述分布式系统所需要的基础功能组件。 distributed-tools组件基于tair、redis分别提供了2个springboot starter，使用起来非常简单。 以使用缓存使用redis为例，application.properties添加如下配置 redis.extend.hostName=127.0.0.1 redis.extend.port=6379 redis.extend.password=pwdcode redis.extend.timeout=10000 redis.idempotent.enabled=true 接下来的篇幅，重点会介绍一下缓存、限流、分布式锁、幂等的使用方式。 缓存 缓存的使用可以说无处不在，从应用请求的访问路径来看，用户user

课程主讲： 互联网应用高级架构师 白贺翔 涉及技术： Redis 、 SSDB 、 Memcached 课程描述： 介绍互联网 分布式 技术的重要性、背景、应用范围；目前互联网行业使用分布 式缓存进行设计的比例，以及大型网站使用的方式和方法，讲解分布式 缓存技 术 、数据类型、实战应用场景、缓存库主从同步、读写分离、高并发、安全性、 事务特性、分布式锁、负载均衡、 Session 共享、发布订阅、数据持久化、哨兵、 高可用、可扩展性、水平垂直扩容、集群环境搭建与应用等。 课程目录 01_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第一节 02_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第二节 03_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第三节 04_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第四节 05_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第五节 06_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第六节 07_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第七节 08_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第八节 09_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第九节 教程下载地址： 互联网分布式缓存技术 本文来自 >> 尚学堂 ； 转载请注明

http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴，点击访问该目录可获取更多内容。 首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后

开源git地址: http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache 分布式缓存中间件 方便实现缓存的分布式，集群，负载均衡，故障自动转移，并兼容多种缓存存储的分布式缓存中间件。 用于解决 分布式架构 中的分布式缓存环节。 特点 ： 1. 代码少，便于扩展。 2. 兼容阿里云memcache，redis，ssdb。 3. 规范缓存使用接口，屏蔽底层缓存实现。 4. 通过配置连接字符串即可切换不同存储引擎，可以混合不同存储引擎组成缓存集群部署。（如部分redis，部分memcache） 5. 动态负载均衡，故障转移，线上无缝平行扩展和扩容，方便运维。 不同存储介质 /// <summary> /// Redis /// 数据存内存,适合内存大小范围内大量缓存。（若是频繁失效的缓存数据，大量热点数据，建议使用redis） /// </summary> Redis, /// <summary> /// SSDB /// 数据热点存内存，大量数据存磁盘。（若是命中率较低，命中热点数据，大量冷数据，建议使用ssdb） /// </summary> SSDB, /// <summary> /// Memcached /// </summary> Memcached, /// <summary> ///

转自： https://www.cnblogs.com/rjzheng/p/9096228.html 引言 为什么写这篇文章? 博主的 《分布式之消息队列复习精讲》 得到了大家的好评，内心诚惶诚恐，想着再出一篇关于复习精讲的文章。但是还是要说明一下，复习精讲的文章偏面试准备，真正在开发过程中，还是脚踏实地，一步一个脚印，不要投机取巧。 考虑到绝大部分写业务的程序员，在实际开发中使用redis的时候，只会setvalue和getvalue两个操作，对redis整体缺乏一个认知。又恰逢博主某个同事下周要去培训redis，所以博主斗胆以redis为题材，对redis常见问题做一个总结，希望能够弥补大家的知识盲点。 复习要点? 本文围绕以下几点进行阐述 1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析 :博主觉得在项目中使用redis，主要是从两个角度去考虑: 性能 和 并发 。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等

转自： https://www.cnblogs.com/rjzheng/p/9041659.html 引言 为什么写这篇文章？ 首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。 但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。目前没有一篇全面的博客，对这几种方案进行解析。于是博主战战兢兢，顶着被大家喷的风险，写了这篇文章。 文章结构 本文由以下三个部分组成 1、讲解缓存更新策略 2、对每种策略进行缺点分析 3、针对缺点给出改进方案 正文 先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。因此，接下来讨论的思路不依赖于给缓存设置过期时间这个方案。 在这里，我们讨论 三种 更新策略： 先更新数据库，再更新缓存 先删除缓存，再更新数据库 先更新数据库，再删除缓存 应该没人问我，为什么没有先更新缓存，再更新数据库这种策略。 (1)先更新数据库，再更新缓存 这套方案，大家是普遍反对的。为什么呢

一 什么是事务？有什么用？ 事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。 2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。 3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的 事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。 4）持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变 就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 二 事务的并发会产生的问题有哪些 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 一个事务多次读取同一个数据，在该事务还未结束时，另一个事务也对该数据进行 了操作，而且在第一个事务两次读取之间，第二个事务对数据进行了更新，那么第一个

前言 缓存系统的用来代替直接访问数据库，用来提升系统性能，减小数据库负载。早期缓存跟系统在一个虚拟机里，这样内存访问，速度最快。 后来应用系统水平扩展，缓存作为一个独立系统存在，如redis，但是每次从缓存获取数据，都还是要通过网络访问才能获取，效率相对于早先从内存里获取，还是不够逆天快。如果一个应用，比如传统的企业应用，一次页面显示，要访问数次redis，那效果就不是特别好，性能不够快不说，还容易使得Reids负载过高，Redis的主机出现各种物理故障。因此，现在有人提出了一二级缓存。即一级缓存跟系统在一个虚拟机内，这样速度最快。二级缓存位于redis里，当一级缓存没有数据的时候，再从redis里获取，并同步到一级缓存里。这跟CPU的一级缓存，二级缓存是一个道理。当然也面对同样的问题。 缓存概念 Cache 通常有如下组件构成 CacheManager：用来创建，管理，管理多个命名唯一的Cache。如可以有组织机构缓存，菜单项的缓存，菜单树的缓存等 Cache：类似Map那样的Key—Value存储结构，Value部分 通常包含了缓存的对象，通过Key来取得缓存对象 缓存项：存放在缓存里的对象，常常需要实现序列化接口，以支持分布式缓存。 Cache存储方式：缓存组件的可以将对象放到内存，也可以是其他缓存服务器，Spring Boot 提供了一个基于ConcurrentMap的缓存

作者：孤独烟 来自：http://rjzheng.cnblogs.com/ 为什么要用redis ：为了并发和性能，使用redis做为缓冲 使用redis有什么缺点 主要是四个问题 (һ) 缓存和数据库双写一致性问题 分析：一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。 另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。 回答：首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。 (二) 缓存雪崩问题 解决方案 : (一)给缓存的失效时间，加上一个随机值，避免集体失效。 (二)使用互斥锁，但是该方案吞吐量明显下降了。 (三)双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点 I 从缓存A读数据库，有则直接返回 II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。 III 更新线程同时更新缓存A和缓存B。 (三) 缓存击穿问题 解决方案： (一)利用互斥锁，缓存失效的时候，先去获得锁