当前位置:Gxlcms > 数据库问题 > MySql的读写分离

MySql的读写分离

时间:2021-07-01 10:21:17 帮助过:8人阅读

  数据量增多,单机的数据库不足以支撑业务,需要用到数据库集群。而读写分离,就是将数据库的读和写分离,对应到数据库一般就是主从数据库,一主一从或者一主多从;业务服务器把数据写到主数据库中,读操作都去从库读;主库会同步数据到从库,保证数据的一致性。

    

技术图片 主从集群

    这种集群方式,就是将访问的压力从主库转移到从库,单机的数据库不能支撑并发读写的时候,而且读的请求很多的情况下就适合数据库集群。如果写的操作很多的话,那就不适合这种集群方式,因为写的时候是写入主库,主库的压力还是没有变化,同时同步到从库也需要消耗资源。

    单机的时候,一般数据库优化就是加索引,但是加了索引对查询有优化,但是写入的时候会有影响,因为写入的数据库不会更新索引。所以在主从数据库中,可以单独的对读库(从数据库)做索引,而写库(主数据库)可以减少缩影而提高写的效率。

    但是主从数据库中需要注意:主从同步延迟、分配机制的考虑

主从同步延迟

    二次读取

      一般操作是,在从库读取数据时,没有读到数据,就去主库进行数据读取。但是这种操作还是将读的压力返还给主库,如果有恶意的攻击,主库就爆了。

        一般情况下,通过对数据库访问的API进行封装就能实现这个功能,业务之间没有耦合。

    写了之后的马上读操作操作主库

       在写了数据后,立马读操作就去访问主库,之后的读操作访问从库,这种业务上会有高度耦合。

    根据业务,将重要的业务数据的读写都放在主库,其他的业务进行读写分离

        类似付钱的这种业务,读写都到主库,避免延迟的问题,但是例如改个头像啊,个人签名这种比较不重要的就读写分离,查询都去从库查。

分配机制的考虑

        分配机制的考虑,就是怎么制定去操作去主库写,去从库读。

      代码封装

        抽取一个中间层,让中间层来实现读写分离和数据库连接。即封装一个provider,包含了对数据的save,query等操作,当save时操作的数据库是主库的,query时操作的数据库是从库。

        实现简单,但是如果如果其中一个数据库宕机了,就需要修改配置重启项目。还有如果有多个子系统的话,语言不一致的话,就会进行重复的开发。

      数据库中间件

        有专门的独立系统来实现读写分离和数据库连接管理,业务服务器和数据库中间件通过SQL协议交流,在业务服务器看起来,数据库中间件就是一个数据库。

        因为是通过sql协议的所以可以兼容不同的语言不需要单独写一套,并且有中间件来实现主从切换,业务服务器不需要关心这点。但是多了一个服务,就会有其他的消耗,难于管理,而且中间件性能要求高,实现复杂,难度高。

        开源的中间件有Mysql Proxy,Atlas。

 

技术图片 数据库中间件

 总结

        读写分离理解和实现相对简单,但是只能减少访问的压力,不能分担存储的压力,当数据增多是,查询的速度还是会很慢。这时候就需要用到分库分表了。

        正常情况下,单机不能支撑业务时,才会用数据库集群,软件设计越简单的设计越好。

        一般数据库的优化是,先优化一些查询操作,然后优化业务的逻辑,或者加入缓存,最后不行再用集群,最后再分库分表。



MySql的读写分离

标签:提高   width   实现   功能   api   auto   tla   接管   存储   

人气教程排行