解决缓存和数据库数据同步问题。
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速度。
再者，就是考虑看能否把数据分离到不同的各个节点，尽量减少单点处理压力。