数据库的分库分表、读写分离和主从复制

1.分库分表

其主要目的是为了解决单库单表数据过多,查询缓慢等问题,解决数据库扩展性问题。切分后也会遇到很多问题(例如:跨库join, 分布式事务等)

分表

分为垂直划分水平划分

垂直划分:
把不同功能,不同使用频率的数据列分别放到不同的表中
例如:把常用的字段放一个表,不常用的放一个表
使用的话是根据具体业务来拆,查询时使用多表联查,可以再配合redis存储

水平划分
垂直切分解决不了大表的瓶颈,如果同一个功能中表的数据量过大,就要对该表进行切分,为水平切分
例如:通过id取模划分,对10取模的话就可以分10张表。

分库:

垂直分库:
按照业务模块来划分出不同的数据库
例如:商场订单模块放主机1中数据库, 商品模块放主机2中数据库。
水平分库:
主要根据数据属性(如商品所属地市, 种类)拆分物理数据库。

分库分表存在的问题:

1.水平分表出现的id自增问题

解决方案:
1.java中的uuid
2.不同数据库步长不同自增
3.通过redis的单线程取到自增的id后加到不同数据库中
4.雪花算法,是通过不同机器的系统时间和机器编号计算的
5.美团的leaf

2.垂直分表出现的多表join,order问题

1.字段冗余(各个表中有相同的常用字段)
2.系统层组装(缓存中台)

3.分布式事务
请转步到我的另一篇文章
分布式事务

2.主从复制

什么是主从复制?有什么好处?

是用来建立一个和主数据库完全一样的数据库环境,称为从数据库;主数据库一般是准实时的业务数据库。从数据库做数据的热备,作为后备数据库,主数据库服务器故障后,可切换到从数据库继续工作,避免数据丢失。保证了数据库的高可用。

主从复制的原理?

1.主数据库有个bin-log二进制文件,记录了所有sql语句。
2.我们的目标就是把主数据库的bin-log文件的sql语句复制过来。
3.让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。

怎么保证主从的一致性?

简单介绍下两种方法:
方法1:在从表中写成功后才返回成功。
方法2: cache中设一个key记录着一次写的数据,然后设置一个同步时间,如果在这个时间内,有一个读请求,看看对应的key有没有相关数据,有的话,说明数据近期发生过写事件,这样key的数据就继续读主库,否则就读从库。

3.读写分离

什么是读写分离?

读写分离 一般有至少两个数据库 一个主数据库,一个从数据库,主数据库用来写操作,从数据库用来读操作。

什么情况下适合读写分离?

读写分离适用与读远大于写的场景,如果只有一台服务器,当select很多时,update和delete会被这些select访问中的数据堵塞,等待select结束,并发性能不高。 对于写和读比例相近的应用,应该部署双主相互复制

读写分离有什么好处?

1.主从只负责各自的写和读,极大程度的缓解X锁和S锁争用(如果读操作被设置为锁的话,Innodb一般不会对select加锁,不管是不是在事务中。)
2.分摊读取。假如我们有1主3从,不考虑上述1中提到的从库单方面设置,假设现在1 分钟内有10条写入,150条读取。那么,1主3从相当于共计40条写入,而读取总数没变,因此平均下来每台服务器承担了10条写入和50条读取(主库不 承担读取操作)。因此,虽然写入没变,但是读取大大分摊了,提高了系统性能。另外,当读取被分摊后,又间接提高了写入的性能。所以,总体性能提高了,说白 了就是拿机器和带宽换性能。

读写分离之后还能优化吗?

1.从库可配置myisam引擎,提升查询性能以及节约系统开销
2.可以在从库启动是增加一些参数来提高其读的性能,例如--skip-innodb、--skip-bdb、--low-priority-updates以及--delay-key-write=ALL。当然这些设置也是需要根据具体业务需求来定得,不一定能用上

你可能感兴趣的:(数据库的分库分表、读写分离和主从复制)