解決緩存和數據庫數據同步問題。
1.緩存的使用方式
讀數據
：先讀取緩存，若不存在則從DB中讀取，並將結果寫入到緩存中；下次數據讀取時便可以直接從緩存中獲取數據。
改數據
：直接失效緩存數據，再修改DB內容（避免突發情況：避免DB修改成功，但由於網絡或者其他問題導致緩存數據沒有清理，造成了臟數據）
deleteAndIncVersion
接口：此接口並不會真的刪除數據，而是給數據打了標簽，表明已失效狀態，並且增加數據版本號；如果數據不存在則寫入NULL，同時也生成隨機數據版本號。OCS寫入支持原子對比版本號：假設傳入的版本號與OCS保存的數據版本號一致或者原數據不存在，則准許寫入，否則拒絕修改。
2.緩存與數據庫的一致性
方案
：MySQL作為主庫（寫），Redis作為高速數據查詢（讀）從庫的異構讀寫分離。
解決：專門開發了自己的MySQL復制工具，可以方便的實時同步MySQL中的數據到Redis上。
如果你可以接受定期從redis導入到mysql，那基本上表示你的業務就不需要mysql。
至於緩存，一般都是讀緩存（寫緩存實現起來很羅嗦，而且也不那么靠譜），與數據庫的同步策略需要添加到自己的代碼邏輯里。
結論：寫操作不緩存。失效緩存數據，再修改DB內容。
其他想法：
首先更新到 Mysql，然后再根據Mysql的更新內容去更新 其他數據庫例如redis。有一個問題很明顯，就是高並發下寫入Mysql是個可怕的事情，所以我之前想到的是直接更新redis然后異步更新Mysql，最后將redis作為緩沖層。
結論：高並發寫的情況必須單獨特殊處理（直接內存操作，慢回寫數據庫）。比如第4節：追求響應速度的情況。
3.多IDC的情況下的緩存一致性
不一致的根本原因是異構系統之間無法協同同步，不能保證DB數據先同步，緩存數據后同步。
所以就要考慮緩存系統如何等待DB同步，或者能否做到兩者共用一套同步機制？緩存同步也依賴DB BINLOG是一個可行的方案。
4.追求響應速度的情況
如果用關系數據庫，大量讀寫會導致索引無效，讀寫效率都會比較低下。可以考慮僅僅把那種一旦丟失就影響很大如當前等級、帳號和密碼之類的才持久化保存到關系數據庫中。
其他的實時數據，可以考慮使用各種NOSQL方案來達成更高的性能
，或者干脆自己的前端程序在內存中折騰，10分鍾才回寫給數據庫行不行呢。
假如非得用關系數據庫不可，建議采用內存數據庫。
如果沒有內存數據庫可用，可以考慮加大機器內存，反正現在內存也便宜，把各種緩存啊SharedBuffer之類的都開得盡可能的大。 還可以考慮上固態硬盤，提高磁盤I/O速度。
再者，就是考慮看能否把數據分離到不同的各個節點，盡量減少單點處理壓力。