转载：Redis与Mysql数据同步解决方案整理

最近在做一个Redis数据同步到数据库MySQL的功能。
自己想了想，也有大概方案。1.队列同步，变跟数据2份，使用消息队列，一份给Redis消费，一份给Mysql消费。2.后台定时任务，定时刷新Redis中信息到数据库。
网上也到处找了下解决方案

方案一：

读: 读redis->没有，读mysql->把mysql数据写回redis写: 写mysql->成功，写redis。就是读的话，先读Redis,Redis没有再读数据库，将数据库中的数据放入Redis。写（增删改），先写数据库，然后写Redis。可以对此稍微优化，比如要求一致性高的数据，从数据库读，比如金融，交易数据。不要求强一致性的从Reids中读取。

方案二：

基于binlog使用mysql_udf_redis，将数据库中的数据同步到Redis。

方案三：

基于MQ，也就是最上面想到的方式1。

方案四：

官方有个memcached的udf插件，如果不是那么强烈非要redis的话，也可以考虑

方案五：

用POSTGRESQL 替代 Mysql +Redis.

各种方案弊端

但是上面的方案都有各自的弊端。方案一，明显对于数据量巨大，更新频繁的数据写入无能为力。比如数量巨大，每个变跟状态又很频繁，这样很容易把数据库写挂。方案二，是使用的mysql的User Defined Function功能，mysql_udf_redis是有人实现的同步数据到Redis的功能，弊端：需要学习成本，而来，第三方的插件不稳定。方案三：怎么保证到数据库和到Redis中的状态一致性。就是假设一条修改数据，从队列写入到Mysql成功，但是写入到Redis失败，这种如何搞。还有就是需要一个消息队列，使用第三方的比如Kafka，RabbitMq等来实现，管理起来不方便，系统整体稳定性不行，而且只是这么个比较小的箱格数据信息同步。有点杀鸡用牛刀。

其他的方案：

订阅key的变化进行数据库更新，写的时候写2份，一份往Redis写，一份是Redis数据的key网更新队列（也可以直接Reids存）里写，再写个定时程序从更新队列里取时间，根据key取出Redis数据到Mysql.这个方案，其实和其他的不一样，弊端了，就是占用内存大，因为需要维护一份更新队列。可以用定时任务，刷Redis中的信
4000
息到数据库。先是进行状态比对，状态不一致的放入集合，批量update数据库。
其实也会有写小问题，比如在比对的时候：1.Redis中的数据状态变跟了，怎么办？我们不可能在比对的时候锁住Redis，200W次循环，这段时间完全可能发生状态变跟。2.在比对的时候，有人更新了数据库，怎么办？因为有些操作是可以直接更新数据库的。比如更新layoutRow之类的信息。
Redis同步mysql大致有两种同步，第一种是mysql 同步到redis，为了兼容手动在mysql数据库操作的同步，可以解析mysql的binlog，当数据库发生增，删，改时自动同步到redis，
可以使用的库有[open-replicator](GitHub - whitesock/open-replicator: Open Replicator is a high performance MySQL binlog parser written in Java. It unfolds the possibilities that you can parse, filter and broadcast the binlog events in a real time manner.)，
如果想同步redis数据到mysql，可以使用
[redis-replicator](leonchen83/redis-replicator)

<dependency>
<groupId>com.moilioncircle</groupId>
<artifactId>redis-replicator</artifactId>
<version>2.3.1</version>
</dependency>

另外分享一篇mysql刷新自动同步到redis的文章，利用mysql的udf函数利用redis的api从mysql同步到redis；利用c++编写redis的函数，利用mysql加载udf，然后采用触发器
自动同步到redis

通过UDF使mysql主动刷新redis缓存

参考的几篇大神的文章：1. <<缓存更新的套路>>：http://coolshell.cn/articles/17416.html2. <<分布式系统的事务处理>>：http://coolshell.cn/articles/10910.html3. <<redis与mysql数据同步代码演示>>：http://www.cnblogs.com/linjiqin/p/3569011.html