架构: 数据库架构设计

引言

• 本文介绍数据库中的架构设计；

• 通常，单机是无法满足大系统对数据库的读写要求的，必须用集群的方式来解决；

• 引入集群意味着提升了系统的复杂度，使系统变得复杂和不好维护；

• 通常采用数据库负载均衡策略、读写分离策略、分库分表策略等加以优化；

负载均衡

• 扩展性强：当系统要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展；

• 可维护性：当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作；

• 安全性：

  • 因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性；

  • 将数据库放到了内网之中，更好地保护了数据库的安全性；

• 易用性：对应用来说完全透明，集群暴露出来的就是一个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

分享&在看