服务端与客户端的数据双向同步设计问题

[bfqyvek]

一套连锁系统,采用C/S结构,要使服务端与客户端的数据双向同步更新\操作等设计,客户端也有数据库.现要求服务端与客户端的数据互同步操作;
从客户端到服务端可做触发器与服务器进行数据同步.
但如从服务端到客户端,服务端如何操作客户端数据.数据如何同步呢.


望各仁兄,能提供建议\例子等等相关的方法.谢谢

顶者有分!!!

[bfqyvek]

kk706,单向是可以了.双向如何做呢

[jamesfay]

SQL Republication

[bfqyvek]

jamesfay ,我是要实现双向的啊.
从客户端到服务端是没有问题.

问题是,从服务端到客户端,服务端如何让客户端也实时更新数据.

[zccmy22]

webservice

[hanjun1024]

可以使用Remoting，双向听事件。

[bfqyvek]

楼上的兄弟,用webservice,如何实现双向?能说一下吗.

从客户端到服务端是没有问题.主要是从服务端到客户端,服务端如何让客户端也实时更新数据.

[hanjun1024]

webservice是被动的，要双向有难度，能想到的办法只有客户端定期轮询服务器。Remoting可以实现事件，这样就能双向了。

[bfqyvek]

hanjun1024 ,用客户端定期轮询服务器,就不能实现实时数据同步了.

达不到要求啊.现在的客户要求双向数据同步.我找不到好的解决办法.

望各仁兄,给些建议与相关资料解决方法.相类似的都行.谢谢!

[九章落地]

客户端通过触发器,把数据传输到服务器的方式不可取。若客户端与服务器之间的网络不顺畅，或者数据量太大，客户端的用户体验会比较差，而且数据的完整性也得不到保障。例如，等半天都没完成一份单！

较为可行的方法是,开发一个独立的EDI程序,负责服务器数据库与客户端数据库之间的数据交换.
1.数据交换EDI程序,可以选择Ftp或WebService作为数据交换技术.

2.服务器的数据改动后,由EDI定时(如每融10分钟)抓取相关单据以xml文档或其他文档的形式导出,导给客户端数据库.

3.客户端亦有一个EDI程序,定时导入服务器发出的相关单据,并把客户端的数据导出给服务器。


分布式架构的系统，若不设计一个健壮的数据交换组件，后期的维护必定付出沉重的代价!

[bfqyvek]

谢谢ydsunny的建议;

由EDI定时(如每融10分钟)抓取相关单据以xml文档,这样的话,会不会每次都要对比整个数据库,进而选择有更新的数据.
如果这样,不是加重服务器的压力吗.如时间隔久,数据又不够准确,时间短的话,服务器压力大?

像这样情况.有没有更好的解决方式呢?

[bfqyvek]

还有兄弟有其他解决办法吗?

[yzlxy]

绝对的实时同步是做不到的。

网络是随时可能发生断网情况的，一旦断网，当前事务如何处理、如何续传又是一套复杂的程序

ydsunny 的方案应该是应用的比较多的一种


对于客户端：保证客户单交易模块的稳定、快速是首要考虑的。

可以采取Xml进行数据缓存。

客户端每发生新单据，则保存到客户端数据库，同时写入到待交换的xml文档中

定时器发生后，提交该xml文档， 如果此时因为断网、服务器繁忙等原因超时响应，则退出交换，保持该文档，

新数据继续存入到这里， 待下一轮定时器发生后再提交。

如此轮训，一旦提交服务器成功，就清掉当前xml文档，以便存放新单据。


至于服务端向客户端同步，也是同理

迄今为止，所有的网络协议都是请求/应答式的，此时服务器就是客户端，客户机就是服务器

所以C/S两端都要有EDI服务程序来响应请求

[yzlxy]

绝对的实时同步是做不到的。

网络是随时可能发生断网情况的，一旦断网，当前事务如何处理、如何续传又是一套复杂的程序

ydsunny 的方案应该是应用的比较多的一种


对于客户端：保证客户单交易模块的稳定、快速是首要考虑的。

可以采取Xml进行数据缓存。

客户端每发生新单据，则保存到客户端数据库，同时写入到待交换的xml文档中

定时器发生后，提交该xml文档， 如果此时因为断网、服务器繁忙等原因超时响应，则退出交换，保持该文档，

新数据继续存入到这里， 待下一轮定时器发生后再提交。

如此轮训，一旦提交服务器成功，就清掉当前xml文档，以便存放新单据。


至于服务端向客户端同步，也是同理

迄今为止，所有的网络协议都是请求/应答式的，此时服务器就是客户端，客户机就是服务器

所以C/S两端都要有EDI服务程序来响应请求

[yzlxy]

绝对的实时同步是做不到的。

网络是随时可能发生断网情况的，一旦断网，当前事务如何处理、如何续传又是一套复杂的程序

ydsunny 的方案应该是应用的比较多的一种


对于客户端：保证客户单交易模块的稳定、快速是首要考虑的。

可以采取Xml进行数据缓存。

客户端每发生新单据，则保存到客户端数据库，同时写入到待交换的xml文档中

定时器发生后，提交该xml文档， 如果此时因为断网、服务器繁忙等原因超时响应，则退出交换，保持该文档，

新数据继续存入到这里， 待下一轮定时器发生后再提交。

如此轮训，一旦提交服务器成功，就清掉当前xml文档，以便存放新单据。


至于服务端向客户端同步，也是同理

迄今为止，所有的网络协议都是请求/应答式的，此时服务器就是客户端，客户机就是服务器

所以C/S两端都要有EDI服务程序来响应请求

[yzlxy]

绝对的实时同步是做不到的。

网络是随时可能发生断网情况的，一旦断网，当前事务如何处理、如何续传又是一套复杂的程序

ydsunny 的方案应该是应用的比较多的一种


对于客户端：保证客户单交易模块的稳定、快速是首要考虑的。

可以采取Xml进行数据缓存。

客户端每发生新单据，则保存到客户端数据库，同时写入到待交换的xml文档中

定时器发生后，提交该xml文档， 如果此时因为断网、服务器繁忙等原因超时响应，则退出交换，保持该文档，

新数据继续存入到这里， 待下一轮定时器发生后再提交。

如此轮训，一旦提交服务器成功，就清掉当前xml文档，以便存放新单据。


至于服务端向客户端同步，也是同理

迄今为止，所有的网络协议都是请求/应答式的，此时服务器就是客户端，客户机就是服务器

所以C/S两端都要有EDI服务程序来响应请求

[yzlxy]

绝对的实时同步是做不到的。

网络是随时可能发生断网情况的，一旦断网，当前事务如何处理、如何续传又是一套复杂的程序

ydsunny 的方案应该是应用的比较多的一种


对于客户端：保证客户单交易模块的稳定、快速是首要考虑的。

可以采取Xml进行数据缓存。

客户端每发生新单据，则保存到客户端数据库，同时写入到待交换的xml文档中

定时器发生后，提交该xml文档， 如果此时因为断网、服务器繁忙等原因超时响应，则退出交换，保持该文档，

新数据继续存入到这里， 待下一轮定时器发生后再提交。

如此轮训，一旦提交服务器成功，就清掉当前xml文档，以便存放新单据。


至于服务端向客户端同步，也是同理

迄今为止，所有的网络协议都是请求/应答式的，此时服务器就是客户端，客户机就是服务器

所以C/S两端都要有EDI服务程序来响应请求

[bfqyvek]

谢谢各位兄弟

[yzlxy]

晕，提交页面出错了，怎么发了这么多次，

请版主过来处理一下，只保留一份


楼主的问题有没有解决？

[yagebu1983]

看了这么多人的留言！！
学到很多东西！！

[Merfs]

我们公司刚开发一款数据库同步软件，sqlserver与sqlserver同步更新，双向同步，
内网一台SQL ,外网固定IP一台SQL，A更新，B也更新，B更新了，A也同步更新，不会死循环，支持断网保存数据,ftp软件同步文件
有需要可以联系我：地址：深圳 email:[e-mail] 15818710282