前面，我写过了一篇替换同步的设想. 在该篇文章中，我使用了分布式缓存的方法替换掉本地缓存的同步。今天我的同事正在为此想法而努力，但是有一个不好消息，就是业务对象太大，有些对象竟然大到超乎想象的地步。我真的很佩服我的同事们，那么严重的问题竟然还能使线上的服务器非常的稳定，大家的实力看来都不错。但是问题没有解决，还得想想怎么解决？
首先，我们需要弄清楚这么大的对象到底是怎么回事？那么如果万一这个对象就这么大？那怎么办呢？我想了一些办法，也和我们的DBA经理讨论了一下，大致有一点方向了，这就是“数据库复制”。
关于数据库复制的概念和使用办法去看数据库的帮助文档。这边主要讲怎么使用复制替换同步。还是回到我们的原点，为什么要同步？因为本地缓存的副本不一致？使用分布式缓存，就是减少副本数量，当副本只有一个的时候肯定就不需要缓存了。那么如果对象很大，分布式缓存就有点得不偿失了？那么怎么办？已经想到了减少缓存副本数量，就不能彻底删掉缓存吗？
答案是可以。使用读写分离，主-从方式。看看如下的架构图：
这种架构就可以实现“无缓存高负载”。很多人看见这个架构都会觉得成本比较高？其实差不多的？关键是读的数据库是一个集群，机器配置差一点没关系，这个地方是用数量取胜的，不是质量？但是写的数据库要稍微好一点就行了。那么这种结构就会牵涉到一个数据同步问题，其实这个问题的解决办法很多，有专业的第三方工具，不过一般都是分析数据库的log，然后分别在读的数据库上执行；以前我也做过一个事业单位的项目，他们使用的IPSAN+Riad；你也可以使用数据库的复制分发功能。
这个里面应该是IPSAN+Riad最贵，而且扩展性最不好；第三方软件第二，扩展性不错，贵啊。数据库的复制分发功能最好，便宜，性能也不错，而且可以设定数据筛选条件，真是架构设计，功能实现的居家必备良药啊。