1、摘要：本文简要阐述了 Borland 的 MIDAS 的解决方案的 3 个缺点:线程管理能力、数据管理能力、数据库连接管理能力。这些都构成了中间层效能的致命弱点。本文尝试提出若干调节器以改善上述能力。这些调节器的讨论有助于设计者理清中间层的使命，从而使多层架构的设计更科学。如何设计基于 Borland Midas 的三层架构？罗迪平关键字COM,MIDAS,调节器。关于 Borland 的 MIDAS 各处介绍颇多，这里不作概念性的介绍。MIDAS 建立在TRemoteDataModule 上，即建立在 COM+上。在数据库应用中、数据库的并发操作是经常发生的，尤其是在关键任务（如银行、邮政、
2、医院、电子商务等）应用中，所以要设计多层架构的中间层必须满足并发请求的需要。所以 TRemoteDataModule 的模式必须选用多线程的方案。但是，是不是每一个需要 COM 服务的客户都开一个线成为之服务是最好的呢？在非冲突的数据访问的计算任务中是这样的，但在有冲突的数据库访问的时候就不是了。例如客户 C1 要想对表 T1 进行插入，客户 C2 要想对表 T1 进行查询，由于不知道港插入的数据是否在查询的范围，所以主流数据库系统（如 Oracle，MS SQL 等）都在客户 C1 对表 T1 进行插入的时候锁定了整个表或页，客户 C2 必须等待。这时候即使 C1 和 C2 用不同的线程执行
3、也不会提高整体性能，相反还要付出数据库进行调度的代价。由于 Apartment 线程模式只提供了 4 倍于 CPU 个数的线程创建能力，所以TRemoteDataModule 所用的 Apartment 模式也只有 4 倍于 CPU 个数的线程。这样远远不能满足更多用户并发访问的请求。而采用 Neutral 模式了之后，并发访问的 TProvider 就不再是客户独享了，所以所对应的 TDataSet 的状态冲突管理成了令许多程序员头痛的突出问题。一般地的说，客户数=COM 实例数线程数数据库连接数。所以 COM 实例分配到线程需要适当的调节，不幸的是，现有的机制只提供了平均分配的算法，而我们
4、更希望基于 COM 任务负担的分配算法。由于 COM 实例数线程数，所以，在 Borland 的 TRemoteDataModule 上放置数据库连接和 TDataSetProvider 是不明智的，因为多出来的 COM 得不到线程服务（即处理机） ，所以闲置，给数据库造成多余的调度负担和保持网络连接的通讯负担。这样，合理的机制至少需要一个 COM 调节器，一个线程调节器，一个数据库连接调节器。接下来，我们看看 Borland 的 TDataSetProvider、TDataSet 裔（如TTable、TQuery、TADOTable、TADOQuery 等，下仅称 TDataSet）和 TD
5、COMConnection（或TSocketConnection，这还需要一个 Socket 中转的服务器） 、TClientDataSet 搭配的一种情况。当 TDataSetProvider 接上 TDataSet 后放在 TRemoteDataModule，客户端用TClientDataSet 连接 TDCOMConnection（或 TSocketConnection）访问时，TDataSetProvider 从所连接的 TDataSet 得到数据，打包后通过 COM 机制发给TclientDataSet。之后呢？当 TClientDataSet 由最终用户改动后执行 ApplyUpd
6、ates，结果让我们大失所望，TDataSetProvider 所连接的 TDataSet 的数据并不改动！TClientDataSet 通过 CommandText 执行的 SQL 更不用说了,不仅 TClientDataSet 自己的数据不改动（即使该 SQL 修改了本 TClientDataSet 所对应的表） ，TDataSetProvider 所连接的 TDataSet 的数据一点都不改动。换而言之，TDataSetProvider 所连接的 TDataSet 不能和后台的数据库系统数据同步，因而不能循环被多个 TClientDataSet 使用，即，没有缓存数据的作用，所有客户都分
7、别通过中间层从数据库服务器上分别取得数据，而不因为有一个中间层而省了什么。所以，我们不能指望不编写代码就能实现真正的多层架构来提高在不同的网络通讯能力的环境的应用的性能了，Borland 没有提供便利的 MIDAS，只是一个数据代理而已。上述的三点讨论，我们希望的基于 COM 的真正的多层架构至少需要一下要素1 用于管理配置的 GUI 用户接口，2 COM 服务器和客户端，3 多线程，4 数据集，5 数据提供者，6 数据库连接，7 暂存数据的数据集，8 SQL 执行器，9 COM 调节器，10 线程调节器，11 数据集调节器，12 SQL 执行器调节器，13 数据库连接调节器， 14 数据压力
8、指示器，15 商业业务监视处理外挂接口下面对 SQL 执行器和其他 6 个调节器进行讨论。一、 SQL 执行器这里的 SQL 执行器要求能分离两种 SQL 请求，一种是简单的对单一的不易改动的数据表的查询、增加、删除、更新，这一种 SQL 应该由有 SQL 执行器实现，但数据还是来源于数据库，并且和数据库同步更新。至于分布式中间层的同步通过刷新实现。为什么这一功能由 SQL 执行器实现而不是只由数据库实现呢？因为上面所讨论的，中间层应该具有暂存数据集的能力，暂存的数据由中间层加以维护会减少数据库和网络的压力，这才能体现中间层存在的必要性，更何况现在的网络情况大部分是:客户和中间层之间的链路带宽
9、比较大（一般是局域网） ，而中间层和服务器的带宽相对比较窄（一般是距离远的局域网或广域网） ，所以中间层的暂存能力显得非常重要。这种数据在本文简称为数据集。另一种 SQL 是操纵较容易改动的或极易改动的业务相关的表或复杂查询，这样的 SQL 由于涉及分布式修改，各个中间层之间的同步维护比较困难而且开销比较大，所以仍交给数据库服务器实现比较合理。二、 COM 调节器调节 COM 分配给线程。一般来说，在多线程的 COM 中，一个客户连接一个 COM 实例，而多个COM 实例分配给一个线程，开始时采用平均分配策略，当搜集的关于效率数据足够时，把任务轻重不一的客户的 COM 实例分配给一个线程，使得
10、每一个线程的负担趋于平均化。调度的过程可能引起客户离线再重新连接。COM 调节器单独调度，不受线程数目、SQL 执行器数目、数据库连接数目的影响。三、线程调节器基于一段时间的运行后的经验，按照某数学模型创建线程个数。该数学模型应考虑数据集个数、SQL 执行器个数、数据库连接个数对实际执行率的影响，考虑相对 COM 个数，以便减少轮候的时间。线程个数还受数据库连接个数的制约，因为多个线程共用一个数据库连接也会导致执行轮候现象。好的设计应该还有一个线程用于 SQL 后执行（back call）器，这个线程在没有任务时挂起。对于 SQL 后执行器的用途下面讨论。四、 数据集调节器正如上面的讨论，数据
11、集是相对静态的表，例如较少改动的字典对照表（如:省市代码对照表等） ，一般用户以只读模式打开，应用程序管理员（下称管理员）以读写模式打开，并且不经常改变。数据集由设计人员设计时指定，少数可以由管理员指定。数据集调节器主要调节多个 COM 实例分时取用、必要时进行复制以便并发使用。五、 SQL 执行器调节器调节 SQL 执行器的个数。调节 SQL 执行器的个数为:线程数+1 个用于数据集+x 个用于 SQL 后执行器。由于 SQL 执行器的创建和回收都比较容易和开销小，因而多产生几个并不会带来什么不良开销，所以 SQL 后执行器可以随用创建。后执行器是一种在独立线程执行的机制，用于中间层能独立维
12、护错误而不是用户维护错误的情况（例如日志，可以在中间层恢复正常后补增执行）等。后执行器没有效率上的要求。六、 数据库连接调节器一般的安排是:视乎网络和数据库服务器的处理能力设定固定个数的据集连接。一般地说，流行的数据库服务器的多连接调度能力很强，所以尽可能的每一个活动的线程都创建连接。但是，基于网络的考虑，基于分布式应用中终端客户甚多的情况，设计者可能限制中间层连接的个数，于是连接数少于 SQL 执行器，调节器需要平衡 SQL 执行器的负担来分配连接。在这种情况，由于 SQL 执行器的执行受到轮后的影响，从而影响了线程调度器的调度。另一种情况是，当用户对某个表的更新操作（INSERT、UPDATE、INSERT）的时候，数据库锁定了整个表，查询（SELECT）操作就在数据库处于等待了状态，直到上述更新操作完成，数据库连接的利用还要对所操作的表错开。 七、 数据压力指示器向客户报告数据集的传送效率、SQL 执行的耗时等信息。综上所述，设计基于 COM 的 Borland MIDAS 的三层架构解决方案，需要解决 COM 实例、线程、数据集和所操纵的表的冲突、数据同步的问题。
