首先redis是作為快取的，一般作為快取有兩種用途，快速訪問和減少IO頻率，所謂減少IO頻率就是等快取積累到一定大小然後一次刷入磁碟進行持久化。一般的設計就是客戶端往資料庫裡更新或者寫讀資料，redis做為經常需要被讀取的資料或者被修改資料的快取，提高操作效率，一般的操作應該是客戶端要修改資料時，先去快取REDIS找，找不到的話去資料庫讀取，替換不熱的快取，不熱的快取刷回資料庫；能找到的話直接修改，這不存在一致性問題。然而LZ要併發訪問REDIS和SQL，這樣要保持一致性的話，讀的時候就不能寫了，就是客戶端更新REDIS，然後REDIS回寫資料庫，這是一個事務，如果有一步不成功，那麼整個事務不成功；如果是多客戶端，如果資料木有分塊，那麼所有寫操作序列話，如果對資料進行了合理分塊，同一塊資料資料序列寫，不同塊併發處理。如果保證讀的時候不能寫，這就需要一個主控節點來提供分散式鎖。分散式知識太多啦，我就粗燥寫了幾句！

redis 通常作為程式快取，不會預先放資料。 所以你說的這種情況我沒遇到過。

如果你實在是需要這種場景， 可以將資料預先放在db， 然後在啟動的時候讀取db， 再初始化redis。 聽起來有些怪異， 但因為我不知道你的使用場景。

所以， 描述下使用場景會比較好。