在客户端与服务器端复制数据的注意事项

有时候出于某些特定的原因,需要在服务器端与客户端之间进行数据的同步。如下图所示,某个公司在各地有销售办事处。为了便于管理,在每个销售办事处都设置了SQL Server客户端应用程序。每天晚上总公司的数据库服务器需要与各自的办事处客户端之间的数据进行同步。这主要是通过服务器与客户端之间的数据复制功能来实现的。在SQL Server中有这方面现成的解决方案,实现起来也比较简单。为此对于这个具体的实现,笔者就不做过多阐述了。笔者现在要就讲的是,在设计并实现这个解决方案的时候,需要注意哪些问题。

  在客户端与服务器端复制数据的注意事项

  注意事项一:按计划同步与安需同步要一起实现。

  这个解决方案的关键点就是如何保证客户端与服务器之间数据的同步问题。一般来说,这个同步是有计划的,是自动完成的。如每天晚上12点自动与总公司的数据库服务器进行数据同步。把客户端的数据传递给服务器,然后再把数据库中最新的数据下载下来。这个动作往往不需要手工去干预,只要刚开始设置好,这个同步工作就会自动完成。

  但是,除了可以根据计划来实现同步的话,有时会也需要能够按需来进行同步。如在2009年6月1日晚上11点实现同步后,在6月2日早上7点之前总公司定义好了最新的价格。6月2日以后的价格要按这个最新的价格表执行。此时在总公司服务器处,就需要强制更新各个客户端的价格。这个就在计划之外了。另外需要注意的是,根据计划同步的时候,往往同步的是全部的数据,包括销售数据、库存量、新增加会员信息等等。而按需实现同步的话,往往只是针对特定的表,如销售价格等等。所以在按需同步时,必须要能够实现根据特定表来进行同步。如果在按需同步时,同步不必要的数据,则可能需要比较长的时间。而按需同步往往是用来针对一些特殊的情况,时间比较紧。所以只针对特定的表进行同步,以减少同步的时间,这是非常必要的,也是非常实际的一个问题。

  注意事项二:可以通过多种方式与服务器实现数据同步。

  一般来说,通过VPN隧道在客户端与服务器之间实现数据的复制,这是比较可行的方案。因为在客户端与服务器端之间建立VPN隧道,不仅可以增加数据的安全,而且还可以提高复制的效率。其整个同步过程所花费的时间是比较短的。但是其代价也是比较高的。如果办事处与总公司的位置不是很远,如在同一个城市,则对企业来说,通过VPN隧道来实现客户端与服务器端数据的同步就显得有点浪费。

  所以,在设计这个解决方案的时候,数据库管理员最好能够考虑一下,能否采用其他一些更加便宜的方式来实现同步。如直接通过internet来实现同步。虽然这个方式可能会发生数据泄露的危险,而且速度也比较慢。但是价格比较便宜。对于一般的企业来说,如服装企业在同城设立销售点的话,采用这个方式来实现同步也已经足够了。为此在设计客户端与服务器端数据同步时,数据库管理员需要向客户说明各种同步渠道的差异,并根据客户的要求来实现。而不能够想当然而,认为VPN隧道不错,就采用这个同步渠道。

  注意事项三:设置更新源。

  由于各地的办事处都需要向服务器提出更新的需要。不过为了提高数据的准确性,在服务器上必须能够设置,哪些内容只可以在服务器上进行更新。如通常情况下,产品的价格只能够有服务器来更新。像KFC各地销售的价格都是统一的。所以各地销售点是不能够更新服务器方的价格表。如果需要提价的话,往往是在服务器端调整价格,然后再把这个价格信息强制更新到各地的销售办事处。所以某些数据应当只在服务器方进行更新。

为此,在部署这个方案时,数据库管理员应该协同企业的管理人员,确定到底哪些数据只能够在数据库服务器方进行更新。如果可行的话,数据库管理员还可以给企业一些建议。即可以根据自己的经验,把需要在服务器方进行更新的内容列出来。这些内容有产品基本信息、产品价格、促销方案等等。然后供企业用户选择。这会让企业用户能够更加迅速、准确的选择出相关的内容。当然,如果企业平时管理比较规范的话,那么肯定也有这方面的书面资料。此时对于数据库管理员来说可能工作起来更加的方便。无论如何,在部署这个解决方案时,数据库管理员必须向企业客户确认这方面的内容。不然的话,到时候出问题,数据库管理员可要吃不了兜着走了。

  注意事项三:要多某些记录进行刷选。

  不同的客户端,从同一个表中获取数据,但是其获取的纪录可能是不同的。如一个中式快餐店,在各地办了很多分店。其为了招揽顾客,会不断的推出新的品种。不过新产品刚刚推出的时候,往往只有在几个特定的门店有的卖。企业希望通过这种方式来判断顾问对新产品的接受程度。如果反响好的话,才会在各地的门店中推广。

  这个需求说出来简单,但是在系统的实现上有一定的难度。具体来说,就是要求客户端与服务器之间在进行数据同步的时候,要能够根据门店代码的不同,进行记录的刷选,把某些产品记录过滤掉,以免造成不必要的麻烦。这在SQL Server数据库上也是可以实现的,配置起来不是很复杂。在实现过程中,其难点是管理方面的问题。即企业需要根据实际情况,定义好相关的过滤规则。而企业平时主要是依靠口头管理,缺乏相关的规则。为此在这个规则的定义上,就遇到了麻烦。

  通常情况下,这个流程是各地连锁店自己申请或者有企业总部指定,然后把新产品在这几个门店试卖。从技术的角度来讲,只是在连锁店信息中加入一个字段,然后再过滤条件上加入一个判断条件即可。为此数据库管理员还需要帮助企业确认相关的业务逻辑。往往着是实现这个需求的关键。如果这个业务逻辑定义的比较严格,而且企业会严格执行的话,那么后续基本上不需要调整。而如果企业没有明确的业务逻辑,而纯粹是凭“灵感”的话,那么后续调整可能会比较多。对于这一点,数据库管理员自己不仅需要心中有数,而且还需要向企业说明这个问题,让他们认识到这个事件的严重性。

  注意事项四:必须控制远程站点保持不同步状态的时间。

  为安全起见,相关应用程序还必须控制远程站点保持不同步状态的时间。简单的说,就是当某个客户端在规定的时间内没有进行数据同步(如网络异常导致同步失败),那么该采取什么措施?如可以设置一个宽限期,第一次同步失败后没有关系,但是不能够连续三次同步失败。如果控制的比较严格,如同步失败后,马上就锁住客户端,不允许相关的应用程序再连接到这个客户端。一般来说,对于即时性要求比较高的企业,如彩票行业、银行等等都会有类似的要求。

  可见,当客户端不及时同步该如何处理,这也是因企业而异的。从SQL Server数据库角度来讲,可以设置不同的规则来处理这件事情。如可以即时锁住客户端,也可以给管理员提供警告,或者给与一个宽限期。现在主要的问题是,企业要确定自己所需要的管理方式,并且在短时间内不会改变。然后,数据库管理员就可以根据企业的要求,在数据库客户端与服务器中进行相关的设置。通常情况下,为了数据能够及时的同步,都需要在客户端采取措施控制远程站点保持不同步状态的时间。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值