解决个数据简单，数据量大，并发5万每秒的问题

[alansde]

解决医保卡在不同医院看病用药情况共享
城市用户数：2000w
预计并发：3w 或者更高，或者说设计能力每秒不低于5w 甲方要求的
预计查询数据量：2000w用户*100药品编码 大概20亿
后期可能覆盖范围更高，部分省市联网，，数据量更大

每位患者都有一个医保卡号
每个药品都有一个固定唯一的编号，在全市统一。

如果一个患者去医院开药
在医院给病人开处方时候，生成一条数据：医保卡号+药品编号 发送到服务器，如果此医保卡开过此药品，医生可以生成处方，如果未开过此药品，提醒医生
此药该患者未开过，如果医生确认生成次处方，数据库记录这条新的记录。方便下次查询。

现在测试阶段，三个医院试点，使用技术 .net+sqlsever 每秒500次请求没有问题
医院的his系统对接要求医院对应服务商解决我平台只需要接收到他们上传的数据


如果满足5w每秒的请求，还想继续使用.net+sqlserver 毕竟原有团队都是这块技术，是否可以解决

数据量大，并发大，但是数据简单


1。新的系统应该怎样构架，需要用哪些新技术,这种架构方法上，需要服务器数量及带宽

2。如果不使用.net +sqlserver推荐使用何种技术

3。要求系统查询和返回数据实时，或者延时少

4。有此类工作经验,并可以完全应付，的可以联系我qq:76777370或者留下qq

有经验的攻城狮给简单说说方案，服务器部署

[skgary]

楼主的模型错了。 2000W人的城市，不可能3W/秒的。 3W条/秒，1小时3600秒，等于1亿，一个城市的人，一小时看5次病？或者开5张处方？或者说，挂号，开方，付费，取药，化验之类的操作要做5次？ 真的要到3W/秒，那你肯定是要每按模块分层，按功能分块，可横向扩展；例如，医保库分开封装，药库分开封装。。。。 关于网络，3W/秒的请求，如果是1KB一个请求，那么等于30MB/秒，基本上要保证GE以上的带宽才行。 如果请求里是10K，20K的图片的话，基本上就必须10GE的网络了。 总结下来一句话，甲方算错了

[pcvvv]

引用 35 楼 skgary 的回复:

楼主的模型错了。 2000W人的城市，不可能3W/秒的。 3W条/秒，1小时3600秒，等于1亿，一个城市的人，一小时看5次病？或者开5张处方？或者说，挂号，开方，付费，取药，化验之类的操作要做5次？ 真的要到3W/秒，那你肯定是要每按模块分层，按功能分块，可横向扩展；例如，医保库分开封装，药库分开封装。。。。 关于网络，3W/秒的请求，如果是1KB一个请求，那么等于30MB/秒，基本上要保证GE以上的带宽才行。 如果请求里是10K，20K的图片的话，基本上就必须10GE的网络了。 总结下来一句话，甲方算错了

应该是3w/分钟，和后面提到的" 每秒500次请求" 吻合

[以专业开发人员为伍]

引用 3 楼 u013776828 的回复:

其实这个并不复杂 一个KV结构就可以很好的处理这个问题 key 医保卡号 value 一个使用过的药品list 通过一个多线程服务程序来对这个KV数据进行维护 如果鸭梨过大 可以在Key上做服务器分割

这样晕一个设计问题，可能程序连“死都不知道怎么死的”。

[以专业开发人员为伍]

引用 5 楼 ldh911 的回复:

建议不要做成中央集中型系统，几大问题： 1、扩展医院数越多，性能下降越快，最后很可能呈指数下降趋势； 2、中央集中意味着单点故障，比如中央服务器机房断电、断网等问题，就是全局性影响； 3、可销售商机下降。 建议总体应做成分布式架构模型： 1、每个医院部署一个本地服务，负责：近期数据查询、本地缓存和缓存数据更新； 2、中央做一个数据中心，负责：所有数据管理 与 查询。

如果“中央”有500台业务处理服务器，这就跟只有2台服务器的“中央”就不一样了。

[以专业开发人员为伍]

引用 18 楼 alexander0729 的回复:

这个其实没那么复杂的，并发也不是那么的高 1. 难道一个医保卡能同时在不同的医院看病？ 2. 挂号之后，医生马上就能诊断？ 其实从挂号到医生诊断，这中间至少是要有好几分钟的间隔的 3. 这个就是个简单的中央架构， 大部分都是读 4. 一个医院的挂号窗口一般都不会超过20个吧， 就算50个吧， 不停的挂号， 那一个窗口挂一个号需要30-50秒吧， 100个医院不算少了吧， 医保跨市结算的先不管它，如果现在就把跨市的结算给解决了，那领导们还怎么赚钱？估计把你恨死了。 5. 1w个并发足够了。 6. 唯一的瓶颈就是挂号的时候，从中央数据库读取这个病人的记录， 能在2分钟之内读完就行 等看完病了就再把新记录给发送到中央数据库就行了， 半个小时总能post过去的吧

引用 18 楼 alexander0729 的回复:

这个其实没那么复杂的，并发也不是那么的高 1. 难道一个医保卡能同时在不同的医院看病？ 2. 挂号之后，医生马上就能诊断？ 其实从挂号到医生诊断，这中间至少是要有好几分钟的间隔的 3. 这个就是个简单的中央架构， 大部分都是读 4. 一个医院的挂号窗口一般都不会超过20个吧， 就算50个吧， 不停的挂号， 那一个窗口挂一个号需要30-50秒吧， 100个医院不算少了吧， 医保跨市结算的先不管它，如果现在就把跨市的结算给解决了，那领导们还怎么赚钱？估计把你恨死了。 5. 1w个并发足够了。 6. 唯一的瓶颈就是挂号的时候，从中央数据库读取这个病人的记录， 能在2分钟之内读完就行 等看完病了就再把新记录给发送到中央数据库就行了， 半个小时总能post过去的吧

lz的需求是在医生开药时，针对每一个药品进行反馈。而不是在挂号和划价环节。

[sp1234_maJia]

引用 35 楼 skgary 的回复:

楼主的模型错了。 2000W人的城市，不可能3W/秒的。 3W条/秒，1小时3600秒，等于1亿，一个城市的人，一小时看5次病？或者开5张处方？或者说，挂号，开方，付费，取药，化验之类的操作要做5次？ 真的要到3W/秒，那你肯定是要每按模块分层，按功能分块，可横向扩展；例如，医保库分开封装，药库分开封装。。。。 关于网络，3W/秒的请求，如果是1KB一个请求，那么等于30MB/秒，基本上要保证GE以上的带宽才行。 如果请求里是10K，20K的图片的话，基本上就必须10GE的网络了。 总结下来一句话，甲方算错了

根据lz描述的“医生每开一个药品的时候就要查询一次服务器”，那么一个人看病时（一个人一天只能可能挂号几个医生的号）一定有可能查询50次服务器。而且一个医疗系统绝不止这一个”查询最近使用过的药品”的查询，一定还有许多别的业务查询。那么你这个估计数量一定要成上200才是lz的用户要求的数量。

[sp1234_maJia]

引用 楼主 u013772189 的回复:

解决医保卡在不同医院看病用药情况共享 城市用户数：2000w 预计并发：3w 或者更高，或者说设计能力每秒不低于5w 甲方要求的 预计查询数据量：2000w用户*100药品编码 大概20亿 后期可能覆盖范围更高，部分省市联网，，数据量更大 每位患者都有一个医保卡号 每个药品都有一个固定唯一的编号，在全市统一。 如果一个患者去医院开药 在医院给病人开处方时候，生成一条数据：医保卡号+药品编号 发送到服务器，如果此医保卡开过此药品，医生可以生成处方，如果未开过此药品，提醒医生 此药该患者未开过，如果医生确认生成次处方，数据库记录这条新的记录。方便下次查询。 现在测试阶段，三个医院试点，使用技术 .net+sqlsever 每秒500次请求没有问题 医院的his系统对接要求医院对应服务商解决我平台只需要接收到他们上传的数据

我认为这个业务逻辑有问题，难以解决大数据量查询问题。如果要解决，就要修改业务流程。 例如医生在一个“开处方”界面上，应该可以快速地录入多个药品，系统不应该在医生录入每一个药品时都以“阻塞的方式”等待这个药品的确认信息。医生一边录入药品，比如说录入了第3个药品时，系统才用一个醒目的颜色显示第一个药品“已经核对通过了”，这种异步的核对操作流程设计，就能把高并发问题化解掉。 3年前瘫痪的铁路售票系统，就是一个“阻塞式”的典型例子。阻塞模式造成了所有人都阻塞，于是大家都非常焦虑、反复刷新页面，这就给一个没有“异步排队模型”的系统雪上加霜了。 如果你为你的系统的业务操作加入一个“任务调度的异步排队”机制，那么你不论是和自由10台服务器、还是迅速（20分钟之内）扩展到100台服务器，都可以迅速水平扩展cpu处理能力。 但是这就要求终端设计上，要进行巧妙地配合。例如医生录入厨房时，他可以飞快地录入而不阻塞。而看到的提示也不要求迅速和完美地显示出来，只要他录入最后一个药品时，总可以在几秒之内看到所有的药品都被确认了，这就行了。你绝不会在医生录入药品时给他“卡”几秒钟，你会给他的界面“异步地”进行填充结果。 这就可以了！

[sp1234_maJia]

异步处理其实也不复杂，只不过是一个逻辑设计的简单问题。在客户端来看，当医生开药时，你服务器判断当前CPU是不是空闲，如果空闲则立刻查询结果并返回；如果不空闲则给客户端仅返回“已经分配任务号8238423”这类消息，然后把任务扔到服务器端任务队列里。这样做的目的是提高用户体验，从而让用户实实在在感觉到“似乎并发数量很大”。 然后客户端有一个定时器程序，例如5秒钟触发一次，如果发现有些药品尚未经过服务器端确认，那么就会去服务器单独用其任务号查询一下有没有“运行结果”需要传过来。如果所有药品都经过确认了，就不访问服务器。当然如果客户端跟服务器保存一个单独的“长连接”使得服务器可以推送确认数据过来，占用资源更少，不过这种长连接的规模似乎有点太庞大了，难以保证稳定。 而在服务器端，对于任何任务，应该可以负载均衡给某一个闲置的服务器查询（谁的CPU利用率最低，就给谁），而不是负责接入客户端请求的那个服务器去查询。如果怕这个服务器宕机，那么把任务放两个或者三个在队列里，冗余地去运行。反正都是在大型机房内部的集群之间的操作。

[以专业开发人员为伍]

就数据库来说，假设你有一个“基本数据库”，然后有一“堆”按照社保登记卡号分段管理的数据库，你的程序总是使用两个并发线程去查询基本库和分段库，然后将结果合并起来，那么也就可以兼容“分库阶段”的系统变动了。

[lukaifu2002]

感觉应该是一个中央集群服务（负责医保等具有全局性质的信息存储、以及异步上传的病人开药、病例等信息）+若干分散在各区或各医院的“本院药品病患信息管理系统”（药品库存信息、医生信息、本医院就医患者病历、处方等信息） 原因： 1、药品是放在本地药房，信息也没必要一定放在中央服务器集群中。难道别的医院还要查询、销售我们医院药房里面的药吗？如果药品信息在本地机房，即便并发再高、传输数据量再大，带宽也相对容易保证的多。 2、有几次会去查其他医院的病例，即便需要，以异步的方式更新数据到到中央服务器集群也没问题。这个更新频率和实时性要求不会太高，使用频率也不太高。 3、一些全局性信息，会经常性的在中央集群服务和分散在各医院的信息系统之间进行交互，但由于大部分本地信息就存储在本地，极大减少了信息传递的数量、网络带宽占用时间和传输时间

[等待时候]

涨知识了！

[风吹过夏天]

以上都是大神。不明觉厉

[冰思雨]

我没搞过大数据的项目，但是，这个帖子都一年多了，我刚看到，想说说自己的想法： 首先，社保卡和药品的使用范围都在同一个城市（的不同医院），这个场景决定了，我们医疗系统，可以以城市为单位。一个城市搞一套这个系统就可以了，至于省一级乃至全国级的数据，登医保卡实现跨省（市）通兑通用再二次开发吧。 其次，既然是数据太多，一时处理不过来，那么，我们就针对数据，创造出几种玩法，搞定瓶颈。 A。系统层面上，分成三个部分：一个是数据中心，一个是医院代理，一个是客户端。数据中心一个城市就一个（由多台服务器组成）；医院代理为每个医院都设立一个（可以多台负载均衡也可以一台服务器搞定，关键看业务量）；客户端就多了去了，每个客户端都链接着医院代理。数据中心持有全局数据，也由三个部分组成；医院代理负责处理本医院内部的流水信息，是客户端与数据中心的桥梁；客户端直接连接医院代理，不与数据中心直接通信，主要完成数据展现和友好界面。 B。数据中心：根据数据的不同，拆分成三个部分，一个是认证服务，一个活跃数据服务，一个惰性数据服务。认证服务由一个或多台服务器组成，主要有两个功能，医疗卡的认证鉴权功能以及相关数据的激活和钝化功能。一般会引入分布式缓存，加快认证速度。活跃数据服务，先要明白什么是活跃数据，就是那些有强烈声明周期的数据，比如我拿着医保卡去医院了，划卡时进行认证鉴权，之后，我医保卡信息会被激活，比如，我的姓名，年龄，病例信息等，凡是今天马上要用的数据，都会被激活，而这些数据在我离开医院，或者支付完药费，或者医院下班后，就会被钝化或丢弃。活跃数据里面还要分共享活跃数据和个性化活跃数据，顾名思义，共享型的数据，比如常规药品信息，你用我也可能会用到；个性化的数据就像我的病例信息了，我有你可能不会有。这些数据都会放到分布式缓存里面，查询压力很大的说。惰性数据服务，保存不经常访问的数据，但是没有还不行，激活的时候还要用到，一般保存到数据库中。数据中心的三个部分，每个部分都可以集群处理的。 C。医院代理：按功能分成三个部分，数据中心代理服务，本地业务处理，客户端接口服务。数据中心代理功能主要负责与数据中心通信，以及缓存部分常用信息，减轻中心压力；本地业务处理服务，处理本地流水信息，最后按照设计需求将本地信息提交给数据中心代理服务，批量同步到数据中心，最好使用消息中间件；客户端接口服务，负责与客户端通信（B/S或C/S）。医院代理根据业务量，也可以做成集群，数据库用一台就可以，缓存可以使用分布式缓存。 D。客户端：主要是数据展现和与医院代理的通信。具体怎么通信，根据协议就好。 第三，说说这个架构优点：1. 查询操作通过分布式缓存来分担，极大减轻了数据的查询压力；2.写入操作通过消息中间件来传递数据，大大缓解了数据库数据写入过载的现象；3.引入医院代理将业务流水与非业务数据进行隔离，大大减轻了中央服务（数据中心）的数据处理压力，业务流水数据原则上由医院代理完成分析汇总，最后将结果批量传递至数据中心即可，当然，也可以强制数据中心进行处理，那数据中心就要增设业务数据处理的功能，统一进行数据处理（不推荐这么搞）。 最后，由于引入了集群，那么必然要考虑单点故障和多点故障的，多点间的数据通过分布式缓存来完成，本身具有良好伸缩性，记得选个好一点的负载均衡算法来玩分布式缓存。稳定性本身在大型软件系统中就是一个不可避免的问题，硬件的融灾做好方案就好，软件的风险问题，只能靠细致和有经验的测试来规避，最后制定一系列紧急预案放在那里等着问题出现即可。 问题一定会出现，不必要过于恐慌，就像买彩票一样，一定会中奖的，就看运气怎么样了。你不买永远都不知道你中不了。

[那城]

还是用三层的做法，客户端不做逻辑处理，只做显示，录入等基本功能，服务端来处理业务逻辑

[你们王哥]

引用 47 楼 preferme 的回复:

我没搞过大数据的项目，但是，这个帖子都一年多了，我刚看到，想说说自己的想法： 首先，社保卡和药品的使用范围都在同一个城市（的不同医院），这个场景决定了，我们医疗系统，可以以城市为单位。一个城市搞一套这个系统就可以了，至于省一级乃至全国级的数据，登医保卡实现跨省（市）通兑通用再二次开发吧。 其次，既然是数据太多，一时处理不过来，那么，我们就针对数据，创造出几种玩法，搞定瓶颈。 A。系统层面上，分成三个部分：一个是数据中心，一个是医院代理，一个是客户端。数据中心一个城市就一个（由多台服务器组成）；医院代理为每个医院都设立一个（可以多台负载均衡也可以一台服务器搞定，关键看业务量）；客户端就多了去了，每个客户端都链接着医院代理。数据中心持有全局数据，也由三个部分组成；医院代理负责处理本医院内部的流水信息，是客户端与数据中心的桥梁；客户端直接连接医院代理，不与数据中心直接通信，主要完成数据展现和友好界面。 B。数据中心：根据数据的不同，拆分成三个部分，一个是认证服务，一个活跃数据服务，一个惰性数据服务。认证服务由一个或多台服务器组成，主要有两个功能，医疗卡的认证鉴权功能以及相关数据的激活和钝化功能。一般会引入分布式缓存，加快认证速度。活跃数据服务，先要明白什么是活跃数据，就是那些有强烈声明周期的数据，比如我拿着医保卡去医院了，划卡时进行认证鉴权，之后，我医保卡信息会被激活，比如，我的姓名，年龄，病例信息等，凡是今天马上要用的数据，都会被激活，而这些数据在我离开医院，或者支付完药费，或者医院下班后，就会被钝化或丢弃。活跃数据里面还要分共享活跃数据和个性化活跃数据，顾名思义，共享型的数据，比如常规药品信息，你用我也可能会用到；个性化的数据就像我的病例信息了，我有你可能不会有。这些数据都会放到分布式缓存里面，查询压力很大的说。惰性数据服务，保存不经常访问的数据，但是没有还不行，激活的时候还要用到，一般保存到数据库中。数据中心的三个部分，每个部分都可以集群处理的。 C。医院代理：按功能分成三个部分，数据中心代理服务，本地业务处理，客户端接口服务。数据中心代理功能主要负责与数据中心通信，以及缓存部分常用信息，减轻中心压力；本地业务处理服务，处理本地流水信息，最后按照设计需求将本地信息提交给数据中心代理服务，批量同步到数据中心，最好使用消息中间件；客户端接口服务，负责与客户端通信（B/S或C/S）。医院代理根据业务量，也可以做成集群，数据库用一台就可以，缓存可以使用分布式缓存。 D。客户端：主要是数据展现和与医院代理的通信。具体怎么通信，根据协议就好。 第三，说说这个架构优点：1. 查询操作通过分布式缓存来分担，极大减轻了数据的查询压力；2.写入操作通过消息中间件来传递数据，大大缓解了数据库数据写入过载的现象；3.引入医院代理将业务流水与非业务数据进行隔离，大大减轻了中央服务（数据中心）的数据处理压力，业务流水数据原则上由医院代理完成分析汇总，最后将结果批量传递至数据中心即可，当然，也可以强制数据中心进行处理，那数据中心就要增设业务数据处理的功能，统一进行数据处理（不推荐这么搞）。 最后，由于引入了集群，那么必然要考虑单点故障和多点故障的，多点间的数据通过分布式缓存来完成，本身具有良好伸缩性，记得选个好一点的负载均衡算法来玩分布式缓存。稳定性本身在大型软件系统中就是一个不可避免的问题，硬件的融灾做好方案就好，软件的风险问题，只能靠细致和有经验的测试来规避，最后制定一系列紧急预案放在那里等着问题出现即可。 问题一定会出现，不必要过于恐慌，就像买彩票一样，一定会中奖的，就看运气怎么样了。你不买永远都不知道你中不了。

这个可以很好的解决，很全面

[我说我行就是行]

sql server 搞个读写分离就行了！

[showjim]

对于海量数据，数据中心应该是支持一致性哈希的服务集群，做好缓存服务，其它的都是不重要的细枝末节。

[zsgzhaosi]

不是很懂问哈，负载均衡+分库分表读写分离，基本没问题，单表千万级就考虑水平拆分

[mash5_paul]

引用 22 楼 KPRF2009 的回复:

数据库换mongoDB吧。。。 架构 我建议参考@ldh911 的建议。。。

兄弟，我们一直用的mongodb，对于LZ说的大数据量，有服务器的集群能解决这个问题。

[是奉壹啊]

不明觉厉，围观