高并发处理方案

[qq_40142095]

项目大概情况：2000个仪表每2秒中向服务器发送一次数据，服务器计算后再返回给仪表，也就是说要求2秒钟之内完成2000次数据的接受-运算-发送。
之前有个项目是4000个表60秒左右来回一次，结果ActiveMq会积压数据，这次求一个不积压的解决方案

[wanghui0380]

额，没有方案。挤压数据只是表示你消费不够 所以你需要的是加快消费，而不是其他方案

[以专业开发人员为伍]

你可以自己写上百十行代码，实现一台 master 服务器与 n 台 worker 服务器的任务调度通讯，不外乎就是 worker 领一下任务、然后把结果返回给 worker 之类的 3、4个命令而已。

[以专业开发人员为伍]

然后把结果返回给 worker 之类的 --> 然后把结果返回给 master 之类的

如果感觉通用框架太复杂、太繁琐、太慢，自己用它几十分之一的代码就能写一个更适用于自己的。

[孤独的海啊]

请说出你的细节。

[E次奥]

如果是一台服务器，那没啥方案；
如果是多台服务器，那就 分发，执行，统计，返回

[wanghui0380]

也许俺们说的话不那么好听。但你只需要想一下实际我们都天天见到的实际场景 每天地铁大厅，高铁大厅都一堆人。------------也就是你说的“积压” 现在到处下雨，各个水库爆满，有些道路淹没半米---------------也就是你说的“积压" 那么问题本质是什么？ 1.其实是运力调度不够，地铁车次不够，排水不够，泄洪不够。所以不是说在上面折腾方案。而是去下面加快调度 2.不要怕“积压”，建水库的目的就是调控。地铁大厅也是中转调控。道路排水也是调控。我们并不是要求水库为空不“积压”，也不要求地铁大厅根本木人不“积压”，也不是要求城市排水沟里没有水不“积压”，我们要求的是他们不会漫过设计要求。如果漫过了，就的开闸，就得分流，就的泄洪，就得抽水（人类的手段都一样，控上游，释下游。一条释放路径不够，就多加几条释放路径） 总归来说ActiveMq这里东西其实就是水库，有库容是对的，调节消峰也是对的，他保护的是下游。如果说你觉着库容过大，想想人类怎么干？很明显不是找东西替代水库，而是限流，分流，泄洪

[正怒月神]

不知道你慢的是程序，还是数据库。 方案不少。 1 负载均衡，同一套项目，可以部署多个站点。然后让请求均匀分散到每个webapi。 2 就如sp所说，创建主次同步的数据库。一台master，N台slave，一般来说都是属于读写分离的范畴。