分布式实时数据库在信用控制中的应用

　　 

□ 中国联通广东分公司   罗欣  陈祥

    当前，移动通信正处于迅速发展的时期，移动用户与话务量都快速增长。在同一个计费系统中，对于用户管理、欠费控制的要求越来越高，由此，信用控制越来越发挥着重要的作用。在整个计费平台中，信用控制涉及到许多分系统：如实时计费、营业帐务中心、客户服务中心、银行联网接口、ＨＬＲ控制接口等。信用控制分系统一方面要从计费、营业帐务、银行等分系统上获取相关数据，又要将处理的结果反映到客服、营帐、ＨＬＲ控制等分系统上，它对时间的要求相当高。
    对于提高信用控制的实时性和有效性，从软件、网络、数据库等方面都有很多可以改进的地方。下面我们提出一个实时数据库的思想，它主要是针对实时性要求高的应用。本文主要对此实时数据库进行可行性和有效性的讨论。

一、实时数据库系统
    实时数据库系统主要用在对时间要求很严格的领域，如国防、工业自动化、网络管理等。现在应用到移动通信计费系统中的信用控制，也是基于时间要求的考虑。相对于传统的数据库系统来说，实时数据库系统对于事务处理的时间要求是特别严格的。系统的正确性不仅仅在于数据逻辑结果的正确，还在结果产生的时间上。任何处理的事务都必须在时间限制到达之前完成，而绝大多数数据库系统都没有对实时应用进行专门的设计，或者缺乏对实时事务处理的支持。其实，因为总有不可预见的数据产生，在实时数据库系统中，也不能保证任何时间限制事务的实现，但可以尽量减少这些不能达到要求的事务的数量。
    由于是应用在信用控制方面，分布式的状况又导致了实时控制的复杂性。主要的问题就是，在分布系统中的多个数据库服务器和客户端的通信问题。通信的开销导致远程服务器的响应处理时间变得更加不可预测，这就引出了一个分布式的实时数据库系统（ＤＲＤＢ）的实现问题，下面将重点讨论这一问题。

二、关于时间性问题
    实时数据库系统的主要目标就是尽可能地减少超过时间限制事务处理的情况，调度决策尽可能地依靠事务的属性如优先权、时限等来达到这个目标。在绝大多数调度策略中，运行时间就是一个很难获得的值，将运行时间运用到调度决策中是非常重要的。如果调度进程已经获得了事务处理时间的相关信息，而这些信息又可以用来检测出哪些是最接近时限的事务，那么就可以赋予这些事务更高的优先权，或者将那些不会超时的事务挂起。
    对于实时数据库的考虑也不仅仅是运行时间的估计。在实时数据库系统中，其他任何与数据相关的时间信息都是非常重要的。例如，信用控制中实时帐单结果，都应该按它们发生的时间建索引。一旦进入数据库，在一段时间内，它们还没有被处理的话，那么很可能此数据已经过期，或者成为不重要的数据了。这是因为，新的数据变化可能随时发生。比如，用户可能在营帐中心被更改了属性，在联网银行上交纳了欠费或者预存款，或者新的话单被批价、新的帐单又产生了，原来的数据可能已经不必使用。
    在分布式的数据库系统中，客户端的输入并不能在同一时间内反映到数据库中，或者是由于处理的延时以及通信的开销，都将导致数据的不一致性。与传统的数据库系统不同，时间数据模型的一个显著特征是，数据不是任何时候都要求正确的，而系统对数据的解释具有选择权。

三、分布式实时数据库系统（ＤＲＤＢ）的实现
    ＤＲＤＢ是以客户机／服务器方式来设计的，它具有多个多线程的服务器，支持多个客户端的数据请求。ＤＲＤＢ是数据库管理系统的核心，它不断地接收来自多个客户端的高层数据库访问请求。所有这些请求都是以包的形式进出的，ＤＲＤＢ有两种不同类型的包：呼叫包和返回包，呼叫包在客户端产生，实际上就是数据库事务，它包括数据库访问操作需要的所有信息。一旦命令被传到服务器上，就会进入在服务器上运行的ＤＲＤＢ调度进程。调度进程会通过运行时间估计技术，来检测系统是否能达到规定的时限要求。如果时限要求是可行的，ＤＲＤＢ服务器就会产生一个ＤＲＤＢ线程去执行这个事务；反之，如果时限要求是不可行的，客户端也会被通知，服务器上也就没有线程产生。ＤＲＤＢ线程处理完这个事务后，就会将呼叫包转发回去。这样，即使时限超过了，ＤＲＤＢ的线程也不预先知道，客户端是通过事务处理的结果才知道的。既然ＤＲＤＢ是一个分布式的数据库，客户端可以发送命令去操作远程的数据。作为预处理的一个过程，服务器会先检测这些命令，并找出处理这些命令的各类关系，将这些关系影射到数据库中的关系上，最终找到处理它们的位置。
    对于服务器来说，一个这样的关系表格是在服务器初始化的时候建立起来的。服务器启动时，第一个操作就是从自己的目录中读取相关文件，并把它们储存到关系表格中；然后再读取一个全局地址文件，这个文件中包含了所有正在运行的服务器的地址以及端口。新的服务器会对外发送自己的关系列表，这样其他服务器就更新自己的关系表，并将它们自己的表格发回给新的服务器，最终新的服务器就可以接收客户端的请求了。
    ＤＲＤＢ对每个关系都赋予一个有效时间，这个有效时间和客户端是无关的，而与储存在真实信息模型中的时间表是类似的。客户端并不能修改这些时间属性，这些属性在标识事务的时间一致性要求时起着关键性的作用。
    这里，介绍一个简单语句的例子：ｓｅｌｅｃｔ ｃｏｕｎｔ???ｆｒｏｍ ｄｅｔａｉｌ＿ｒｅｃｏｒｄ＿ｔａｂｌｅ ｗｈｅｒｅ ｖａｌｉｄ ｔｉｍｅ＜１这个例子给了我们一个完全不同于常规数据库的思想，就是上面提到的时间一致性、时间有效性的思想。它会返回ｄｅｔａｉｌ＿ｒｅｃｏｒｄ＿ｔａｂｌｅ这个关系表中，在事务处理完成的最后一秒钟内，被更新或被插入的记录数。ＤＲＤＢ允许系统用户在显示输出、建立或者修改关系时操作的有效时间属性。
    为了实现并发控制，ＤＲＤＢ系统执行了严格两级锁（２ＰＬ）协议。由于在商用系统上的通用性，以及在恢复和避免重迭失败的有效性，ＤＲＤＢ选择了严格两级锁协议。ＤＲＤＢ允许用户发送一系列的命令，并获得这些命令的集合结果。事务处理的功能使ＤＲＤＢ让用户将一系列的命令形成一个原子操作进行处理，这样，ＤＲＤＢ服务器就必须保留所有的结果，直到事务的每个命令都执行完毕。在事务提交的时候，一样也遵循两级锁协议。
    一个ＤＲＤＢ事务有时间限制和计算的要求，而时间限制要求包括释放时间‘ｒ’（或者叫发送时间）和最后期限‘ｄ’。释放时间就是从客户端发送事务的时间；而计算要求是用前面提到的运行时间估计‘ｒｔｅ’来标识，ｒｔｅ包括了处理事务时的通信、ＩＯ、计算的开销；最后期限标识着客户端对事务处理的时间限制要求。
    显然?正常情况下，有这样的要求：ｒｅｌｅａｓｅ ｔｉｍｅ?ｒ? ＋ ｒｕｎ－ｔｉｍｅ ｅｓｔｉｍａｔｅ?ｒｔｅ? ＜ ｄｅａｄｌｉｎｅ?ｄ?。当事务被提交到服务器时，ＤＲＤＢ调度进程可以获得释放时间和最后期限，而运行时间可以基于操作的性能和包含数据的属性计算出来。我们这个系统的目标就是尽可能的减少那些在时间‘ｄ’后完成的事务数目。对于那些超过最后期限的事务，有两种选择处理方式：一是，当估计超时时中止退出。
    这里举一个例子。当进行大批量话单批价处理时，由于要进行实时信用控制，需要对话单进行分类累计如服务号码、合同号码等，但当一批话单数据被提交处理时，要求更新或者建立实时帐单记录。当然批价在不停地进行中，如果前一批数据的部分更新事务超过了期限，那么中止那部分事务会比较合适，可以将它们放在下一批数据更新中去完成，因为事务必然是要重新提交的，而在下一批数据中可能也会含有它们的更新数据。
    当然我们有第二种选择，无论超时与否，所有事务都将被完成。当然这种选择，我们认为是适合银行的金融交易，而不适应实时计费与实时信用控制。如果这些事务要被执行完的话，就涉及到与其他事务的优先权和互锁的问题。
    ＤＲＤＢ的实现方式是两种选择的综合。当一个事务被提交到系统中时，会被检测它是否在执行中会超时。如果超时，就被中止，这样显然节约了在这些事务上的开销。在系统繁忙时期中，允许这些事务进入到系统，显然会影响系统的整体性能；同时，中止一些当前运行的事务，有可能帮助其他一些事务达到它们的时限要求。当一个事务被接收的话，它就会被执行完，这样的方法往往被用来验证调度进程的运行时间估计的有效性。

四、调度策略与运行时间估计
    ＤＲＤＢ的调度算法包含三个部分：决定任务被执行的策略，分配优先权的策略，冲突解决的策略。下面我们对前两种策略进行了一定程度的分析。
    １．调度策略。调度进程在事务进入系统或被中止的时候，会被调用，在事务间资源（数据资源或者ＣＰＵ资源）发生竞争，也会被调用。调度进程的第一个任务是，将准备好的事务分成两个部分，一部分是可以在满足时限的（可行的），另一部分是不能满足时限的（不可行的）。可行的事务必然满足下面的条件：ｃｕｒｒｅｎｔ ｔｉｍｅ?ｔ? ＋ ｒｕｎ－ｔｉｍｅ ｅｓｔｉｍａｔｅ?ｒｔｅ? ＜＝ ｄｅａｄｌｉｎｅ?ｄ?，这种方法也适合于事务已经获得了部分的处理时间，可以改进如下：ｃｕｒｒｅｎｔ ｔｉｍｅ?ｔ? ＋ ｒｔｅ － ｓｅｒｖｉｃｅ ｔｉｍｅ?ｐ? ＜＝ ｄｅａｄｌｉｎｅ?ｄ?。这里的ｐ就是事务积累的处理时间。当由于资源的原因，事务被耽误了，也能被重新估计是否能满足期限要求。这种策略的成功与否在于运行时间估计的准确性，过高估计了计算时间可能导致事务不必要地退出，而过低估计计算时间可能导致系统性能的下降。
    有很多种方法来分配优先权。比如Ｆｉｒｓｔ Ｃｏｍｅ Ｆｉｒｓｔ Ｓｅｒｖｅ?ＦＣＦＳ?，Ｅａｒｌｉｅｓｔ Ｄｅａｄｌｉｎｅ?ＥＤ?和Ｌｅａｓｔ Ｓｌａｃｋ?ＬＳ?。当然ＦＣＦＳ是不适合时限要求的，而ＥＤ策略在某些应用上是高效率的，但又不能进行运行时间估计，ＬＳ是比较适合于ＤＲＤＢ的。
    这里，我们对松弛时间定义如下：Ｓｌａｃｋ?ｓ? ＝ ｄｅａｄｌｉｎｅ?ｄ? － ?ｃｕｒｒｅｎｔ ｔｉｍｅ?ｔ? ＋ ｒｔｅ?。松弛时间越少，就被赋予越高的优先权，如果优先权为负，那么，这个事务就可能不满足时限要求。这种优先权分配方法并没有考虑服务时间，所以说它是静态分配，也就是说，当事务进入系统，优先权已经被决定。当然持续的ＬＳ策略是可以考虑服务时间的，这样，连续的优先权计算就可以在任何时候计算事务优先权。
    ２．运行时间估计。常规的实时系统一般都是处理那些预先有资源要求的事务，通过资源要求可以进行计算开销估计。但是，实时数据库通常处理那些没有预先资源要求的事务、数据的随机访问使调度程序更加复杂化。在调度问题上，运行时间估计是个关键因素，它对负载的均衡、优先权分配、冲突处理和ＩＯ调度都有很大的影响。实际上，ＤＲＤＢ设计一个目的就是得出可信的运行时间估计，并将这些时间估计运用到调度决策中去。在这种方法中，主要利用数据的物理属性（包括关系中的属性类型、数据等）以及数据库操作的类型（比如联合、差集等），来试图推导出运行时间。
    这里有一个例子。在用户的实时帐单表中，如果里面只有一条记录，无疑这时对它进行单独操作的ｓｅｌｅｃｔ语句的运行时间是最短的，运行时间主要包括基本的起始开销如传输命令、预处理、打开关系表格以及从磁盘读取数据等，ｓｅｌｅｃｔ的实际计算开销和基本终止操作（如提供返回结果等）。当帐单表中有５千用户的数据，或者有５０万用户的数据，受影响最大的是对于实际计算的开销了。实际上，系统的负载和数据的冲突（包括ＣＰＵ和ＩＯ等），并不会影响到时间限制，这里说的是事务的时间限制。如果从实时帐单表中查询１万用户的数据时，给定了运行时间１０秒，这时由于关系表被其他高优先权的事务加锁，５秒后解锁，仍然要求这个查询在剩下的５秒时间内完成。
    当然，这里的运行时间估计并不是一个精确的估计，很多原因（比如操作的差异性）都可能导致过高或者过低的估计；我们只是对它进行了初步的描述，要达到具体的可操作要求，就需要在模拟系统上进行大量的实验。而实时数据库正好是可以在模拟系统上进行仿真实验的，在模拟数据库环境下，可以进行多种情况下的性能分析测试。

五、结论
    实时数据库服务器是实时系统的关键组成部分，事务处理都有时间限制，而如果数据没有被及时使用，就可能会无效。也就是说，调度不仅要满足一致性要求，而且要满足时间要求。
    本文描述了一个具有时间功能的关系型数据库ＤＲＤＢ，它具有解决实时系统问题的功能。从实时性的角度出发，由于具备时间一致性和数据一致性的考虑，ＤＲＤＢ可以满足计费系统的实时信用控制要求。在调度策略上的运行时间估计以及数据库操作上的时间一致性要求是这个实时系统的关键因素。ＤＲＤＢ提供了一种在实际操作环境中，进行实时处理的思想。当然，还有相当多关于实时数据库系统的技术问题，需要进行进一步的研究探讨。

原文转自：http://www.ltesting.net