分布式系統(tǒng)的冪等性問題
這個(gè)應(yīng)該是沒有特定答案的蒿偎，因情況而異，總得來說要么就是數(shù)據(jù)庫層面加上唯一鍵俄烁，要么就是使用redis來實(shí)現(xiàn)冪等性
image.png
分布式系統(tǒng)接口調(diào)用保證順序性
image.png
image.png
如果實(shí)在要求100%強(qiáng)順序性，采用分布式鎖方案，請求需要另外加上序號(hào)璃氢，但是這個(gè)方案會(huì)降低并發(fā)量
image.png
zk做分布式協(xié)調(diào)
image.png
zk做分布式鎖
image.png
zk做源數(shù)據(jù)和配置管理
image.png
zk做HA高可用性
image.png
redis做分布式鎖的簡單場景
image.png
image.png
RedLock
image.png
規(guī)避單個(gè)redis宕機(jī)導(dǎo)致鎖(用的比較少，很少驗(yàn)證狮辽。這個(gè)很麻煩)
集群部署的redis一也，使用分布式鎖時(shí)有可能redis鎖出現(xiàn)錯(cuò)誤
redis 主從復(fù)制是異步進(jìn)行的，那么就有可能在加鎖的時(shí)候(master加鎖成功喉脖，此時(shí)客戶端會(huì)認(rèn)為加鎖成功塘秦，但是redis異步復(fù)制還沒開始時(shí)master就已經(jīng)宕機(jī)了，這個(gè)時(shí)候slave升級(jí)為master角色动看，但是新master并沒有數(shù)據(jù)尊剔，所以下一個(gè)請求過來 又可以加鎖成功了，這就形成了沖突)菱皆。要解決這個(gè)問題 的方案是加鎖時(shí)须误，要確保主從都加鎖了 客戶端才認(rèn)為加鎖成功才行。
二者做分布式鎖的對(duì)比
image.png
分布式會(huì)話session
就是使用redis唄
