通知表方案对优势以及二维表对接方案可能存在问题

近些年来，系统的复杂性和先进性增长非常显著。现在对系统的可靠性、可伸缩性和灵活性等的要求要比以前更高，这种需要已经促成了更为复杂的先进体系结构的出现。为了适应这种对更好更快的系统日益增长的需求，<供应商>在对<源系统>系统与<目标系统>对接方案中提供的对接方案使用中间数据库库方式进行对接，并使用通知表传送机制，作为解决这些复杂问题的一种方式。

相比二维表对传的方式，<供应商>通知方案有以下几个优点：

1. 保证数据读取时的完整性
通知表与业务表通过通知ID关联，如果业务数据有主从表关联，<源系统>和<目标系统>程序控制确保先写从表，再写主表，最后写入通知表，保证了数据结构完整性。

二维表对接存在的问题：

为了保证数据的完整性，每行数据有一列标明子项数量，每一次对接扫描都需要额外做一次检查子表是否有足够数据的查询。

2.减少网络请求次数
如果访问中间表需要远程网络操作，网络请求次数将影响到系统业务的响应时间。

正常轮询的步骤为：<源系统>读取通知表，通知表如发现消息，才进行业务表读写操作。通知表无数据不会对业务表进行扫描，不会产生额外的查询。

二维表对接存在的问题：

如果有多个业务表，无论业务表是否产生了业务数据，都必须进行额外的查询。

举例：

场景：

传递发运单主表1条记录，从表有100条发运订单详细

通知表方案：<目标系统>进行发运对接， <源系统>系统读取数据时，仅需要读取通知表1次，通知表有数据，才进行业务处理，判断数据是否传递完毕查询数据库只需要1次。

当<源系统>读取到通知，接下来需要读取1次运单主表，1次订单详细（读取100条）

二维表的优化方案：

二维表的优化方案是将一次业务数据的总长度写入二维表字段，但此方案仍旧避免不了额外操作。

<目标系统>进行发运对接，假设发运订单详细有100条数据，在<目标系统>写入发运对接二维表的时候，假设写入50条时，<源系统>对业务表进行第一次轮询读取，读取1行，从该行得到总行数为100，此时需要再额外查询一次符合订单项的数据有多少行，当查询行数得到50<100时说明未传完，便进放弃并等待第二次请求。

如果业务数据未传完时，每次至少需要进行2次查询后才能判断数据是否传完毕。

当<源系统>读取到通知，接下来需要根据订单ID查询1次订单详细表（读取100条）。

接下来必须执行至少1次删除（按照订单ID），并必须立即将100条写入到备份表，产生100项立即写操作。

3.减少数据库写操作次数
       对于数据库，写操作所需要的时间是读取操作的10倍以上，减少写操作的次数，将能极大地提高数据库的响应能力。<供应商>方案不会在业务处理时进行备份写入操作，而在系统空闲时做写入备份操作，将提高业务高峰单位时间内数据库的处理能力。

二维表对接存在的问题：

二维表读取数据处理完成后，需要立即进行备份写入操作和业务数据删除操作，削弱了业务高峰单位时间内数据库的业务处理能力。该问题如果遇到例如聚划算、双十一等业务高并发情况将更加显著。

举例：

通知表方案：业务表数据处理完成，<源系统>将通知表数据进行备份写操作处理，业务数据暂不处理，<源系统>对业务表采取一天一次备份机制处理已处理的业务数据，将已处理的通知备份表关联的业务数据在非繁忙时期（例如凌晨5点）进行备份，减少正常运营时期的对数据库的读写操作。

二维表方案：业务表数据处理完成，需要立即对业务表数据进行备份写操作和业务数据删除操作，削弱了数据库的响应速度。

基于以上特点，对比传统的表对传的方案，<供应商>方案更适合在远程网络条件下进行。可以有效的减少请求次数及减轻数据库操作压力、加快数据库响应时间。