mysql分布式缓存_基于Redis分布式缓存实现

三.采用binlog架构刷新缓存可行性分析

2.对于使用MIXED日志格式，此日志格式，记录的是对应数据库操作的SQL语句，采用此日志方式存在的问题：

对于一些未任何更新操作的SQl语句，像条件不满足，对应的sql也会记录到binlog日志中。

SQL语句记录的未必包括所有的更新操作。

对于一些分布式数据库，对于SQL中的where条件指定的是非均衡字段，也许会存在多条SQL,跟设计有关！

基于以上考虑，采用MIXED的日志格式进行binlog解析是行不通的。(官网给出的指示是failed statementsare not logged ，但不包括语法没错误，更新条件不符合对应的SQL)

3.采用ROW日志格式

对于此日志格式，每行变化都有对应的记录，此日志格式，对于解析及采集数据都是非常方便的，也只有采用此日志格式，才能基于binlog修改，做刷新缓存相关方案的设计。但是基于此日志格式也存在一些问题：

需要考虑项目中是否有大量的批量的update操作，如果采用此日志格式，批量操作每一行修改都会记录一条日志，大量的批量操作所产生的日志量，以及所带来的IO开销是否可以接受。

通过以上分析，最终项目中还是考虑基于ROW日志格式进行缓存刷新，还有一个问题需要考虑，在应用层DB进行了相应的update操作后，所产生的Binlog是会带来一定的延迟，如果Binlog处理模块正常运行，数据是的延迟会非常少，MS级别以内，对用户体验是没有感知的，但是Binlog模块是多点，异常，以及相应的延迟肯定会是存在的，这样，缓存数据肯定会存在脏数据。

不过通过以上方案，数据能达到最终一致性，因此how to权衡，需要考虑。

通过以上分析，是否采用Binlog来做缓存数据刷新相信大家有一个基本概念了

四.基于binlog刷新缓存的实现时注意的地方

1.如果是采用Java做相关开发，可以使用开源的tungstenAPI

2.Binlog日志解析是按照mysql 的master/slave同步流程来实现，即一个线程同步，一个线程解析。

3.设计是可分Binlog处理模块以及缓存处理SqlEvent两部分，其中Binlog处理解析好对应的SqlEvent，然后对应的缓存刷新处理SqlEvent,一个简单的生产者-消费者模式。

4.对于多个Binlog处理模块可以是单点，也可以是通过一些协同工具来管理，看需求。可以使用ZooKeeper等。

5.对于分布式缓存中的数据，对于Binlog来刷新的缓存数据会存在load数据的问题，为了减轻DB的额外压力，flush操作可在get缓存数据处完成。看需求，如果读写完全分享的话此DB的额外压力可以接收的话也可行。

6.对于缓存数据性一致性要求比较高的，可以通过版本号来控制，即在应用层引入一定的耦合，在DB操作时带mark ，缓存刷新是也mark，另外get操作时比较双版本号来达到数据的一致性。(此跟5谈论的一定的联系，读写是否完全分离，以及相应一致性实现的一些方法)

五.一点心得

前前后后，对Redis完成调研，以及相关的一些使用，分布式缓存的实现，基于binlog方式的修改等，接触有一年多了，这段时间下来，学了很多，以上算是一点小记，这部分工作的一点小记。实现过程中存在更多的问题。

最近自己的工作上调研的一个失误，影响了很多工作量，心里受到了些打击。

但是2012，谁知道这年能不能过完呢，非本命年，如此背运的一年，也真是少见。

上面为题外话了，，工作上的失误，给了自己更多的是对于自己工作的反思。

对于调研相关的一些工作，一定要做的仔细，相应的细节一定要了解透彻，否则也许一此小问题会导致整个方案的不可行，甚至更大的的问题。连锁反应！

接下来有时间会写一篇关于BloomFilter的的文章 ，以及D-Left_BloomFilter，在此说明，只为自己有更大的动力去完成它。项目中实现了D-Left_BloomFilter，但在网上没有相关实现，在对其优化后，会在博文上做一些小小的记录。

以上如果有什么不对的地方请指正，有什么相关问题也可以跟我联系，可以一起交流学习！