高并發(fā)原子性處理
場(chǎng)景：redis校驗(yàn)是否存在->存表
相同的請(qǐng)求1000次/s
//判斷是否請(qǐng)求過(guò)
if(redis.get(key,hashKey)!=null){
//重復(fù)請(qǐng)求，拋出異常
throw new RunTimeException("重復(fù)請(qǐng)求");
}
//沒(méi)有請(qǐng)求過(guò)惠险，存redis
redis.put(key,hashKey,value);
//存表
saveDB();
發(fā)現(xiàn)表中存在多條數(shù)據(jù)
解決方式一：synchronized
synchronized(this){
//判斷是否請(qǐng)求過(guò)
if(redis.get(key,hashKey)!=null){
//重復(fù)請(qǐng)求，拋出異常
throw new RunTimeException("重復(fù)請(qǐng)求");
}
//沒(méi)有請(qǐng)求過(guò)，存redis
redis.put(key,hashKey,value);
redis.expire(key,timeout);
//存表
saveDB();
}
問(wèn)題：
這種方式并不是原子性的，還是可能會(huì)存在問(wèn)題蛤肌，比如put和expire其中一條成功，一條失敗批狱。
分布式環(huán)境下裸准，也會(huì)有問(wèn)題，可能會(huì)每臺(tái)機(jī)都存一條
redis
解決方式二：setnx
if(redisTemplate.opsForValue().setIfAbsent(key,value,Duration.ofMillis(timeout))){
//存表
saveDB();
}
else{
//重復(fù)請(qǐng)求赔硫，拋出異常
throw new RunTimeException("重復(fù)請(qǐng)求");
}
多臺(tái)redis服務(wù)器可能會(huì)出現(xiàn)問(wèn)題炒俱，（setnx(key,value,1000)的時(shí)候，A服務(wù)器存入緩存，還沒(méi)同步到本地或者沒(méi)來(lái)得及同步到slave就掛了权悟，下一次（setnx(key,value,1000)）的時(shí)候砸王，在集群中是沒(méi)有的。這時(shí)候就多條的情況僵芹。
解決方式三：RedLock
- 獲取當(dāng)前時(shí)間戳
- client嘗試按照順序使用相同的key,value獲取所有redis服務(wù)的鎖处硬，在獲取鎖的過(guò)程中的獲取時(shí)間比鎖過(guò)期時(shí)間短很多，這是為了不要過(guò)長(zhǎng)時(shí)間等待已經(jīng)關(guān)閉的redis服務(wù)拇派。并且試著獲取下一個(gè)redis實(shí)例荷辕。
- 比如：TTL為5s,設(shè)置獲取鎖最多用1s，所以如果一秒內(nèi)無(wú)法獲取鎖件豌，就放棄獲取這個(gè)鎖疮方，從而嘗試獲取下個(gè)鎖
- client通過(guò)獲取所有能獲取的鎖后的時(shí)間減去第一步的時(shí)間，這個(gè)時(shí)間差要小于TTL時(shí)間并且至少有3個(gè)redis實(shí)例成功獲取鎖茧彤，才算真正的獲取鎖成功
- 如果成功獲取鎖骡显，則鎖的真正有效時(shí)間是 TTL減去第三步的時(shí)間差 的時(shí)間；比如：TTL 是5s,獲取所有鎖用了2s,則真正鎖有效時(shí)間為3s(其實(shí)應(yīng)該再減去時(shí)鐘漂移);
- 如果客戶(hù)端由于某些原因獲取鎖失敗曾掂，便會(huì)開(kāi)始解鎖所有redis實(shí)例惫谤；因?yàn)榭赡芤呀?jīng)獲取了小于3個(gè)鎖，必須釋放珠洗，否則影響其他client獲取鎖
注意的點(diǎn)：
- 先假設(shè)client獲取所有實(shí)例溜歪，所有實(shí)例包含相同的key和過(guò)期時(shí)間(TTL) ,但每個(gè)實(shí)例set命令時(shí)間不同導(dǎo)致不能同時(shí)過(guò)期，第一個(gè)set命令之前是T1,最后一個(gè)set命令后為T(mén)2,則此client有效獲取鎖的最小時(shí)間為T(mén)TL-(T2-T1)-時(shí)鐘漂移;
- 對(duì)于以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功许蓖，是因?yàn)槿绻∮谝话肱袛酁槌晒Φ脑?huà)蝴猪，有可能出現(xiàn)多個(gè)client都成功獲取鎖的情況， 從而使鎖失效
- 一個(gè)client鎖定大多數(shù)事例耗費(fèi)的時(shí)間大于或接近鎖的過(guò)期時(shí)間膊爪，就認(rèn)為鎖無(wú)效自阱，并且解鎖這個(gè)redis實(shí)例(不執(zhí)行業(yè)務(wù)) ;只要在TTL時(shí)間內(nèi)成功獲取一半以上的鎖便是有效鎖;否則無(wú)效
mysql
解決方式四：Mysql insert
表：
create table database_lock(
id int not null auto_increment primary key,
resource int not null comment '資源',
description varchar(1024) not null default "" comment '描述',
version int,
updated_time datetime,
unique key `uiq_idx_resource` (`resource`)
)engine=InnoDB default charset=utf8;
根據(jù)resource是unique key唯一約束原則實(shí)現(xiàn)的。
try{
insertIntoMysqlLock(user.getId(),"mall.user.id",1);
saveDB();
}
catch (Exception e){
throw new MallDefaultException("重復(fù)下單");
}
insert into database_lock value(1,'mall.user.id',1,sysdate);
解決方式五：Mysql update
insert into database_lock value(1,'unlock',1,sysdate);
if (update(user.getId(),1)) {
saveDB();
}
else {
throw new MallDefaultException("重復(fù)下單");
}
```sql
update database_lock set version = version+1 ,updated_time = sysdate where resource = 1 and version = 1 and description = 'unlock';
zookeeper
分布式鎖三要素
1.互斥米酬；任何時(shí)刻只能有一個(gè)client獲取鎖
2.釋放死鎖沛豌；即使鎖定資源的服務(wù)崩潰或者分區(qū)，仍然能釋放鎖
3.容錯(cuò)性赃额；只要多數(shù)redis節(jié)點(diǎn)（一半以上）在使用琼懊，client就可以獲取和釋放鎖
