高并发核心技术 - 幂等性 与 分布式锁

高并发核心技术之 - 幂等性

1. 什么是幂等性

幂等性就是指：一个幂等操做任其执行屡次所产生的影响均与一次执行的影响相同。 用数学的概念表达是这样的： f(f(x)) = f(x). 就像 nx1 = n 同样， x1 就是一个幂等操做。不管是乘以多少次结果都同样。

2. 常见的幂等性问题

幂等性问题常常会是由网络问题引发的，还有重复操做引发的。

场景一：好比点赞功能，一个用户只能对同一片文章点赞一次，重复点赞提示已经点过赞了。

示例代码：

public void like(Article article,User user) {
	//检查是否点过赞
    if (checkIsLike(article,user)) {
	//点过赞了
    throw new ApiException(CodeEnums.SYSTEM_ERR);
}
else {
	//保存点赞
    saveLike(article,user);
}
}
</pre>

看上去好像没有什么问题，保存点赞以前已经检查过是否点赞了，理论上同一我的不会对同一篇文章重复点赞。但实际不是这样的。由于网络请求不是排队进来的，而是一窝蜂涌进来的。

某些时候，用户网络很差，可能很短的时间内点击了屡次，因为网络传输问题，这些请求可能会同时来到咱们的服务器。

• 第一个请求 checkIsLike（） 返回 false ， 正在执行 saveLike() 操做，还没来的及提交事务
• 第二个请求过来了 ，checkIsLike（） 返回 也是 false , 并去 执行了 saveLike() 操做

这样子，就形成了一个用户同时对一篇文章进行了屡次点赞操做。

这就是典型的幂等性问题， 操做了一次和操做了两次结果不同，由于你多点了一次赞，按照幂等性原则 无论你点击了多少次结果都同样，只点了一次赞。

不少场景都是这样形成的，好比用户重复下单，重复评论，重复提交表单等。

那怎么解决呢？ 假设网络的请求是排队进来的就不会出现这个问题了。

因而咱们能够改为这样：

public synchronized void like(Article article,User user) {
	//检查是否点过赞
if (checkIsLike(article,user)) {
	//点过赞了
throw new ApiException(CodeEnums.SYSTEM_ERR);
}
else {
	//保存点赞
saveLike(article,user);
}
}
</pre>

synchronized 同步锁 这样咱们的请求就会乖乖的排队进来了。

PS ：这样作是效率比较低的作法，不建议这么作，只是举例子，synchronized 也不适合分布式集群场景。

场景二 ： 第三方回调

咱们系统常常须要和第三方系统打交道，好比微信充值，支付宝充值什么的，微信和支付宝经常会以回调你的接口通知你支付结果。为了保证你能收到回调，每每可能会回调屡次。

有时候咱们也为了保证数据的准确性会有个定时器去查询支付结果未知的流水，并执行响应的处理。 若是定时器的轮训和回调恰好是在同时进行，这可能又出BUG了,又进行了两次重复操做。

那么问题来了： 假设我是一个充值操做， 回调回来的时候 ，会作业务处理，成功了给用户帐户加钱。这是后就要保证幂等性了， 假设微信同一笔交易给你回调了两次，若是你给用户充值了两次，这显然不合理(我是老板确定扣你工资)，因此要保证 无论微信回调你多少次 ，同一笔交易你只能给用户充一次钱。这就幂等性。

解决幂等性问题方案

• synchronized 适合单机应用，不追求性能 ，不追求并发。
• 分布式锁 可是每每咱们的应用是分布式的集群，而且很讲究性能，并发，因此咱们须要用到 分布式锁 来解决这个问题。

Redis 分布式锁：

/**
* setNx
*
*  @param key
*  @param value
*  @return
*/
public Boolean setNx(String key,Object value) {
	return redisTemplate.opsForValue().setIfAbsent(key,value);
}
/**
*  @param key 锁
*  @param waitTime 等待时间  毫秒
*  @param expireTime 超时时间  毫秒
*  @return
*/
public Boolean lock(String key,Long waitTime,Long expireTime) {
	String vlaue =  UUIDUtil.mongoObjectId();
	Boolean flag = setNx(key,vlaue);
	//尝试获取锁  成功返回
if (flag) {
	redisTemplate.expire(key,expireTime,TimeUnit.MILLISECONDS);
	return flag;
}
else {
	//失败
//如今时间
long newTime =  System.currentTimeMillis();
	//等待过时时间
long loseTime = newTime + waitTime;
	//不断尝试获取锁成功返回
while (System.currentTimeMillis()  < loseTime) {
	Boolean testFlag = setNx(key,vlaue);
	if (testFlag) {
	redisTemplate.expire(key,expireTime,TimeUnit.MILLISECONDS);
	return testFlag;
}
//休眠100毫秒
try {
	Thread.sleep(100);
}
catch (InterruptedException e) {
	e.printStackTrace();
}
}}return false;}/**
*  @param key
*  @return
*/
public Boolean lock(String key) {
	return lock(key,1000L,60  *  1000L);
}
/**
*  @param key
*/
public void unLock(String key) {
	remove(key);
}
</pre>

利用Redis 分布式锁 咱们的代码能够改为这样：

public void like(Article article,User user) {
	String key =  "key:like"  + article.getId()  +  ":"  + user.getUserId();
	//  等待锁的时间  0  ，  过时时间  一分钟防止死锁
boolean flag = redisService.lock(key,0,60  *  1000L);
	if(!flag) {
	//获取锁失败  说明前面的请求已经获取了锁
throw new ApiException(CodeEnums.SYSTEM_ERR);
}
//检查是否点过赞
if (checkIsLike(article,user)) {
	//点过赞了
throw new ApiException(CodeEnums.SYSTEM_ERR);
}
else {
	//保存点赞
saveLike(article,user);
}
//删除锁
redisService.unLock(key);
}
</pre>

key 的设计也很讲究： 数据不冲突的两个业务场景，key不能冲突，不一样人的key也不同，不一样的文章Key也不同。 根据场景业务设定。

一个原则： 尽量的缩小key的范围。 这样才能加强咱们的并发。

首先咱们先获取锁，获取锁成功 执行完操做，保存数据 ，删除锁。获取不到锁返回失败。设置过时时间是为了防止‘死锁’，好比机器获取到了 锁，没有设置过时时间，可是他死机了，没有删除释放锁。

• 版本号控制 CAS 算法： CAS有3个操做数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改成B，不然什么都不作。这个比较繁杂，有兴趣的同窗能够去看看。