分布式锁

年 月 日 时 分 秒 序号 案例 订单产生的类 public class OrderNumber { private static Integer number=0; //生成订单号 public String getNumber(){ SimpleDateFormat sdf=new SimpleDateFormat("yyyy-MM-dd-HH-mm-ss"); ++number; return sdf.format(new Date())+"\t"+number; } } 订单业务处理类 public class OrderService implements Runnable{ private static OrderNumber orderNumber=new OrderNumber(); private Lock lock=new ZkLockImpl(); //生成订单 public void getOrderNumber(){ //同步代码块：多个线程访问同一个资源时 /*synchronized (orderNumber){ }*/ //获取锁 lock.getLock(); System.out.println("当前生成的订单编号为："+orderNumber.getNumber()); //释放锁 lock.unLock(); } @Override

概述 互联网应用发展到今天，从单体应用架构到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

摘要 分布式锁在很多应用场景下是非常有效的手段，比如当运行在多个机器上的不同进程需要访问同一个竞争资源的时候，那么就会涉及到进程对资源的加锁和释放，这样才能保证数据的安全访问。分布式锁实现的方案有很多，比如基于ZooKeeper实现、或者基于Mysql实现等等，今天我们来一起看看如何基于Redis实现分布式锁服务。 分布式锁要点 对于分布式锁的目标，我们必须首先明确三点： 任何一个时间点必须只能够有一个客户端拥有锁。 不能够有死锁，也就是最终客户端都能够获得锁，尽管可能会经历失败。 错误容忍性要好，只要有大部分的Redis实例存活，客户端就应该能够获得锁。 一种简单的方法 理解了上面我们列出的三个点，我们来分析一下一般的基于Redis实现的分布式锁： 使用Redis实现锁最简单的办法是创建一个key，且这个key通常有有限的存活时间，这一点可以利用Redis的过期时间特性，所以锁最终会被释放掉，当客户端需要释放资源的时候，客户端delete这个key即可。 So far so good!但是有个单点问题，假如Redis master挂掉怎么办，因此我们需要加个slave，当master挂掉的时候可以切换到slave。这又带来了新的问题，由于Redis的复制是异步的，因此我们不能保证同时只有一个客户端获得锁。 这个模型有很显然的竞态： Client在Master上面获得了锁。

浅解.Net分布式锁的实现 序言 我晚上有在公司多呆会儿的习惯，所以很多晚上我都是最后一个离开公司的。当然也有一些同事，跟我一样喜欢在公司多搞会儿。这篇文章就要从，去年年末一个多搞会的晚上说起，那是一个夜黑风高的晚上，公司应该没有几个人在啦，我司一技术男悠悠的走到我的背后，突然一句：“还没走啊？”！“我日，吓死我啦，你也没走啊”。此同事现在已被裁员，走啦，当晚他问我啦一个问题，至此时也没有机会告知，今天我就在这里就简单描述下他当时的问题，其实实现起来简单的不值一提，不过任何一个简单的问题往往都会有很多中解决方案，探索找到最佳的解决方案，然后把细节做好，那就是技术的精髓与乐趣所在。我这里只抛砖一下，希望能给我老同事一个思路。 回到问题 首先有如下二张表，字段有IsBuyed（0：未使用，1：已使用），ProductNo：产品编号，Count：使用次数。 就是针对这张表做需求扩展的。 1、每次请求过来，都随机拿到一个未使用过的产品编号 public int GetNo() { using (IDbConnection conn = GetConn()) { return conn.ExecuteScalar<int>("select top 1 ProductNo from AStore where isBuyed=0 order by newid()"); } } 2、每次请求过来

分布式一致性问题： # 分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可 在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如 分布式事务 、 分布式锁 等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行 分布式锁： # 是在分布式系统之间同步访问共享资源的一种方式。 不同的系统或者同一个系统不同的主机共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰，从而保证数据的一致性，怎么保证数据的一致性，就用到了分布式锁 那么用锁来解决资源抢占时，又有哪些问题： # 1、死锁 # 死锁是在并发编程中理论上都会出现的问题 什么是死锁： 抢占资源的各方，彼此都在等待对方释放资源，以便自己能获取系统资源，但是没有哪一方退出，这时候就死锁了 产生死锁的4个条件： 互斥条件 不可抢占条件 占用并申请条件 循环等待条件 解决方法： 解决死锁的问题只要解决了上面的4个条件之一即可。那怎么解决呢？

常见问题： 1、为什么使用redis （一）性能 我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。 （二）并发 在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。 2.使用redis有什么缺点 (一)缓存和数据库双写一致性问题 (二)缓存雪崩问题 (三)缓存击穿问题 (四)缓存的并发竞争问题 3、单线程的redis为什么这么快 (一)纯内存操作 (二)单线程操作，避免了频繁的上下文切换 (三)采用了非阻塞I/O多路复用机制     参照上图，简单来说，就是。我们的redis-client在操作的时候，会产生具有不同事件类型的socket。在服务端，有一段I/0多路复用程序，将其置入队列之中。然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中。 4、redis的数据类型，以及每种数据类型的使用场景 回答：一共五种 (一)String 这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候

Redis介绍 　　Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 相比于传统的关系型数据库，Redis的存储方式是key-value型的，说到key-value，我们肯定能想到JSON，但是JSON中value是不区分数据类型的，Redis支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询，能够更好的帮助我们进行数据的存储检索。此外Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。 正是由于这些特点，Redis广泛的应用于对性能和并发要求高的业务场景中，以下是常见的场景： String：缓存、计数器、分布式锁等。 List：链表、队列、微博关注人时间轴列表等。 Hash：用户信息、Hash 表等。 Set：去重、赞

分布式锁-redLock And Redisson 2019-03-01 16:51:48 淹不死的水 阅读数 372 更多 分类专栏： 分布式锁 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/stone_yw/article/details/88062938 文章目录 CAP redis分布式锁存在的问题 RedLock RedLock是什么？ RedLock算法 失败时重试 释放锁 性能、 崩溃恢复和redis同步 针对redlock的争议 Redisson 使用案例 源码 CAP 在引出RedLock之前，先介绍一下分布式系统中CAP理论： C(Consistency)：一致性，在同一时间点，所有节点的数据都是完全一致的。 A(Availability)：可用性，应该能够在正常时间内对请求进行响应。 P(Partition-tolerance)：分区容忍性，在分布式环境中，多个节点组成的网络应该是互相连通的，当由于网络故障等原因造成网络分区，要求仍然能够对外提供服务。 CAP理论告诉我们，任何分布式系统只能满足三个中的两个，不可能全部都满足。 参考 分布式系统那点事 redis分布式锁存在的问题 网上对于采用redis实现分布式锁有很多种方案

Redis基础类型常用操作命令 概念：Redis是用C语言开发的一个开源的高性能键值对数据库。 特征： 数据间没有必然的联系 内部采用单线程机制进行工作 高性能 多数据类型支持 字符串类型 String 列表类型 List 散列类型 Map 集合类型 Set 有序集合类型 SortedSet 持久化支持 应用场景 为热点数据加速查询；如：热点商品、热点新闻、热点资讯等高访问量信息。 任务队列；如：秒杀、抢购、购票等。 即时信息查询；如：排行榜等。 时效性信息控制；如：验证码、投票控制等。 分布式数据共享；如：分布式架构中的session等。 消息队列 分布式锁 基础数据类型之: String 单个string类型的存储空间为512MB string基本操作 添加或修改数据 set key value 获取数据 get key 删除数据 del key 设置过期时间(默认单位为秒) expire key second 追加信息到初始value后边 append key value 添加/修改多个数据 mset key1 value1 key2 value2... 获取多个数据 mget key1 key2 ... 获取字符串长度 strlen key 设置key的生命周期 控制生命周期 setex key seconds value (秒) psetex key

1. 什么是redis? Redis 是一个使用 C 语言写成的，开源的基于内存的高性能key-value数据库。 Redis的值可以是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位图）等多种数据结构组成。 回到顶部 2. Redis的特性 速度快 速度快的原因： - Redis所有数据都放在内存中 - Redis是C语言实现 - Redis使用了单线程的架构，预防了多线程可能产生的竞争问题 基于键值对的数据结构服务器 Redis中的值不仅可以是字符串，Redis的值可以是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位图）等多种数据结构组成，便于许多应用场景的开发并且提高了开发效率。 丰富的共鞥 提供了键过期功能，可以用来实现缓存 提供了发布/订阅功能，可以用来实现消息系统 支持Lua脚本功能，可以利用Lua创造出新的Redis命令 提供了简单的事务功能，能在一定程度上保证事务特性 提供了流水线（Pipeline）功能，减少了网络开销 简单稳定 客户端语言多 持久化 RDB（快照） AOF（日志的形式） 4.0版本开始支持RDB和AOF混用的方式聊进行持久化 主从复制 高可用和分布式 高可用实现：Redis Sentinel 分布式实现