数据上传下发，同步问题

[杀马特丶蛮牛]

数据中心和各客户点之间数据上传下发问题，客户点会执行某些操作，生成临时表，需要将这些临时表数据上传平台。
1.客户点怎么上传？每次读取100条数据，发送到平台，平台执行完毕返回状态？
2.平台收到数据存入消息队列，但这样客户点没法知道平台这批数据是否操作成功

[杀马特丶蛮牛]

如果按1，客户点很多个的情况下，并发怎么解决， 按2的话并发没啥问题了，存入消息队列，一条条解决，但这样会不会造成队列元素过多，可能同时很多个点一次性发很多条数据，平台没处理完数据，可能客户以为没成功，还会一直点发送按钮，等待的队列越来越多

[lorimoon]

选2，可以返回消息的我记得rabbit mq 就可以而且可持久化，但是你的系统设计有问题吧？这客户端多数据操作了还要多并发这系统不少？排队是直接拿排队号不是站着等，参考浏览器下载列表。

[lorimoon]

选2，rabbit mq 可以返回消息，但是不应该让用户等，完之后在列表显示结果就是。

[以专业开发人员为伍]

你先要说清楚“数据中心”是客户端还是服务器端？这个你们确定了吗？如果首尾尚且部分，研究别的更深入的东西都是百搭。

[以专业开发人员为伍]

“大数据时代”实际上往往编程设计是很 low 的。原本是要设计一个企业级的 Server，然后自己的 Client 来访问自己的 Server。可是有许多初学者只学过什么“增删改查”，或者只学过什么“消息队列”，于是满脑子就只有数据库系统的 ADO.NET 驱动或者 Redis、MQ 之类的编程概念。

其实说白了，许多公司没有设计 c/s 系统的能力，而是使用各种各样的开源服务来“堆”系统，用各种简单的服务系统的客户端驱动调用方法来回避 Server 设计开发。真的能回避得了吗？作为软件公司的老板或者技术负责人，碰到这种情况会非常后悔没有招聘到“服务器开发人员”而把有限的薪水给了太多的（既不能专业开发前端框架的）处于中间夹层的开发者。

真正的服务器开发是基于通讯协议，在协议设计中包含业务对象，并且实现服务器协议解析、内部数据处理过程。而不是调一大堆开源服务的增删改查消息的客户端语句。

[以专业开发人员为伍]

大数据时代，一个公司就要设计自己的“实时数据库”系统，来接收高并发大数据，来采集高并发大数据，将信息点的事件高并发地进行订阅和通知给相关的远程客户端应用。而许多公司用专业开发人员的钱，给了一些只学过简单的 winform、asp.net 页面初步编程的人，通过调用各种开源“服务”，缓解技术难题。这里的关键在于“没有服务器端设计开发技术”，实际上是靠调用各种服务的 c 端驱动，来对客户欺骗说自己是做大数据服务器开发的。那么结果就是用户等了几年以为能将传统的过时的系统更新换代到大数据处理系统，最后发现被坑了。

[杀马特丶蛮牛]

引用 3 楼 lorimoon 的回复:

选2，rabbit mq 可以返回消息，但是不应该让用户等，完之后在列表显示结果就是。

那我客户点上传平台，传完了要是平台执行失败怎么操作？平台消息队列订阅者执行成功或者失败再回调客户点的接口？告诉你成功或者失败？要是这期间队列很多，一直等待，客户点一直在重发数据怎么做？

[杀马特丶蛮牛]

引用 4 楼 以专业开发人员为伍 的回复:

你先要说清楚“数据中心”是客户端还是服务器端？这个你们确定了吗？如果首尾尚且部分，研究别的更深入的东西都是百搭。

数据中心是服务器端

[以专业开发人员为伍]

你自己细品。实际上你设计开发一个“数据中心”，它自然就是消息总线、就是数据清洗总线、就是计算总线、就是业务对象网关。就好像一个飞机驾驶员不去开飞机，而是请空姐来开飞机，然后纠结说“因为自己的性能不高、动作频率不够快、达不到要求”，这样的纠结是有原因的，也不太合适。

[sdfsvbvcbcb]

解决方案, 首先你客户端把需要上传的数据全部读取出来组合为一个数据包,然后取这一组数据的MD5,服务端通过数据的MD5来确定是那一组数据,这样就可以解决并发接收的问题, 还有数据包的顺序, 为同一组数据增加一个包顺序的编号,接收完毕后服务器按照MD5和包顺序编号再合并数据,然后再检测接收到的数据MD5确定这个包是否为完整的就OK了, 说白了你用成熟的Sokcet通讯框架来做这些都不是问题, 可以去了解下 HPSokcet