需求:为什么需要DAL

很多大公司都做了数据访问层的设计,数据访问层的主要功能是让应用程序和数据库进行隔离。对于业务开发者来说,DAL就像数据库一样是透明的。业务开发者接入DAL,不需要了解底层使用什么数据库,不需要了解数据库中的表的分布情况。

我们部门绝大多数的后端都是使用Python开发的,而Python由于GIL的限制,并不能达到真正意义上的多线程,所以需要开多进程来实现并发,恰好因为多进程的原因,链接池并不能进行共享,也不能限制数据库的连接数。如果进程开多了之后,就会导致数据库因为连接数的开销,花费了太多的数据库资源。举个例子,我们的数据后台开了4个服务,每个服务开了15个进程。每个进程由于用了异步,则使用了连接池,每个进程的链接池用了3个连接数。那么连接到数据库的连接数最大会达到180个。加上开发环境,测试环境,单数据后台这一个系统来说,最大需要花费250多个连接数。而这250个连接数顶多在上班高峰期才会全部使用到,这造成了数据库的巨大压力。

其实,在整个系统来说,最多使用到100-150个连接数是最合理的。除了高峰期以外的时间,可以断开数据库连接,减少资源的消耗。那么应对这样的需求,我们则提出了搭建一个DAL的中间件的设置。让所有的后端服务连接一个DAL,让数据库连接数得到最大资源的利用。

DAL的优点

通过仔细分析发现DAL不仅能减少连接数,还有更多的好处,主要分析如下:

  1. 连接池可控制

    连接池可以控制,真如上面所说。这是我们最直接的需求,减少数据库的连接数,让业务开发更简单。也不至于因为业务原因,使得数据库出现资源消耗严重导致业务受到影响。

  2. 数据库和业务分离

    对于数据库的限制和操作,可以放在DAL层做处理。最直接的是 限制并发的查询数,对于断掉的数据库连接,可以集中处理。是得数据库逻辑处理相关代码在DAL得到更专业的处理,让业务开发更加的纯粹,干净。从而达到代码解耦的目的。

  3. 更方便缓存

    可以在DAL层做一些数据缓存。根据我们业务的特点来说,查询比插入,更新多很多,而且绝大多数的数据都是离线的数据,只有等到第二天数据才会得到更新。那么,我们可以通过在DAL中做一层短暂的数据缓存,以缓解数据库的查询压力,对于消耗查询资源的SQL,做特定的更长的缓存。让用户的查询体验更好。

  4. SQL相关的统计分析

    可以在DAL层中做一些统计,将每次查询的SQL和需要的时间保存下来,通过累计的保存,可以对所收集的SQL进行分析,找出耗时最多的SQL进行特定的优化。

设计思路

适配不同类型的数据库: 由于我们的业务需要,我们的数据会从不同的地方获取,比如说GP, PG,Impala和Redis,那么,我们的DAL则需要适配各种不同的数据库产品,而这对于业务开发来说是透明的。业务开发只需要通过函数去调用DAL的服务就好,就能获取到数据。

定期维护连接池:还有就是一个定期维护连接池的需求。部分连接数在长时间没有查询时,我们可以通过将其断开,减少数据库的资源压力。

框架设计

Drive层

Drive层主要是包含各种数据库设备的驱动,目前支持有Postgresql,Impala等驱动,Drive层主要作用是隔离了数据库底层驱动和上层接口。这里规定了实例化一个Drive对象对应的是单个数据库连接。主要处理底层对应数据库的SQL执行,兼容了数据库连接出错的容错处理。

Pool连接池

连接池主要是管理单个数据库的所有连接数,类似于我们常说的数据库连接池一样的存在,主要作用是对连接池的连接数进行动态的扩容和缩减。

管理者

管理者位于连接池上层,主要是用来管理多个不同数据库的连接池。提供了定时清理超时连接的接口。对没有做配置的接口连接进行舍弃。

定时器

定时器主要提供了一个定时清理超时数据库连接的功能。主要是通过起一个线程,定时调用管理者提供的清理超时连接的接口。实现了连接数的自动扩容。

RPC连接

RPC连接主要用于接口调用,这里采用了Thrift作为后端调用的协议,主要好处在于可以让后端通过调用函数的方式调用该接口。

结束语

DAL的整个架构非常简单,采用了很多新的技术,如RPC框架的使用。在实现自动扩容缩减接口的过程中,因为需要用到deque来管理连接数,但是由于deque在pop和append这样的方法中没有实现阻塞的机制,还对deque进行了封装,提供了阻塞的机制。在实现定时器的时候,准备使用threading的Timer的,由于Timer调用时都会创建一个新的线程,这样频繁的调用是挺消耗系统资源的,因为在实现的过程中,则重写了threading的Timer。

其实整个DAL的第一个版本实现了很少的功能,之后的版本中将会加入SQL时间统计,优化更好的日志记录, 实现实时的获取到连接池的状态, 实现更底层的业务连接, 不需要业务修改任何代码就能连接到DAL上。优化还有很多需要做,为实现更好的DAL任重而道远。

以上

发表评论

电子邮件地址不会被公开。 必填项已用*标注