设计数据库集群读写分离并非易事( 二 ) 作者:菜菜出处:灵魂拷问：解决

在binlog的复制过程中，极低的概率会发生binlog还没有来得及刷新到磁盘就出现磁盘坏掉或者down机的情况，最终的效果就是主从数据的不一致，但是这种不可抗拒的因素，一般是可以容忍的。
还有一种现象，一般数据从主节点复制到从节点会开启单线程模式，如果主库产生新数据的速度大于同步的速度，那有可能会进一步加大主从同步的延迟时间，这个是否可以考虑开启多线程或者利用缓存模块来屏蔽同步延迟的问题呢？
主备方案说到数据库主从的架构部署方式，还有一种类似的方案：主备。主备是利用冗余一个节点来做备用节点，但是这个节点在主节点正常运行的情况下，不会对外提供服务，做了一个真正的“备胎” 。当主节点挂掉，备用节点会代替主节点的位置，并成为主节点开始对外提供服务。
主备方式可以利用简单的类似keepalive机制来实现自动化，理论上不需要进行选举操作。利用主备方式来实现数据库高可用有哪些特点呢？

可用性是利用keepalive机制来保证的，这个切换过程对业务是透明的，业务方无需修改任何代码
读写都在主库上进行，很容易产生单点的瓶颈问题，由于没有其他节点的数据同步过程，所以数据可以保证一致性
主备架构中，备库只是单纯的备份，整体的资源利用率50% ，因为备库一直在被闲置
扩展性比较差，无法做到横向扩展，但是可以利用分库分表来解决扩展性问题

一主一备或者一主多备方案在资源的利用率上很低，所以后来出现了多主的架构，多主架构是指，会存在多个主库，每个主库都提供读写功能，这就涉及到多个主库之间数据同步的方式，虽然性能上要比一主要高，但是数据一致性上很难搞。所以很多互联网公司并不推荐使用这种方案。
写在最后数据库的扩展由于其属于有状态的范畴，所以比无状态的网站或者服务要困难很多。现在主流的落地方案也都是基于“分”的策略，分库分表方案和主从读写分离方案是两种最常用的扩展方式，在很多情况下，二者是结合起来使用的，即：在分库分表的情况下，每个节点采用主从读写分离的方式，这也是目前比较主流的方式了。
作者:菜菜
【设计数据库集群读写分离并非易事】出处: