分布式锁

此文仅入门，需要扩展挖深，自行钻研 缓存-redis 数据库-mysql 1. 缓存 什么是缓存？ 定义 缓存是系统快速响应的一种关键性技术，是一组被保存起来以备将来使用的东西，介于应用开发和系统开发之间，是产品经理们经常顾及不到的地方，也是技术架构设计的非功能性约束。 分类 按软件系统所处的位置不同分类 客户端缓存 服务端缓存 网络中的缓存 按规模和部署方式分类： 单体缓存 缓存集群 分布式缓存 为什么要用缓存？ 为什么要用缓存，我们这里仅从软件开发层面来分析，首先你必须了解关于系统的性能的一些指标。 系统的性能的指标一般包括： 响应时间：系统对用户的请求作出的响应时间，它完整的记录了整个系统处理请求的时间。 延迟时间：一般指系统处理完请求后，由于网络传输到用户之间的网络延迟时间。 吞吐量：指单位时间内系统处理请求的数量。无并发的系统中，它与响应时间成反比。 并发用户数：指系统能够同时承载的正常使用系统功能的用户数量，它比 吞吐量更能直观的反应系统的性能 资源利用率：反映的是一段时间内资源平均被占用的情况 系统的性能，反映在从浏览器到网络，再到服务器，甚至数据库等各个应用层面。而在各个层面使用缓存将大大提升整个系统的性能。 缓存离客户端越近，响应时间则越快；缓存离数据库越近，则响应时间越长。 缓存是一种用空间换时间的概念。 如果带宽收费(流量付费)，那么缓存就是变相的省钱利器。

redis结构: String,Hash,List,Set,Zet 持久化: RDB 快照形式 AOF 追加 1,redis既然是单线程的,为啥处理速度很快 redis每秒处理100000+的QPS,基于内存操作,只是我们在处理网络请求的时候,是单线程处理,redis Server在运行的时候肯定不止一个线程,单线程省去了很多上下文切换的时间,redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。 2.分布式锁 加锁使用setnx(); key可以为当前线程id,value随便,当执行完后返回1,表明没有加锁,可以使用,当返回0的时候,表明当key已经存在,加锁失败,解锁的话del(key), 锁超时:当线程获取锁之后,挂掉了,那么锁就无法释放,这个时候需要设置expire()超时时间,保证到期释放锁 问题一: setnx 和expire操作非原子性,解决:redis高版本有set()方法设置超时时间 问题二: 线程执行时间太长,超时时间过了,其他线程获取锁执行,redis误删其他的锁,解决:删除锁时校验是否为当前线程 校验和删除非原子性操作,可以通过LUA脚本来操作, String luaS

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中， Java 中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的 Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。 针对分布式锁的实现，目前比较常用的有以下几种方案： 基于 数据库 实现分布式锁 基于缓存（ Redis ，memcached，tair）实现分布式锁 基于Zookeeper实现分布式锁 在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理） 可以保证在分布式部署的应用集群中

一、什么是 Redis? Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库,可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。 与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。 Redis 是完全开源免费的，遵守 BSD 协议，是一个高性能的 key-value 数据库。 二、Redis 与其他 key - value 缓存产品有以下三个特点： （1）Redis 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 （2）Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。 （3）Redis 支持数据的备份，即 master-slave 模式的数据备份。 三、Redis有哪些优缺点 优点 （1）性能极高 – Redis 能读的速度是

一 Redis使用bitset(bitmap)来统计日活跃量 1 BitMap介绍 　　Bitmap(即Bitset)，是一串连续的2进制数字（0或1），每一位所在的位置为偏移(offset)，bitmap就是通过最小的单位bit来进行0或者1的设置，表示某个元素对应的值或者状态。 　　Redis从2.2.0版本开始新增了 setbit , getbit , bitcount 等几个bitmap相关命令。虽然是新命令，但是并没有新增新的数据类型，因为 setbit 等命令只不过是在 set 上的扩展。在bitmap上可执行AND,OR,XOR以及其它位操作。 2 相关命令 　　（1）SETBIT key offset value 　　对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。位的设置或清除取决于 value 参数，可以是 0 也可以是 1 。当 key 不存在时，自动生成一个新的字符串值。 　　字符串会进行伸展(grown)以确保它可以将 value 保存在指定的偏移量上。当字符串值进行伸展时，空白位置以 0 填充。 　　offset 参数必须大于或等于 0 ，小于 2^32 (bit 映射被限制在 512 MB 之内)。 　　 对使用大的 offset 的 SETBIT 操作来说，内存分配可能造成 Redis 服务器被阻塞。 　　redis>

前言 分布式锁一般有三种实现方式： 数据库 乐观锁；2. 基于 Redis 的分布式锁；3. 基于ZooKeeper的分布式锁。 本篇博客将介绍第二种方式，基于Redis实现分布式锁。 虽然网上已经有各种介绍Redis分布式锁实现的博客，然而他们的实现却有着各种各样的问题，为了避免误人子弟，本篇博客将详细介绍如何正确地实现Redis分布式锁。 可靠性 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件： 互斥性： 在任意时刻，只有一个客户端能持有锁。 不会发生死锁： 即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 具有容错性： 只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。 解铃还须系铃人： 加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。 代码实现 一、引入redis 依赖 <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.9.0</version> </dependency> 备注：根据版本不同，jedis 的set 方法也有所不同 二、配置文件增加redis 配置 # redis.properties 配置文件： # region Redis jedis #

先来说说什么是分布式锁，简单来说，分布式锁就是在分布式并发场景中，能够实现多节点的代码同步的一种机制。从实现角度来看，主要有两种方式：基于redis的方式和基于zookeeper的方式，下面分别简单介绍下这两种方式： 请尊重作者劳动成果，转载请标明原文链接： https://www.cnblogs.com/jpcflyer/p/9142813.html 一、基于redis的分布式锁实现 1.获取锁 redis是一种key-value形式的NOSQL数据库，常用于作服务器的缓存。从redis v2.6.12开始，set命令开始变成如下格式： SET key value [EX seconds] [PX milliseconds] [NX|XX] 除key和value外，EX是超时时间，NX表示只有在key不存在的时候才会设置key的值，而XX表示在key存在的时间才会设置key的值。NX机制就是基于redis分布式锁的核心。能够解决以下问题： 1）节点1获取key，并且设置超时时间后，还没来得及释放就挂掉了——这里EX超时时间会发挥作用，超时后自动释放锁。 2）刚获取到锁，还没来得及设置超时时间就挂了——这里设置key和设置超时时间是原子操作，如果出现这种情况，会返回0，即获取不到锁。 2.释放锁 为了解决非原子操作带来的问题，常采用lua脚本实现。lua脚本的操作会被认为是原子性的

一、pom依赖 <dependency> <groupId>tf56.redis</groupId> <artifactId>redis-client</artifactId> <version>1.0.0</version> <exclusions> <exclusion> <artifactId>servlet-api</artifactId> <groupId>javax.servlet</groupId> </exclusion> <exclusion> <artifactId>gson</artifactId> <groupId>com.google.code.gson</groupId> </exclusion> </exclusions> </dependency> <!-- 其他redis依赖 --> 二、MyCacheCloudRedisFactory工具类 package tf56.payOnlineService.util.redis; ​ import com.sohu.tv.builder.ClientBuilder; import com.sohu.tv.cachecloud.client.basic.enums.RedisTypeEnum; ​ import org.apache.commons.lang.StringUtils; import org

第一、分布式锁解决方案 分布式锁一般有三种实现方式 1.数据库乐观锁 采用数据库 不建议 性能不好 jdbc 2.基于redis分布式锁 基于Redis实现分布式锁（setnx）setnx也可以存入key，如果存入key成功返回1，如果存入的key已经存在了，返回0. 多个客户端(jvm),使用setnx命令方式,同时在redis上创建相关的一个key，因为redis key不能够允许重复的看，只有谁能够创建key成功，谁就能够获取到锁，没有创建key成功jvm，就会等待。 3. 基于ZooKeeper的分布式锁 基于Zookeeper实现分布式锁 Zookeeper是一个分布式协调工具，在分布式解决方案中, 多个客户端（jvm），同时在zk上创建相同的一个临时节点，因为临时节点路径是保证唯一， 只要谁能够创建节点成功，谁就能够获取到锁，没有创建成功节点，就会进行等待，当释放锁的时候，采用事件通知给客户端重新获取锁的资源。 最终核心思路，保证只能够有一个jvm进行做操作 第二、分析Redis实现分布式锁 多个客户端(jvm),使用setnx命令方式，同时在redis上创建相同的一个key，因为redis key不会允许重复的，只要能够创建key成功，谁就能够获取到锁，没有创建key成功jvm，就会进行等待。 如何释放锁？ 在执行操作的时候，删除对应的key

分布式环境下多个操作以原子的方式执行 单体操作可以加锁synchronized{ } 如果是分布式的环境 前端niginx部署多个端口，会有bug redis中文手册api setnx 将key的值设为values，当key不存在时，如果给定的key已经存在，则setnx不做任何动作 进入时setkey值， 处理逻辑， 结束时删除key值， 这样在处理逻辑时如果发生异常，直接凉凉，key值一直不会被删除 所以加异常吹trycatch 但是服务在处理逻辑时挂了怎么办， 加redis超时时间，保证原子性 然后多个服务配置不同的唯一id，保证锁唯一 集大成者直接用redission框架 lock 来源： CSDN 作者： 谁还不是个孩子 链接： https://blog.csdn.net/weixin_43991917/article/details/103596317