秒殺過程中怎么保證redis緩存和數(shù)據(jù)庫的一致性？如果要“保證”數(shù)據(jù)的安全性，會帶來開銷的進(jìn)一步提高，從而失去使用redis帶來的性能優(yōu)勢。正確的方法是區(qū)分不同的服務(wù)，這樣當(dāng)不需要“保證”數(shù)據(jù)一致性時

秒殺過程中怎么保證redis緩存和數(shù)據(jù)庫的一致性？

如果要“保證”數(shù)據(jù)的安全性，會帶來開銷的進(jìn)一步提高，從而失去使用redis帶來的性能優(yōu)勢。

正確的方法是區(qū)分不同的服務(wù)，這樣當(dāng)不需要“保證”數(shù)據(jù)一致性時，就可以使用redis優(yōu)化。MySQL仍然在敏感場合使用。

Redis緩存怎么與數(shù)據(jù)庫進(jìn)行數(shù)據(jù)同步？

這種writer-reader體系結(jié)構(gòu)的總體思想是，writer將在緩存更新階段解決一致性問題。當(dāng)數(shù)據(jù)庫數(shù)據(jù)發(fā)生變化時，redis會同步更新，以保證緩存更新的成功。作為完整性判斷，您可以使用自遞增的版本號（或時間戳）來判斷數(shù)據(jù)是否是最新的，而無需檢查所有屬性。作為后檢測，可以對其進(jìn)行優(yōu)化以降低掃描成本。例如，只應(yīng)使用最新時間段（如10分鐘）內(nèi)的更新數(shù)據(jù)。這一套應(yīng)該相對較小，在redis中的檢查成本相對較低。

有些“上古”程序員一直堅持反對使用redis怎么辦？

分享大人物的答案似乎合情合理。

不要告訴我們是否使用redis。你必須告訴我們你為什么要使用redis。沒有redis的業(yè)務(wù)怎么了？世界上沒有免費的午餐。如果不直接使用頭部緩存/NoSQL，可能會帶來越來越嚴(yán)重的問題。

單個數(shù)據(jù)庫的最大優(yōu)點是易于實現(xiàn)事務(wù)，并由數(shù)據(jù)庫本身保證。舉個簡單的例子，要下訂單，需要扣除庫存并插入訂單條目。如果inventory和order都是數(shù)據(jù)庫表條目，那么這個事務(wù)是無可挑剔的。如果庫存在redis中，訂單條目是mysql，通常需要先寫redis，成功后再寫數(shù)據(jù)庫。如果您寫數(shù)據(jù)庫失敗，需要回滾redis，如果由于網(wǎng)絡(luò)或其他原因回滾失敗，將再扣減一個存貨。不要認(rèn)為這些事情很容易解決。事務(wù)處理的復(fù)雜性遠(yuǎn)遠(yuǎn)超出您的想象。例如，當(dāng)您編寫mysql時，您在提交時就失去了連接。你無法判斷提交是成功還是失敗。你的redis是不是在倒退？

因此，當(dāng)您引入一個新層時，您必須弄清楚您必須使用cache/NoSQL的目的以及您可以接受的一致性模型。否則，你就要出丑了。