各位朋友，
我现在在一个游戏团队中开发，我们现在遇到了一个关于Mysql的棘手的问题，一般普通的新闻网站，这些对同步及时性要求不高的场合都可以用主从同步，读写分离来实现负载的分散，但是对于游戏里面大部分数据都是玩家的任务相关数据，还有道具等数据，这些数据对各服务器之间的及时同步要求非常高，至少应该保持在1秒级别的。但是我们做的游戏放在facebook社交平台上，不像一般的网页游戏，可以通过分区来分散压力，我们1000万+的用户全部在一个区里面，虽然我们会定期清理一些用户数据，但是由于游戏数据变化太快，采用mysql传统的通过日志文件实现的主从同步方案已经不可行，因为主服务器会通知从服务器，有什么新的变化了，从服务器会去下载日志，然后同步数据。但是这个日志文件增加和变化实在太快了，主服务器今天的变化，从服务器明天甚至后天都还没有同步到，随着时间的推移，这个差会越来越大，根本无法使用从服务器上的数据，因为上面的数据相当于回档了几天的数据，现在平均是5000次每秒的动态请求，四台PHP FPM服务器，每台开了500个FPM进程，但是DB只有主服务器一台，开了2048个连接数，48G的内存已经使用得差不多了，不能再开连接数了，经常会出现连接数爆表。这个问题不是优化表结构，数据结构和sql查询的问题了，因为玩家数据一般不会涉及到关联查询，都是单表查询，查询全部有索引，数据已经分表，根据玩家ID个位数字分表。99%的请求都能在500ms以内处理完，80%的请求在100ms以内，所以查询优化应该是已经做到一定的值了。请问在这种数据量极大，频繁写，插入，删除的情况下，如何实现多个mysql服务器上的数据的及时同步？来实现可以增加Mysql服务器来解决连接数的问题？
我现在在一个游戏团队中开发，我们现在遇到了一个关于Mysql的棘手的问题，一般普通的新闻网站，这些对同步及时性要求不高的场合都可以用主从同步，读写分离来实现负载的分散，但是对于游戏里面大部分数据都是玩家的任务相关数据，还有道具等数据，这些数据对各服务器之间的及时同步要求非常高，至少应该保持在1秒级别的。但是我们做的游戏放在facebook社交平台上，不像一般的网页游戏，可以通过分区来分散压力，我们1000万+的用户全部在一个区里面，虽然我们会定期清理一些用户数据，但是由于游戏数据变化太快，采用mysql传统的通过日志文件实现的主从同步方案已经不可行，因为主服务器会通知从服务器，有什么新的变化了，从服务器会去下载日志，然后同步数据。但是这个日志文件增加和变化实在太快了，主服务器今天的变化，从服务器明天甚至后天都还没有同步到，随着时间的推移，这个差会越来越大，根本无法使用从服务器上的数据，因为上面的数据相当于回档了几天的数据，现在平均是5000次每秒的动态请求，四台PHP FPM服务器，每台开了500个FPM进程，但是DB只有主服务器一台，开了2048个连接数，48G的内存已经使用得差不多了，不能再开连接数了，经常会出现连接数爆表。这个问题不是优化表结构，数据结构和sql查询的问题了，因为玩家数据一般不会涉及到关联查询，都是单表查询，查询全部有索引，数据已经分表，根据玩家ID个位数字分表。99%的请求都能在500ms以内处理完，80%的请求在100ms以内，所以查询优化应该是已经做到一定的值了。请问在这种数据量极大，频繁写，插入，删除的情况下，如何实现多个mysql服务器上的数据的及时同步？来实现可以增加Mysql服务器来解决连接数的问题？
其实新浪就是用的mysql服务器集群
Transfer是一个主从多线程同步工具，直接patch在MySQL中。2011年开发完成。于去年的12.12上线，并撑住高峰期主从，保证从库无延迟，使得应用能够直接从从库上读数据。看下这个是否合适？