redis分布式事务（redis分布式事务锁面试题）

本篇文章给大家谈谈redis分布式事务，以及redis分布式事务锁面试题对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis分布式锁 模拟秒杀业务
• 2、缓存击穿、穿透、雪崩及Redis分布式锁
• 3、什么是Redis?
• 4、Redis怎么实现分布式锁
• 5、finally里的redis锁释放了为什么事务还没有提交

Redis分布式锁 模拟秒杀业务

并发测试工具 JMeter

tips ： sychronized 加在静态方法上，表示sychronized(类.class){} 。加唤基消在非静态方法上等同于对整个方法体使用sychroniced(this){}。

为什么会出现锁不住的情况呢，还是有多扣的情况。这是因为我们使用了 @Transactional 注解加入了事务控制。Spring的事务控制是通过AOP实现的，在业务开始前后会添加/提交事务。流程大概如下：

引入事务控锋笑制管理类。

这样也是可以实现单机 并发控制的。

上面的例子说明 synchronize 关键字是可以解决并发问题的。但是这种方和知式会有很大的缺陷：

为了解决上面的问题，就引入了分布式锁的概念。

一个简单的 nginx 配置请求分发

[img]

缓存击穿、穿透、雪崩及Redis分布式锁

分布式锁: setnx ,redisson 并发问题

幂等问题: 落表状态,Redis

缓存击穿: 指缓存中无,db中有

原因: 一个key高并发恰好失效导致大量请求到db

方案: 加锁,自旋锁,或一个线程查芹乎db,一个线程监控(直接用Redisson分布式锁)

缓存穿透:指缓存和db中均无

原因: 一般是恶意请求

方案: 加布隆过滤,或查db无时,也设置缓存,value为某些特殊表示或"null"

雪崩:指缓存同时大量失效

原因: 大量的key同时失效,db压力加大

方案: 设置失效时间是增加随机数

问题方案文献:

(图例洞首简分析)

Redis分布式锁:

事务未执行完锁已到期释放问题：使用Redissoin解决续租问题，内部已解决

分布式锁文献:

(setnx + expire同时操作)

====================================

Redis原理与应纳裤用

什么是Redis?

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统

Redis是一个开源的使用ANSIC语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API

它通常被称为数据结构服务器，因为值(value)可以是 字符串(String), 哈希(Map), 列表斗信(list), 集合(sets)和有序集合(sorted sets)等类型

Redis 简介

Redis是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库

Redis与其他key - value缓存产品有以下三个特点：

①Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

②Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

③Redis支持数据的备份，即master-slave模式的数据备份。

Redis 的特点

高性能：Redis 将所有数据集存储在内存中，可以在入门级 Linux 机器中每秒写(SET)11 万次，读(GET)8.1 万次

持久化：当所有数据都存在于内存中时，可以根据自上次保存以来经过的时间和/或更新次数，使用灵活的策略将更改异步保存在磁盘上

数据结构：Redis 支持各种类型的数据结构，例如字符串、散列、集合、列表、带有范围查询的有序集、位图、超级日志和带有半径查询的地理空间索引

原子操作：处理不同数据类型的 Redis 操作是原子操作，因此可以安全地 SET 或 INCR 键，添加和删除集合中的元素等

支持的语言：Redis 支持许多语言，如C、C++、Erlang、Go、Haskell、滑燃Java、JavaScript(Node.js)、Lua、Objective-C、Perl、PHP、Python、R、Ruby、Rust、Scala、Smalltalk等

主/从复制：Redis 遵循非常简单快速的主/从复制。配置文件中只需要一行来设置它，而 Slave 在 Amazon EC2 实例上完成 10 MM

key 集的初始同步只需要 21 秒

分片：Redis 支持分片。与其他键值存储一样，跨多个 Redis 实例分发数据集非常容易

可移植：Redis 是用 C 编写的，信销虚适用于大多数 POSIX 系统，如 Linux、BSD、Mac OS X、Solaris 等

Redis怎么实现分布式锁

阿粉最近迷上了 Redis，为什么呢？感觉 Redis 确实功能很强大呀，一个基于内存的系统 Key-Value 存储的数据库，竟然有这么多的功能，而阿粉也要实实在在地把 Redis 来弄一下，毕竟面试的时候，Redis 可以说是一个非常不错的加分项。

为什么需要分布式锁？

目前很多的大型项目全部都是基于分布式的，而分布式场景中的数据一致性问题一直是一个不可忽视的问题，大家知道关于分布式的 CAP 理论么？

CAP 理论就是说任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。

而我们的系统最终满足的永远都是最终一致性，而这种最终一致性，有些时候有人会喜欢问关于分布式事务，而有些人则偏重在分布式锁上。

但是阿粉选择的就是使用缓存来实现分布式锁，也就是我们在项目中最经常使用的 Redis ，谈到 Redis，那真是可以用在太多地方了，比如说：

我们今天就来实现用 Redis 来实现分布式锁，并且要学会怎么使用。

1.准备使用 Jedis 的 jar 包，在项目中导入 jar 包。

jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); 这个加锁的姿势才是我们最需要了解的，不然你用的时候都不知道怎么使用。

key：加锁的键，实际上就是相当于一个唯一的标志位，不同的业务，你可以使用不同的标志位进行知者加锁。

requestId：这个东西实际上就是用来标识他是哪一个请求进行的加锁，因为在分布式锁中，我们要知道一件事，就是加锁的和解锁的，必须是同一个客户端才可以。

而且还有一种比较经典的就是 B 把 A 的锁给释放了，导致释放混乱，如果你不加相同的请求，A 线程处理业务，执行了加锁，锁的过期时间是5s, B线程尝试获取锁，如果 A 处理业务时间超过5s，这时候 A 就要开始释放锁，而B在这时候没有检测到这个锁，从而进行了加锁，这时候加锁的时候，A还没处理完对应业务，当他处理完了之后，再释放锁的话，要是就是直接把 B 刚加的锁释放了，要么就是压根都没办法释放锁。

SET_IF_NOT_EXIST：看字面意思，如果 key 不存在，我们进行Set操作，如果存在，啥都不干，也就不在进行加锁。

SET_WITH_EXPIRE_TIME：是否过期

expireTime：这是给 key 设置一个过期的时间，万一你这业务旦漏一直被锁着了，然后之后的业务想加锁，你直接给一直持有这个这个锁，不进行过期之后的释放，那岂不是要凉了。

上面的方法中 tryGetDistributedLock 这个方法也就是我们通常使用的加锁的方法。

大家看到这个 script 的时候，会感觉有点奇怪，实际上他就是一个 Lua 的脚本，而 Lua 脚本的意思也比较简单。

其实这时候就有些人说，直接 del 删除不行么？你试试你如果这么写的话，你们的领导会不会把你的腿给你打断。

这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，也就是说，这锁就算不是我加的，我都能开，这怎么能行呢？

在这里给大家放一段使用的代码，比较简单,但是可以直接用到你们的项目当中

我们先把这个实现方式实现了，然后我们再来说说大家最不愿意看的理论知识，毕竟这理论知识是你面试的时候经常会被问到的。

分布式CAP理论：

加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。

也就是说，在二十年前的时候，CAP 理论只是个猜想。结果两年之后被证实了，于是，大家在考虑分布式模猛烂的时候，就有根据来想了，不再是空想了。

什么是分布式的 CAP 理论 ？

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项

这个和(Atomicity)不太一样，因为之前看有些人说，在 CAP 理论中的 A 和数据库事务中的 A 是一样的，单词都不一样，那能一样么？

Availability ：分布式中的 A 表示的是可用性，也就是说服务一直可用，而且是正常响应时间。

而你在搭建分布式系统的时候，要保证每个节点都是稳定的，不然你的可用性就没有得到相对应的保证，也谈不上是什么分布式了。只能称之为一个伪分布式。

Consistency： 一致性

也就是说你的更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，这个如果你在使用 Redis 做数据展示的时候，很多面试官都会问你，那你们是怎么保证数据库和缓存的一致性的呢？

毕竟你只是读取的话，没什么问题，但是设计到更新的时候，不管是先写数据库，再删除缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。

所以如果你对这个很感兴趣，可以研究一下，比如说：

如果你能在面试的时候把这些都给面试官说清楚，至少感觉你应该能达到你自己的工资要求。

Partition tolerance:分区容错性

分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

其实在 CAP 理论当中，我们是没有办法同时满足一致性、可用性和分区容错性这三个特性，所以有所取舍就可以了。

关于使用 Redis 分布式锁，大家学会了么？

finally里的redis锁释放了为什么事务还没有提交

原因： 在事务中使用redis分布式锁，方法一旦执行事务生效，接着是redis分布式锁生效，代码执行完后释放redis分布式锁、然后提交事务数据，最后事务结束卜毕。在这个过程中事务没有提交之前分布式锁已经被释放，导致分布式锁失效

解决：旦弊坦在调用事务方法之前先加分布式锁

@Transactional

public void update(int id) {

boolean lock = redisLock.lock(id);

if (!lock) {

throw new RuntimeException(“当前人数过多，请稍后再试”);

}

/*

业务代码在该区域

*/

redisLock.unlock(id);

}

在上面的模桐代码中，我们同时使用了@transactional和redis分布式锁(其他锁同理，比如synchronized同步锁也会出现这个问题)

关于redis分布式事务和redis分布式事务锁面试题的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。