概述

分布式锁有几种实现方式, 若是用数据库实现, 可能会有性能的缺陷, 那么今天就来聊一聊缓存(Redis)来实现分布式锁;

实现

使用Redis实现分布式锁最简单的方案是使用命令SETNX。SETNX（SET if Not eXist）的使用方式为：SETNX key value，只在键key不存在的情况下，将键key的值设置为value，若键key存在，则SETNX不做任何动作。SETNX在设置成功时返回，设置失败时返回0。当要获取锁时，直接使用SETNX获取锁，当要释放锁时，使用DEL命令删除掉对应的键key即可。

这个方式跟之前用数据库的基于表记录实现差不多, 只不过换用了更高性能的缓存redis罢了, 所以他同样有一个缺点,就是如果因为某些错误, 而没有删除键key的时候, 会导致锁释放不掉, 不过这个问题比数据库的更好解决, 可以为这个key设置超时时间(这个一般redis key都是要的);

set命令用下面方式修饰:

1
2
3
4

* EX seconds：将键的过期时间设置为 seconds 秒。执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。
* PX milliseconds：将键的过期时间设置为 milliseconds 毫秒。执行 SET key value PX milliseconds 的效果等同于执行 PSETEX key milliseconds value 。
* NX：只在键不存在时，才对键进行设置操作。执行 SET key value NX 的效果等同于执行 SETNX key value.
* XX：只在键已经存在时，才对键进行设置操作。

创建一个锁, 设置过期为10s:

1
2
3

SET lockKey lockValue EX 10 NX
或者
SET lockKey lockValue PX 10000 NX

注意EX和PX不能同时使用，否则会报错：ERR syntax error。
解锁的时候还是使用DEL命令来解锁。

目前看上去方案就很完美, 但实际还是有隐患, 不完美;

概述

以前在单机时代, 并不需要分布式锁, 当多个线程需要访问同个资源时, 可以用线程间的锁来解决, 比如(synchronized);
但到了分布式系统的时代, 线程间的锁机制就没用了, 那是因为资源会被复制在多台机中, 已经不能用线程间共享了, 毕竟跨越了主机了, 应该属于进程间共享的资源;
因此, 必须引入分布式锁, 分布式锁是指在分布式的部署环境下, 通过锁机制来让多客户端互斥的对共享资源进行访问;

数据库分布式锁

对于选型用数据库进行实现分布式锁, 一般会觉得不太高级, 或者说性能不够, 但其实他足够简单, 如果一个业务没那么复杂, 其实很多时候, 减少复杂度是更好的设计;还是要基于场景来定
然后一般用数据库实现分布式锁, 有三种实现思路:
1.基于表记录;
2.乐观锁;
3.悲观锁;

起因

公司上线一个新的项目, 业务层使用了spring cloud, 本地调试都好好的, 但是却在部署上服务端, 加了一层nginx后; 发现请求没响应; 但奇怪的是, 并不是所有的api请求都是没响应, 有部分可行;

排查

1.首先查看下有响应的和无响应的代码有何不同, 发现有响应的都是比较简单的接口, 没有经过服务间调用的, 而无响应的那些, 都是需要请求多个服务来进行了, 我们使用的是spring cloud的feign组件, 那是不是这部分的坑呢? 导致请求不通呢?
2.但是查看日志, 所有服务的记录都是有返回的, 并且如果使用ip加端口, 不经过nginx的话, 那就可以得到正常的响应; 难道这个锅要nginx来背?

Redis使用规范指导

一. 键值设计

1.key名设计:

• 可读性和可管理性: 以业务名:表名:id 来避免冲突;

1

user:book:1

• 简洁性: 不要过长, 会导致内存占用过高; 最好不要超过20字节;

1

若过长: 就把常用的单词缩写: 如: u:bok:1

• 不要包含特殊字符(强制)

1

如 空格, 换行, 单双引号以及其他的转义字符

1. ASCII方案:

• 一开始的计算机标准, 用于存储空格,标点符号,数字,大小写字母等;(美国信息互换标准代码)

2.GB2312方案:

• 为了弥补ASCII无法显示中文, 规定127后的两个字符连在一起, 组成两字节长的编码(全角), 用于显示简体汉字;

3.GBK标准:

• 汉字太多,导致规定只要是高字节是127以后的,就是一个汉字的开始, 而后面可以跟着非127以后的;

4.GB18030:

• 扩展少数民族的字;