WebSphere JDBC Adapter 入站服务性能调优

核心提示：概述JDBC Adapter（简称 Adapter）入站服务被广泛应用于需要对数据库中业务数据表进行监控的企业应用集成中，由于企业应用的规模不同，WebSphere JDBC Adapter 入站服务性能调优，对 Adapter 入站服务的性能要求也不同，如何配置 Adapter 入站服务以提高 Adapter 处理事

概述

JDBC Adapter（简称 Adapter）入站服务被广泛应用于需要对数据库中业务数据表进行监控的企业应用集成中。由于企业应用的规模不同，对 Adapter 入站服务的性能要求也不同，如何配置 Adapter 入站服务以提高 Adapter 处理事件的性能在实际应用中极其重要。本文将全面介绍如何通过调整 Adapter 入站服务配置，以满足各种企业集成中对 Adapter 入站服务的性能需求。

JDBC Adapter 入站服务简介

JDBC Adapter 是符合 J2CA 规范，运行在 WebSphere Process Server 上的，提供各种数据库厂商与应用程序间连接的适配器。Adapter 使数据库和应用程序间拥有双向连接的能力，包括从应用程序到数据库的出站连接能力，以及从数据库到应用程序的入站连接能力。使用 Adapter 的入站服务，应用程序可以监控数据库业务数据表的变化，因此被广泛应用于各种以数据库为中心的企业应用的集成整合中。图 1 展示了典型的 Adapter 入站服务的基本工作原理。各种构建于数据库之上的应用程序，按已有应用程序的业务逻辑向业务数据表写入数据。Adapter 利用事件触发器（Trigger）或者各种数据库特有的事件通知机制，比如 Oracle 数据库的 DBMS_NOTIFICATION 程序包，透明的监控各种应用程序的业务数据变化，并将事件缓存于事件记录表中。部署于服务器的 Adapter 入站服务定期轮询事件记录表并将新发现的数据库事件传送给处理事件的模块。

图 1. JDBC Adapter 入站服务基本工作原理

查看原图（大图）

除了提供基本的入站连接能力， Adapter 为数据库事件监控提供了完善的事件转发保证、数据一致性、事务性支持，可以确保业务数据事件被安全正确的处理。在实际应用中，由于业务规模不同，系统对业务数据事件处理的性能要求各异，为此 Adapter 提供了丰富的性能配置选项，以满足各种应用程序对事件处理的性能需求。本文将在后续章节中详细介绍 Adapter 各种性能选项。

调节基本性能参数

Adapter 提供了两个基本的性能参数可以方便的调节 Adapter 的事件处理能力。在 WebSphere 集成开发环境中，用户可以在 Adapter 入站服务接口的 属性视图 下的 端点配置 下的 高级激活属性 配置中找到这两个参数的配置项，如图 2 所示。

图 2. JDBC Adapter 基本性能参数配置

轮询周期之间的时间间隔 是指每次轮询事件表的间隔，它以毫秒为单位，默认时间间隔为 2000 毫秒。轮询周期中的最大事件数 是指每次轮询提取的最大事件数，默认最大事件数位为 10 。轮询间隔越小， Adapter 的平均事件处理能力越强，而每次轮询事件数越大， Adapter 的平均事件处理能力越强。

默认配置下每秒钟 Adapter 最多能处理 5 个业务数据事件，这对于事件处理能力要求较高的应用显然是不够的。我们可以通过适当降低 轮询时间间隔 以及提高 轮询事件数 来提高 Adapter 的事件处理能力。对于突发事件较多而平均事件数量较少的系统，我们可以适当增加 轮询事件数 并延长 轮询时间间隔，以达到大的突发事件处理能力，并且减少事件较少时对数据库压力。而对于事件数量随时间较均匀分布的系统，我们可以适当减少 轮询时间间隔 以增加事件处理能力并减少事件延迟。

选择事件交互类型

Adapter 事件交互 是指当入站服务发现事件后如何将事件传递给接收事件的模块。Adapter 入站服务与接收事件的组件间有两种交互样式，同步交互 和 异步交互，如图 3 所示。

图 3. JDBC Adapter 事件交互方式配置

同步交互 是指当 Adapter 传递完当前事件后，等待事件处理组件处理完事件后再继续传递发送余下事件。异步交互 是指当 Adapter 传递发送事件后，不等待接收事件的组件处理事件，而是在确认事件发送后，马上继续传递剩余事件。

对于单个事件处理时间较长的系统，异步交互 能够使 Adapter 入站服务达到更大的事件传递发送吞吐量。如果使用 异步交互 方式， Adapter 传递事件后，事件的后续处理的可靠性由应用服务器（WebSphere Process Server）保证；而如果使用 同步交互，如果事件处理失败，Adapter 会马上收到通知，并可以将相应事件记录标记为处理失败，系统管理员可以查询到失败事件，并且根据实际情况决定是否重新提交事件，因此同步交互事件处理会有更高可靠性。在实际应用中，用户应该根据系统的实际需求选择使用合适的事件交互类型。

选择事件传递类型

Adapter 入站服务的 事件传递 类型是指当 Adapter 从事件表中取到多条事件记录后，以何种工作方式将事件传递给接收事件的模块。它是影响入站服务处理能力的重要选项，如图 4 所示 Adapter 提供了三种事件传递类型。

图 4. JDBC Adapter 事件传递类型配置

查看原图（大图）

ORDERED 是指 Adapter 严格按轮询到的事件顺序处理各个事件，它可以确保事件处理的有序性；UNORDERED 是指 Adapter 不会严格按轮询到的顺序处理事件，而会启用多个线程并发处理轮询到的事件，因此可以明显提高 Adapter 的事件处理能力；ORDEREDBYKEY 是指 Adapter 将事件按业务数据主键分组，相同业务数据主键值的事件将被分为相同组，不同组间并发发送，而相同组的事件顺序发送。

ORDERED 和 UNORDERED 是最常使用的两种事件传递类型。 Adapter 默认使用 ORDERED 传递类型，Adapter 在 ORDERED 传递模式下，仅使用一个线程处理事件，因此可以确保事件处理的有序性。但如果单个事件处理时间较长，那么无论如何配置 轮询时间间隔 及 最大事件数，也难以提高 Adapter 事件处理的能力。此时，如果系统对事件处理的顺序没有严格的要求，可以选择使用 UNORDERED 事件传递类型。UNORDERED 事件传递类型的工作原理，如图 5 所示。

图 5. JDBC Adapter UNORDERED 事件传递类型工作原理

查看原图（大图）

当使用 UNORDERED 传递类型时， Adapter 仍会使用一个连接来轮询事件表，但会并行处理轮询到的事件。因此，如果服务器事件处理组件的并发处理能力较强，采用 UNORDERED 传递类型可以显著提高 Adapter 的事件处理能力。

当使用 UNORDERED 传递类型时 Adapter 自身会维护一个连接池，并使用 WebSphere 应用服务器提供的标准 J2EE 组件 WorkManager 作为工作线程池提供者。Adapter 向 WorkManager 提交 工作（Work） 前先从连接池中获取一个连接，WorkManager 管理的线程会并行的处理接收到的 工作，当 工作 被处理完成后，Adapter 会收回工作者线程中的连接，因此每个工作者线程会占用一个连接。通过配置事件处理的连接数用户可以直接控制事件处理的并发数，如图 6 所示。

图 6. JDBC Adapter 连接数配置

需要注意的是，这里的连接是指由 Adapter 管理的连接，并不等同于一个数据库连接，当使用预定义 DataSource 作为数据库连接提供者时，每个连接除了固定占用一个数据库连接外，在处理事件中还需要动态的获取一个额外的数据库连接来操作事件表，以保证事件表操作的事务独立性。因此此时要保证 Adapter 入站服务正常运行，需要确保 DataSource 中有足够的数据库连接资源。我们将在介绍数据库连接类型信息选择时详细介绍各种数据库连接方式的工作方式及资源需求。

另外，由于 Adapter 使用 WorkManager 作为事件传递的线程提供者，因此需要确保 WorkManager 中有足够的线程资源用于事件传递。WorkManager 的配置如图 7 所示：

图 7. WorkManager 的配置

查看原图（大图）

在图 7 中，DefaultWorkManager 一共有三种作用范围，分别是 Cell，Node，Server，他们分别作用于 Cell，Node，Server 之上。但是这三种作用范围的 DefaultWorkManager 所对应的线程池都是 Default 线程池。Default 线程池的配置见图 8。

图 8. 线程池的配置

查看原图（大图）

图 8 中显示 Default 线程池 最小线程数 为 20，最大线程数 也为 20。这个线程池的 最大线程数 决定着入站服务所能达到的最大的并行处理能力。如果 WorkManager 启动的线程总数超过 最大线程数，WorkManager 将不会再为接收到的 工作 产生新的线程，因此接收到的 工作 将会暂时阻塞等待。很可能出现这种情况，当选择 UNORDERED 事件传递方式，同时 UNORDERED 允许的最大连接数设置为 30，那么理论上 Adapter 最大允许 30 个线程并发处理事件，但是实际情况是最多只有 20 个并行线程在处理事件，这是因为 Default 线程池的最大允许线程数为 20，所以虽然同时提交 工作 为 30 个，但真正并发执行 工作 的线程只有 20 个，其他工作则阻塞等待。此时可以更改 Default 线程池的配置增加线程池的大小，如图 9 显示：

图 9. 线程池的属性配置

查看原图（大图）

选择数据库连接类型

Adapter 自身会管理、维护到数据库的连接。数据库连接类型 是指 Adapter 入站如何创建数据库连接。Adapter 入站服务可以选择两种创建数据库连接的方式，如图 10 所示。

图 10. JDBC Adapter 连接类型配置

指定数据库连接信息 是指通过在激活属性中指定连接数据库的 URL，驱动程序类等信息来创建数据库连接；指定预定义 DataSource 是指通过在激活属性中指定服务器中预定义的 DataSource 来指定数据库连接提供者。

如前文所述，如果使用 UNORDERED 事件传递类型，Adapter 内部会创建独立的连接池以重用具有传递能力的入站连接。这样可以显著降低入站连接的创建开销，提高 Adapter 性能。当采用指定数据库连接信息方式创建数据库连接时，Adapter 会使用内部连接池独立管理、重用数据库连接资源。而如果使用预定义 DataSource 作为数据库连接方式，Adaper 将与 DataSource 一起联合管理数据库连接资源。

对于 指定数据库连接信息 的数据库连接类型，每个入站连接占用一个数据库连接；而对于 指定预定义 DataSource 的连接类型，每个入站连接除了固定占用一个数据库连接外，为了保证对事件表操作的事务独立性，每个入站连接在传递事件时需要动态的向 DataSource 申请和释放连接。因此，假设用于事件传递的最大连接数是 N，那么采用 指定数据库连接信息 时 Adapter 最大需要创建 N 个数据库连接；而当使用 指定预定义 DataSource 时，DataSource 中最大连接数必须大于 N+1，Adapter 才能正常工作。由于每次事件传递，Adapter 需要从 DataSource 中动态申请和释放数据库连接，为此 Adapter 需要额外的性能开销。因此对于 Adapter 入站服务，采用 指定数据库连接信息 作为数据库连接创建方式会占用更少资源且有更好的性能。

配置多个 Adapter 共同处理事件

为了保证事件处理的正常工作，一个 Adapter 入站服务只能在一个节点中被激活，这在某些大型应用中可能会成为事件处理的性能瓶颈。Adapter 可以支持多个入站服务同时轮询相同事件表，并发处理业务数据事件。其原理如图 11 所示。

图 11. 多个 JDBC Adapter 入站服务并行工作原理

查看原图（大图）

分布在多台服务器中的多个入站服务，或者多个入站服务分别在集群环境中被激活，他们独立并行的工作，并且轮询相同事件表；当轮询到事件记录后，多个入站服务同时并行的传递服务；事件可以直接传递至事件处理组件，或者先传递至队列，然后由队列转发至事件处理组件。通常这种工作方式适用于系统对事件处理的吞吐量有非常高的要求，而事件处理逻辑复杂单个事件处理事件较长，仅有一个入站服务难以满足要求的应用场景。由于多个入站服务并行工作，这种工作方式可以使得系统整体事件处理能力得到极大提高。但为了避免不同入站服务同时处理相同事件记录导致事件重复发送或者导致事件处理并发异常，需要恰当的配置入站服务以确保不同入站服务处理不同的事件记录。基于适配器实例的事件过滤属性是 Adapter 为这种多个入站服务同时工作所提供的支持。它和产生事件的触发器一起灵活配置以达到多个入站服务的负载平衡。比如典型应用中，事件表的主键 EVENT_ID 是一个均匀分布的自增长序列，因此可以利用 EVENT_ID 使得事件均匀分布于不同适配器实例，以达到不同适配器实例处理不同事件且不同入站服务达到的负载平衡的目的。假设，如图 11 所示，共有三个入站服务同时工作，那么代码列表 1 给出了如何在 Oracle 数据库中编写触发器以利用 EVENT_ID 的特性，使事件均匀分布于各个入站服务中的 SQL 代码示例。

清单 1. 触发器示例

create　or　replace　
TRIGGER　CUSTOMER_EVENT_DELETE　AFTER　DELETE　ON　CUSTOMER　
REFERENCING　OLD　AS　O　NEW　AS　N　
FOR　EACH　ROW　
declare　
p_event_id　number;　
p_conector_id　varchar(10);　
BEGIN　
select　event_seq.nextval　into　p_event_id　from　dual;　
select　'00'||(mod(p_event_id,　3)　+　1)　into　p_conector_id　from　dual;　
INSERT　INTO　wbia_jdbc_eventstore　(event_id,　object_key,　object_name,　
object_function,　event_priority,　event_status,　connector_id)　
VALUES　(p_event_id,:O.pkey,　'SampleCustomer',　'Delete',　1,　0,　p_conector_id);　
END;　

我们可以在 WebSphere 集成开发环境中为不同入站服务配置不同事件过滤适配置实例，如图 12 所示。

图 12. 配置 JDBC Adapter 事件过滤适配器实例

查看原图（大图）

假如我们为入站服务 1 配置 用于事件过滤适配器实例 为 001，为入站服务 2 配置 用于事件过滤适配器实例 为 002,，为入站服务 3 配置 用于事件过滤适配器实例 为 003；因此不同入站服务可以互不干扰的并行的处理相同事件表，使得系统的事件处理能力得到极大提升。

在实际应用中，用户可以根据应用需求，利用 Adapter 入站服务特性并结合数据库触发器、事件表等灵活配置以实现多个入站服务并行工作。

总结

表 1. 影响 JDBC Adapter 入站服务性能的因素

名称	对入站服务的性能影响
轮询周期之间的时间间隔	轮询间隔短入站服务事件处理能力越强，默认值为 2000 毫秒
轮询周期中的最大事件数	最大事件数越大入站服务事件处理能力越强，默认值为 10
事件交互类型	共支持两种交互方式同步交互及异步交互；异步交互有更好的性能，同步交互则有更高可靠性。
事件传递类型	共支持三种事件传递类型 ORDERED、UNORDERED、ORDEREDBYKEY；ORDERED 可以保证事件顺序传递，一般用于对性能要求不高的场合；UNORDERED 不能严格保证事件顺序传递，但有更高性能，一般用于对性能要求较高场合，但需要保证服务器有足够资源。ORDEREDBYKEY 可以保证相同 KEY 值事件有序发送，不同 KEY 值事件并发发送，是介于 ORDERED 和 UNORDERED 间的事件传递类型。
数据库连接类型	入站服务支持两种连接方式指定数据库连接信息及指定预定义 DataSource；指定数据库连接信息占用资源较少且有更好性能。
部署方式	Adapter 支持多个入站服务并发处理相同事件表，但需要保证不同入站服务处理不同事件记录。

表 1 总结了本文介绍的影响 Adapter 入站性能的所有因素。实际应用中可以根据业务需求合理利用这些参数已达到系统对入站服务的性能需求。