0%

数据库中间件

一般用MySql、PostgreSQL这类开源数据库,存在的问题就是性能差较低。为了提高性能,要对数据库进行拆分。

一、垂直拆分

将一个数据库中表,根据功能不同,拆分成多个数据库。

1581000248(1)
拆分使得单个请求的响应时间增加,但整个服务的吞吐量增加

二、读写分离(实现了读能力扩展)

1581000509(1)
用户查询的时间,要比写数据库的时间要多。所以一个master数据库用于写,多个slave用于读。slave节点的数据可以理解为master节点数据的全量备份。
1581000723(1)
对开发而言

  • 基本读写分离:master写、slaves读
  • 主从数据同步延迟问题:取钱后查看余额是强一致性;发布微博,通知所有关注者是弱一致性
  • 事务问题:一个事务同时包含读写情况。若读时从库,而写是主库,属于分布式行为,本地事务无法控制,属于分布式事务范畴,但非常复杂且效率较低。主流做法是统一走主库,从而保证了本地事务搞定
  • 感知集群信息变更:从库延迟或失败率高,自动隔离;主从切换等

    三、分库分表(实现了写能力的扩展)

    经过垂直分区后的Master/Slave模式在业务表中的数据量很大时,也是极其耗费资源的。所以通过水平分区,将原本一张表维护的海量数据分配给N个子表进行存储和维护。
    1581000974(1)

好处

  • 存储能力的扩展:庞大数据量,磁盘存储有限情况
  • 写能力的扩展:Master/Slave模式只有一个master节点,在高并发情况下,也会成为整个系统瓶颈。

挑战

  • 基本的数据库增删改查:
    希望能想平常写语句那样,需要如下操作
    1581002081(1)
  • 分布式id:不能采取自增情况
  • 分布式事务:比如批量插入4个数据库,保证同时成功、失败等实现,有解决方案,但实现很复杂。
  • 动态扩容

主流数据库中间件设计方案

目的:向开发人员屏蔽读写分离、分库分表等挑战,隐藏底层实现细节,使得开发人员像操作单表那样操作数据。
1581002637(1)

参考:http://www.sohu.com/a/336811296_505827