引言
本文介绍数据库中的架构设计;
通常,单机是无法满足大系统对数据库的读写要求的,必须用集群的方式来解决;
引入集群意味着提升了系统的复杂度,使系统变得复杂和不好维护;
通常采用数据库负载均衡策略、读写分离策略、分库分表策略等加以优化;
负载均衡
扩展性强:当系统要更高数据库处理速度时,只要简单地增加数据库服务器就可以得到扩展;
可维护性:当某节点发生故障时,系统会自动检测故障并转移故障节点的应用,保证数据库的持续工作;
安全性:
因为数据会同步的多台服务器上,可以实现数据集的冗余,通过多份数据来保证安全性;
将数据库放到了内网之中,更好地保护了数据库的安全性;
易用性:对应用来说完全透明,集群暴露出来的就是一个IP(1) 不能够按照Web服务器的处理能力分配负载;
缺点:负载均衡器(控制端)故障,会导致整个数据库系统瘫痪;
读写分离
当读和写的频率相差很多时(ebay的读写比率是260:1),为了提升效率,减少磁盘IO压力,采取读写分离;
实现原理:
数据库服务器搭建主从集群,一主一从、一主多从都可以;
数据库主机负责读写操作,从机只负责读操作;
数据库主机通过复制将数据同步到从机,每台数据库服务器都存储了所有的业务数据;
业务服务器将写操作发给数据库主机,将读操作发给数据库从机;
主从机数据不一致的解决:
数据不一致:当数据写入主服务器后,要在下次同步后才能查询到;
读从机失败后再读一次主机;
关键业务(账号、转账等)读写操作全部指向主机,非关键业务采用读写分离;
分库分表
分数据库
是指按功能模块拆分到不同的数据库,比如分为订单库、商品库、用户库;
join只适用于同一数据库的不同表联合查询,拆分后不同数据库之间无法用join语句进行查询,只能分几次查询;
事务是同一数据库中的概念,要想在不同数据库之间实现事务的回滚,只能用查询log回滚的方式;
成本高,拆分到不同的数据库意味着需要建立多个备份数据库;
分数据库表 - 垂直(纵向)拆分
原先是一个表中包含所有10个字段;
现在将查询频率特别高的字段分离到另外的表中(比如婚恋网站的name, sex, age三个字段),其他字段(如个人介绍destribution等)留在原表;
优点:查询性能提升,如果只查询重要字段,无需将其他字段也查出来,速度很快;
缺点:如果要查出所有字段,必须经过两次查询;
分数据库表 - 水平(横向)拆分
将同一个表的数据进行分块保存到不同的数据库中,这些数据库中的表结构完全相同;
顺序路由:
如可以按订单的日期所在年份分,2003年的放在db1中,2004年的db2,以此类推;
缺点是数据分布不均,可能2003年的订单有100W,2008年的有500W;
hash路由:
对user_id进行hash(或者如果user_id是数值型的话直接使用user_id的值也可),然后用一个特定的数字,比如应用中需要将一个数据库切分成4个数据库的话,我们就用4这个数字对user_id的hash值进行取模运算,决定存在哪个表中;
如果现在想将4个表变成5个表,改变膜值,则所有的数据都需要改变位置,很麻烦;
配置路由:
就是建立一个DB,这个DB单独保存user_id到DB的映射关系,每次访问数据库的时候都要先查询一次这个数据库,以得到具体的DB信息,然后才能进行我们需要的查询操作;
优点:灵活性强,一对一关系;
缺点:每次查询之前都要多一次查询,会造成一定的性能损失;
source: //changsiyuan.github.io/2018/07/17/2018-7-17-Architecture-6
分享&在看