数据库主从问题

参考链接

为什么主从

  • Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。

  • 在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。

为什么分离

  • 因为写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。

问题？

数据库集群,读写分离现在可以说是项目必备的了，但是我们如何保证其每个数据库的数据一致性

主从不同步

半同步复制

原理：主库发生增删改操作时，等待从库及时复制了操作并通知了主库，才会把这个操作认为成功。

优点：保证了数据一致性
缺点：慢

数据库中间件

原理：

所有的数据库操作请求都走数据库中间件，写的请求路由到主库，读的请求路由到从库。当有对某个表/库的写请求过来时设置一个key同时设置一个允许主从同步的时间，假设是1秒。所以在写操作完之后如果立马有个读的请求过来，如果有对应的key，如果时间在1秒内，就到key对应的主库中读数据，否则路由到从库中。

简单来说就是：给中间件一个同步时间，同步时间内读操作落到主库，同步时间外，读操作落到从库。

优点：快，减少主库压力
缺点：同步时间需要经验

缓存记录写Key法

原理：

将某个库上的某个key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如1s

当读请求发生时：
（1）先到cache里查看，对应库的对应key有没有相关数据
（2）如果cache hit，有相关数据，说明这个key上刚发生过写操作，此时需要将请求路由到主库读最新的数据
（3）如果cache miss，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离

优点：相对于数据库中间件的形式相对成本较低

缺点：引入了cache组件，并且读写数据库多了一步cache操作