我是这样作的，大家挑挑在这个过程中都犯了哪些错误以及改进意见

现实场景：有一个系统挂在互联网上，用来采集企业的档案，每个档案可以由总局采集，也可以由区县局录入该区县的企业，每个企业档案对应一个主表和二三十张子表组成。问题就出在，有些区县局上不了网，但是也需要录入数据，所以决定把该外网系统采集档案这块业务单提出来做一个单机版系统，表结构和网络版一样，就是把系统移植到tomcat和access数据库环境下，打成一个安装包，给区县局安装采集。至此一个系统被切分成了外网系统和单机版系统两部分，那就产生一个大问题，数据同步，安装好的单机版需要在联网情况下下载用户信息和该区县的企业记录，之后断网随意操作，什么时候想提交公网系统了，连接互联网，提交新档案和旧档案的修改。

问题来了：
上面描述了问题场景，问题就在于数据同步，单机版肯定不能直接拿到互联网系统数据库的连接，所以需要把上传的企业信息取出来，拼成xml传过去，在另一端解xml插入数据库。
我当初第一个想法：服务器端坐一个servlet，客户端用httpUrlConnection往http请求的body写数据给服务器端，但是httpUrlConnection的问题是无法跳过登陆验证，每次访问这个servlet都返回登陆页面。
我改变了想法：自己写一个socket，监听8860端口用于数据同步（我以后不会这么干了，因为监听这个端口完全是我一意孤行，客户很可能只允许开80端口，后来我庆幸不是），我每次电击“下载”，都先往服务器发一个请求并传一个该区县的id，服务器查询企业表将该区县的所有企业id和名称传给客户端，这样客户端可以查看当前哪些企业可以下载，然后点击确认。开始下载，我每个企业下载单独开了一个ajax线程，用xmlhttprequest发送请求给一个servlet这个servlet向远程socket发送请求并得到xml串，解析串插入数据库，返回true给ajax请求，页面上则在该企业名称后面打勾，这样看起来像是一个以企业为单位的伪进度条。
每个请求，在服务器端开启一个线程查询-〉拼串-〉返回，20多张表数据拼成一个巨大的xml串传给客户端，同时这个企业也肯能存有附件，对于附件的处理，我总希望它和其他数据保持一致性，所以我将附件的二进制码用base64编码生成一个字符串拼在一个xml的标签里。
下载过程和上传过程一样刚好相反。

这样做的目的:
1、不是表对表的同步，而是以企业为单位同步，保证数据完整性，不会出现一个企业同步一半的情况。
2、客户端和服务器端同步的表、字段可以随意修改，同步很容易适应表的变化。
3、由于当初不懂serverpush方法，则用每个企业一个请求来实现看似是进度条的东西，加强用户体验。

遇到困境：
1、在第一个版本中，大概有500家企业每个企业9个表的数据，下载流畅。但是后来修改版本，企业4000家，每个企业对应20多张表，在同步到200多的时候发现出现请求莫名其妙中断的情况，考虑可能某一端线程太多导致多余线程没有执行。
2、4000家时候，我在ajax端坐了线程池，查看池里的xmlhttprequest是否状态ready，如果ready就用，如果不存在ready的创建一个新的放入池中，但是执行时候报浏览器脚本缓慢。

我总结过程中犯的错误：
1、不该擅自开新端口监听
2、我该在服务器端也做一个线程池

评论

4 楼 unsid 2009-01-23  

regular 写道

2001年的时候做过类似的工作。当时是因为客户的11个门店使用MODEM上网，因此希望尽量减少上网费用。对任一门店做到的离线修改数据，然后很短时间对所有门店数据进行在线同步。 我当时在各个门店计算机上用Access数据文件，中心服务器用SqlServer。 做法是，离线时把客户端的每一次数据库更新操作都变成一个表名ID+字段名+字段值;...的字串，保留在历史表。在线的时候上传下载历史表信息。中心端的数据库仅有一个历史表。每个客户端负责根据历史数据更新30几个表的信息。 这样做，即使是MODEM，每秒也能传递100条历史数据。而且客户端可以记住上次更新到第几个历史记录，下一次连线的时候仅仅从这个记录开始继续读。大概一个月新增3万条记录。 项目做得很成功，客户很高兴。领导很满意。 当时没用任何值得炫耀的新技术。不过自认为方案设计的挺合理。

在这个项目中充分体验到了前期考虑不够带来的后果

3 楼 regular 2009-01-23  

2001年的时候做过类似的工作。当时是因为客户的11个门店使用MODEM上网，因此希望尽量减少上网费用。对任一门店做到的离线修改数据，然后很短时间对所有门店数据进行在线同步。

我当时在各个门店计算机上用Access数据文件，中心服务器用SqlServer。

做法是，离线时把客户端的每一次数据库更新操作都变成一个表名ID+字段名+字段值;...的字串，保留在历史表。在线的时候上传下载历史表信息。中心端的数据库仅有一个历史表。每个客户端负责根据历史数据更新30几个表的信息。
这样做，即使是MODEM，每秒也能传递100条历史数据。而且客户端可以记住上次更新到第几个历史记录，下一次连线的时候仅仅从这个记录开始继续读。大概一个月新增3万条记录。

项目做得很成功，客户很高兴。领导很满意。

当时没用任何值得炫耀的新技术。不过自认为方案设计的挺合理。

2 楼 unsid 2009-01-14  

我没提这个细节，内容已经DES加密了，由于秘钥在服务器端和客户端事先存储好了，不通过网络传输秘钥，另外连接验证也有就是每次下载之前先把自己的用户名密码传过去验证这个用户名和密码是否都正确。
现在就是不知道这么多企业，下载到几百条，其他线程都停了，是不是跟服务器端的线程太多有关系

1 楼 魔力猫咪 2009-01-14  

你在客户端和服务器端管得太多了。因设计不好，造成效率低下。你现在的系统安全性相当大，所有内容等于明文传输，且没有连接验证。等于谁都可以随便连接查询了。
推荐使用WebService解决远程交互问题。使用加密证书保证WebService连接的合法性和安全性。
客户端的所谓线程池实在没必要。服务器端要尽快实现。推荐用EJB3，直接可以使用服务器发布成WebService。由EJB容器帮你管理线程以提高效率。