項目中@Transactional對redis沒有效果，如何讓緩存在異常時也回滾

今天面試的時候，被問到跟你類似的問題，上網(wǎng)搜一下只搜到這個問題，就來說一下我的情況吧。
我的想法和其他人也一直，就是在保證入庫的前提下（也就是事務完成之后）再進行緩存的更新，或者對緩存進行CAS校驗。
但是面試官說，這樣做無疑增加了開發(fā)的復雜性，因為把更新緩存和實際業(yè)務邏輯分離了，有沒有更好的方法。
我覺得他說的也對，但最后也沒想到什么好點子，原本以為面試官會有很棒的解題思路。
結(jié)果他的回答讓我崩潰，他說：
1，在事務中的時候不做更新緩存操作，而是用刪除緩存的操作
2，在讀數(shù)據(jù)的時候，才去判斷緩存時候過期或者是否需要更新。
3，為了保證刪除緩存的操作萬無一失，進行雙刪除操作，同步刪一次，異步刪一次。

我勒個去，先不提讀數(shù)據(jù)時也是存在數(shù)據(jù)不一致的隱患，我一直沒想去刪除緩存這個方法，就是因為一旦刪除緩存之后，萬一突然來了個高并發(fā)請求，是會造成緩存穿透的，而緩存穿透的危害比數(shù)據(jù)不一致要大得多。他說這個是內(nèi)部系統(tǒng)不會有很大的訪問量，這種解釋簡直無語，他的這種做法和hack沒任何區(qū)別。

先入庫在寫緩存的吧，mysql的Innodb引擎才支持事務，流程正確了就不存在這個問題