redis高速緩存原理？Rredis數(shù)據(jù)格式？Rphp redis做mysql的緩存，怎么異步redis同步到mysql數(shù)據(jù)庫？正常情況下沒有問題。但也有人使用惡意腳本，即同一個(gè)人發(fā)起大量請(qǐng)求，一秒鐘

redis高速緩存原理？

R

redis數(shù)據(jù)格式？

R

php redis做mysql的緩存，怎么異步redis同步到mysql數(shù)據(jù)庫？

正常情況下沒有問題。

但也有人使用惡意腳本，即同一個(gè)人發(fā)起大量請(qǐng)求，一秒鐘可能是一兩百個(gè)請(qǐng)求甚至更多，不止一個(gè)人。

問題出在第一步。

舉個(gè)例子，假設(shè)每個(gè)人只能抽一次獎(jiǎng)，因?yàn)檎?qǐng)求太快，同一個(gè)人A和B的兩個(gè)請(qǐng)求幾乎同時(shí)到來。a已經(jīng)完成了邏輯，在表中插入記錄時(shí)，因?yàn)閙ysql的性能問題，B可以 當(dāng)轉(zhuǎn)至1時(shí)，不讀取表中的記錄，因?yàn)锳的插入根本沒有完成。所以請(qǐng)求b將再次經(jīng)歷抽簽邏輯。導(dǎo)致同一個(gè)人抽兩次，然后插入臺(tái)。

我關(guān)心的是B是否能在A插入的瞬間判斷出表中有數(shù)據(jù)。

所以我覺得問題是mysql寫的不夠快，讀的不夠快，所以想用r

redis為什么把數(shù)據(jù)放到內(nèi)存中？

為了快一點(diǎn)。Redis是單線程架構(gòu)，采用I/O復(fù)用的事件模型。單線程架構(gòu)避免了頻繁的上下文切換，但問題是如果一個(gè)操作很慢，就會(huì)導(dǎo)致?lián)砣?。?nèi)存和硬盤的讀寫速度不是一個(gè)數(shù)量級(jí)的，可以為redis提供更快的讀寫速度，保證redis的高性能。