一冰啃、什么是冪等性
可以參考數(shù)據(jù)庫(kù)樂(lè)觀鎖機(jī)制，比如執(zhí)行一條更新庫(kù)存的 SQL 語(yǔ)句刘莹，在并發(fā)場(chǎng)景阎毅，為了性能和數(shù)據(jù)可靠性，會(huì)在更新時(shí)加上查詢(xún)時(shí)的版本点弯，并且更新這個(gè)版本信息扇调。可能你要對(duì)一個(gè)事情進(jìn)行操作抢肛，這個(gè)操作可能會(huì)執(zhí)行成百上千次狼钮，但是操作結(jié)果都是相同的碳柱，這就是冪等性。
二熬芜、消費(fèi)端的冪等性保障
在海量訂單生成的業(yè)務(wù)高峰期莲镣，生產(chǎn)端有可能就會(huì)重復(fù)發(fā)生了消息，這時(shí)候消費(fèi)端就要實(shí)現(xiàn)冪等性涎拉，這就意味著我們的消息永遠(yuǎn)不會(huì)被消費(fèi)多次瑞侮，即使我們收到了一樣的消息。
業(yè)界主流的冪等性有兩種操作：
1.唯一 ID + 指紋碼 機(jī)制鼓拧，利用數(shù)據(jù)庫(kù)主鍵去重
2.利用redis的原子性去實(shí)現(xiàn)
三区岗、唯一 ID + 指紋碼 機(jī)制
大家肯定懂唯一 ID 的，就不多說(shuō)了毁枯，為什么需要指紋碼呢慈缔？這是為了應(yīng)對(duì)用戶(hù)在一瞬間的頻繁操作，這個(gè)指紋碼可能是我們的一些規(guī)則或者時(shí)間戳加別的服務(wù)給到的唯一信息碼种玛，它并不一定是我們系統(tǒng)生成的藐鹤，基本都是由我們的業(yè)務(wù)規(guī)則拼接而來(lái)，但是一定要保證唯一性赂韵，然后就利用查詢(xún)語(yǔ)句進(jìn)行判斷這個(gè)id是否存在數(shù)據(jù)庫(kù)中娱节。
好處就是實(shí)現(xiàn)簡(jiǎn)單，就一個(gè)拼接祭示，然后查詢(xún)判斷是否重復(fù)肄满。
壞處就是在高并發(fā)時(shí)，如果是單個(gè)數(shù)據(jù)庫(kù)就會(huì)有寫(xiě)入性能瓶頸
解決方案 ：根據(jù) ID 進(jìn)行分庫(kù)分表质涛，對(duì) id 進(jìn)行算法路由稠歉，落到一個(gè)具體的數(shù)據(jù)庫(kù)，然后當(dāng)這個(gè) id 第二次來(lái)又會(huì)落到這個(gè)數(shù)據(jù)庫(kù)汇陆，這時(shí)候就像我單庫(kù)時(shí)的查重一樣了怒炸。利用算法路由把單庫(kù)的冪等變成多庫(kù)的冪等，分?jǐn)倲?shù)據(jù)流量壓力毡代，提高性能阅羹。
四、利用 redis 的原子性去實(shí)現(xiàn)
相信大家都知道 redis 的原子性操作教寂，我這里就不需要過(guò)多介紹了捏鱼。
使用 redis 的原子性去實(shí)現(xiàn)需要考慮兩個(gè)點(diǎn)
一是 是否 要進(jìn)行數(shù)據(jù)落庫(kù)，如果落庫(kù)的話酪耕，關(guān)鍵解決的問(wèn)題是數(shù)據(jù)庫(kù)和緩存如何做到原子性导梆？
數(shù)據(jù)庫(kù)與緩存進(jìn)行同步肯定要進(jìn)行寫(xiě)操作，到底先寫(xiě) redis 還是先寫(xiě)數(shù)據(jù)庫(kù)，這是個(gè)問(wèn)題问潭，涉及到緩存更新與淘汰的問(wèn)題
二是 如果不落庫(kù)，那么都存儲(chǔ)到緩存中婚被，如何設(shè)置定時(shí)同步的策略狡忙？
不入庫(kù)的話，可以使用雙重緩存等策略址芯，保障一個(gè)消息副本灾茁，具體同步可以使用類(lèi)似 databus 這種同步工具。
