分布式锁

分布式锁的由来、特点、及Redis分布式锁的实现详解

懵懂的女人 提交于 2019-12-07 16:56:24
什么是分布式锁 要介绍分布式锁,首先要提到与分布式锁相对应的是线程锁、进程锁。 1.线程锁 主要用来给方法、代码块加锁。当某个方法或代码使用锁,在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果,因为线程锁的实现在根本上是依靠线程之间共享内存实现的,比如Synchronized、Lock等。 2.进程锁 为了控制同一操作系统中多个进程访问某个共享资源,因为进程具有独立性,各个进程无法访问其他进程的资源,因此无法通过synchronized等线程锁实现进程锁。 3.分布式锁 当多个进程不在同一个系统中,用分布式锁控制多个进程对资源的访问。 分布式锁的由来 在传统单机部署的情况下,可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。 但是在分布式系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机并发控制锁策略失效,为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁的由来。 当多个进程不在同一个系统中,就需要用分布式锁控制多个进程对资源的访问。 分布式锁的特点 首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: **1、互斥性:**任意时刻,只能有一个客户端获取锁,不能同时有两个客户端获取到锁。 **2、安全性:*

C++基于redis的分布式锁

≡放荡痞女 提交于 2019-12-07 12:12:47
之前无意间看到了一下redis的分布式锁,都没有C++版本的,基本全是java的redission。 闲着没事就写了一个。 以前还以为是redis提供的分布式锁的服务,其实不然,只是redis提供了分布式锁的几个基本特性的服务。 1.是客户端持有锁有时间限制,redis对每个key都可以设置过期时间,所以就很方便去控制锁的过期。 2.redis有发布和订阅的服务, 这样任意一个客户端在解锁的时候就可以用过发布的方式去通知所有客户端可以抢锁了。 以下是一个简单的版本, 基本功能是有的,后面具体项目要用的完善。我用的时redisclient的这个库文件,这个库网络I/O用的asio,需要编译的时候需要boost。下载地址: https://download.csdn.net/download/lc_boyi/10845732 DistributeLock.h #ifndef __DISTRBUTELOCK_H_ #define __DISTRBUTELOCK_H_ #include <thread> #include <iostream> #include <windows.h> #include "boost/asio/io_service.hpp" #include "boost/asio/ip/address.hpp" #include "boost/function.hpp"

认识Redis与Redis的数据类型

我的未来我决定 提交于 2019-12-07 00:16:05
本文作为Redis的入门教程,旨在让大家对Redis有一个概念性和整体性的认识,并且可以快速上手,为深入Redis打下基础。 文章概要: Redis的介绍 Redis与其他数据库的对比 Redis与其他缓存实现对比 Redis的数据结构类型 Redis命令操作几种数据类型 Spring Data Redis操作几种数据类型 ZSET(有序集合)保证顺序 SET(集合)随机获取元素 目录 Redis的介绍 Redis与其他数据的对比 Redis与其他缓存实现对比 Redis的数据类型 Redis 5种数据类型概览 Redis命令操作5种数据类型 STRING命令 字符串操作 SETEX与SETNX 数字操作 批量操作 BIT操作 LIST命令 SET命令 HASH命令 ZSET命令 总结 相关链接 作者资源 参考资源 相关资源 charts books Redis的介绍 Redis是一种非关系型数据库(non-relational database, 简称nosql)。 Redis是一个远程内存数据库,Redis客户端可以通过TCP协议请求服务端。 Redis性能强劲,且支持持久化和复制,可以方便地存储和读取海量数据。 那么Redis到底有多快? Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求,你可以使用 redis

redis加锁的几种实现

巧了我就是萌 提交于 2019-12-06 16:23:19
redis加锁的几种实现 2017/09/21 1. redis加锁分类 redis能用的的加锁命令分表是 INCR 、 SETNX 、 SET 2. 第一种锁命令 INCR 这种加锁的思路是, key 不存在,那么 key 的值会先被初始化为 0 ,然后再执行 INCR 操作进行加一。 然后其它用户在执行 INCR 操作进行加一时,如果返回的数大于 1 ,说明这个锁正在被使用当中。 1、 客户端A请求服务器获取key的值为1表示获取了锁 2、 客户端B也去请求服务器获取key的值为2表示获取锁失败 3、 客户端A执行代码完成,删除锁 4、 客户端B在等待一段时间后在去请求的时候获取key的值为1表示获取锁成功 5、 客户端B执行代码完成,删除锁 $redis->incr($key); $redis->expire($key, $ttl); //设置生成时间为1秒 3. 第二种锁 SETNX 这种加锁的思路是,如果 key 不存在,将 key 设置为 value 如果 key 已存在,则 SETNX 不做任何动作 1、 客户端A请求服务器设置key的值,如果设置成功就表示加锁成功 2、 客户端B也去请求服务器设置key的值,如果返回失败,那么就代表加锁失败 3、 客户端A执行代码完成,删除锁 4、 客户端B在等待一段时间后在去请求设置key的值,设置成功 5、 客户端B执行代码完成

Redis 分布式锁

三世轮回 提交于 2019-12-06 12:19:56
众所周知,redis是一个高性能的分布式 key-value 存储系统,在NoSQL数据库市场上,redis自己就占据了将近半壁江山,足以见到其强大之处。同时,由于redis的单线程特性,我们可以将其用作为一个 消息队列 。本篇文章就来讲讲如何将redis整合到spring boot中,并用作消息队列的 (本人自己在线上使用后,感觉加分布式锁大大影响了效率,还没有单机效率高) 为什么会出现消息队列? 异步:常见的B/S架构下,客户端向服务器发送请求,但是服务器处理这个消息需要花费的时间很长的时间,如果客户端一直等待服务器处理完消息,会造成客户端的系统资源浪费;而使用消息队列后,服务器直接将消息推送到消息队列中,由专门的处理消息程序处理消息,这样客户端就不必花费大量时间等待服务器的响应了; 解耦:传统的软件开发模式,模块之间的调用是直接调用,这样的系统很不利于系统的扩展,同时,模块之间的相互调用,数据之间的共享问题也很大,每个模块都要时时刻刻考虑其他模块会不会挂了;使用消息队列以后,模块之间不直接调用,而是通过数据,且当某个模块挂了以后,数据仍旧会保存在消息队列中。最典型的就是 生产者-消费者 模式,本案例使用的就是该模式; 削峰填谷:某一时刻,系统的并发请求暴增,远远超过了系统的最大处理能力后,如果不做任何处理,系统会崩溃;使用消息队列以后,服务器把请求推送到消息队列中

分布式的优点、分布式锁及分布式事务处理机制

最后都变了- 提交于 2019-12-06 10:54:01
1、关于分布式锁的了解? 原理:控制分布式系统有序的去对共享资源进行操作,通过互斥来保持一致性。 具备的条件: ①分布式环境下,一个方法在同一时间只能被一个机器的一个线程执行 ②高可用的获取锁和释放锁 ③高性能的获取锁和释放锁 ④具备可重入特性 ⑤具备锁失效机制,防止死锁 分布式锁的三种实现: A. 基于数据库实现分布式锁; B. 基于缓存(Redis等)实现分布式锁; C. 基于Zookeeper实现分布式锁 A.基于数据库的实现: 在数据库中创建一个表,表中包含方法名等字段,并在方法名字段上创建唯一索引,想要执行某个方法,就是用这个方法名向表中插入数据,成功插入则获取锁,执行完成后删除对应的行数据释放锁 B.基于缓存(Redis等)实现分布式锁: 推荐: Redis有很高的性能; Redis命令对此支持较好,实现起来比较方便 实现: (1)获取锁的时候,使用setnx加锁,并使用expire 命令为锁添加一个超时时间,超过该时间则自动释放锁,锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。 (2)获取锁的时候设置一个获取的超时时间,若超过这个时间就放弃获取锁。 (3)释放锁的时候,通过UUID判断是不是该锁,若是该锁,就执行delete进行锁释放。 C.基于Zookeeper的实现方式 原因: Zookeeper是一个为分布式应用提供一致性服务的开源组件

终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够?

谁都会走 提交于 2019-12-06 10:20:01
终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够? 一只Tom猫4小时前 我要分享 之前有零零散散整理过一些专题给大家参考学习,这次一次性来个终极手撕之架构大全,包含开源框架、分布式、微服务、性能优化等四个大专题共17个小专题,全部一锅端,送给大家一起学习~ 注意:需要全部完整版架构大全答案的可以 【“点击我”免费领取】 《终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够?》 01 开源框架(Spring +SpringMVC+Mybatis) 开源框架答案解析如下: 1.1 手撕开源框架之Spring 什么是 Spring 框架?Spring 框架有哪些主要模块? 使用 Spring 框架能带来哪些好处? 什么是控制反转(IOC) 请解释下 Spring 框架中的 IoC BeanFactory 和 和 ApplicationContext 有什么区别? Spring 有几种配置方式? 如何用基于 XML 配置的方式配置 Spring 如何用基于 Java 配置的方式配置 Spring 怎样用注解的方式配置 Spring 请解释 Spring Bean 的生命周期? Spring Bean 的作用域之间有什么区别? Spring 框架中的单例 Beans 是线程安全的么? 请举例说明如何在 Spring 中注入一个 Java Collection

redis 缓存穿透、击穿、雪崩

我们两清 提交于 2019-12-06 08:44:50
缓存穿透: 大量查询 redis 中不存在的key(用随救数进行查询),导致每次都会去查询数据库,造成数据库压力过大(甚至宕机)。 解决办法: 1.对我们的 api 接口 进行限流处理、用户授权、黑名单和白名单进行拦截。 2.将不存在的 key 存到 redis 中并设置有效期,有效减轻短时间内重复 key 的查询。不推荐使用(一般随机数都是不相等的)。 3.布隆过滤器 介绍:它实际上是一个很长的 二进制 向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多,缺点是有一定的误识别率和删除困难。 缓存击穿: 在高并发的情况下,当一个缓存 key 过期时,因为访问该 key 请求较大,多个请求同时发现缓存过期,因此对多个请求同时数据库查询、同时向Redis写入缓存数据,这样会导致数据库的压力非常大; 1.使用分布式锁 保证在分布式情况下,使用分布式锁保证对于每个key同时只允许只有一个线程查询到后端服务,其他没有获取到锁的权限,只需要等待即可;这种高并发压力直接转移到分布式锁上,对分布式锁的压力非常大。 2.使用本地锁 使用本地锁与分布式锁机制一样,只不过分布式锁适应于服务集群、本地锁仅限于单个服务使用。 3.软过过期 设置热点数据永不过期或者异步延长过期时间; 4.布隆过滤器 缓存雪崩:

什么鬼,面试官竟然让我用Redis实现一个消息队列!!?

房东的猫 提交于 2019-12-06 07:48:49
GitHub 9.4k Star 的Java工程师成神之路 ,不来了解一下吗? GitHub 9.4k Star 的Java工程师成神之路 ,真的不来了解一下吗? GitHub 9.4k Star 的Java工程师成神之路 ,真的确定不来了解一下吗? 众所周知,redis是一个高性能的 key-value 数据库,在NoSQL数据库市场上,redis自己就占据了将近半壁江山,足以见到其强大之处。同时,由于redis的单线程特性,我们可以将其用作为一个 消息队列 。本篇文章就来讲讲如何将redis整合到spring boot中,并用作消息队列的…… 一、什么是消息队列 “消息队列”是在消息的传输过程中保存消息的容器。——《百度百科》 消息 我们可以理解为在计算机中或在整个计算机网络中传递的数据。 队列 是我们在学习数据结构的时候学习的基本数据结构之一,它具有先进先出的特性。 所以, 消息队列 就是一个保存消息的容器,它具有先进先出的特性。 为什么会出现消息队列? 异步:常见的B/S架构下,客户端向服务器发送请求,但是服务器处理这个消息需要花费的时间很长的时间,如果客户端一直等待服务器处理完消息,会造成客户端的系统资源浪费;而使用消息队列后,服务器直接将消息推送到消息队列中,由专门的处理消息程序处理消息,这样客户端就不必花费大量时间等待服务器的响应了; 解耦:传统的软件开发模式

分布式锁的解决方案

北战南征 提交于 2019-12-06 05:21:40
分布式锁的背景,基于数据库、redis、zookeeper实现分布式锁的原理与优缺点你都知道吗?   为什么要分布式锁、分布式锁的实现方式有哪几种、这几种分布式锁实现方式的优缺点有哪些?阅读完本文后你你应该掌握: 基于数据库实现分布式锁具体步骤是什么,优缺点是什么; 基于Redis实现分布式锁具体步骤是什么,优缺点是什么; 基于Zookeeper实现分布式锁具体步骤是什么,优缺点是什么; 分布式锁诞生的背景   我们在开发 单机应用 的时候,如果需要对某一个共享变量进行多线程同步访问的时候,可以使用我们学到的Java多线程的18般武艺进行处理,并且可以完美的运行,毫无Bug!   我们现在的应用程序如果只部署一台服务器,那并发量是很差的,如果同时有上万的请求那么很有可能造成服务器压力过大,而瘫痪。   想想双十一 和 三十晚上十点分支付宝红包等业务场景,自然需要用到多台服务器去同时处理这些业务,那么这些服务可能会有上百台同时处理,   但是请我们大家想一想,如果有100台服务器 要处理分红包的业务,现在假设有1亿的红包,1千万个人分,金额随机,那么这个业务场景下是不是必须确保这1千万个人最后分的红包金额总和等于1亿。   如果处理不好 每人分到100万,那马云爸爸估计大年初一,就得宣布破产了 分布式锁应该具备的条件   在分析分布式锁的三种实现方式之前