医保大并发解决方案

http://bbs.csdn.net/topics/390716520

 

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

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

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

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


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

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


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

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

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

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

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

----------------

每秒钟3w次并发意味着峰值期间每秒钟有3w条记录要过来。假设一个用户生成3条记录，那么每秒钟就有1w个用户开出药方，像北京这样的1500w人口的城市只要半个钟头就可以全部看一遍病了，个人觉得这样强的处理能力是过多了。
作为一个估计，一个城市里面每个人每3天配一次药的话，2000w/3/8/3600=230，峰值时翻倍基本上能处理到500次并发需求就够了，一般的数据库集群应该能撑的过去的。
--------------------

引用 1 楼 yyfhz 的回复:

每秒钟3w次并发意味着峰值期间每秒钟有3w条记录要过来。假设一个用户生成3条记录，那么每秒钟就有1w个用户开出药方，像北京这样的1500w人口的城市只要半个钟头就可以全部看一遍病了，个人觉得这样强的处理能力是过多了。
作为一个估计，一个城市里面每个人每3天配一次药的话，2000w/3/8/3600=230，峰值时翻倍基本上能处理到500次并发需求就够了，一般的数据库集群应该能撑的过去的。

谢谢关注，，，
后期还有病房实时使用用药数据，这个数据量相当大，还有其他的数据。
我们也是这样想过。但是甲方提出的要求就是3w的并发量。
从我们做项目来说，要求越高越好，越有钱赚。

-----------------------------------

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

----------------------

建议不要做成中央集中型系统，几大问题：
1、扩展医院数越多，性能下降越快，最后很可能呈指数下降趋势；
2、中央集中意味着单点故障，比如中央服务器机房断电、断网等问题，就是全局性影响；
3、可销售商机下降。


建议总体应做成分布式架构模型：
1、每个医院部署一个本地服务，负责：近期数据查询、本地缓存和缓存数据更新；
2、中央做一个数据中心，负责：所有数据管理 与 查询。

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

--------------------------

建议不要做成中央集中型系统，几大问题：
1、扩展医院数越多，性能下降越快，最后很可能呈指数下降趋势；
2、中央集中意味着单点故障，比如中央服务器机房断电、断网等问题，就是全局性影响；
3、可销售商机下降。


建议总体应做成分布式架构模型：
1、每个医院部署一个本地服务，负责：近期数据查询、本地缓存和缓存数据更新；
2、中央做一个数据中心，负责：所有数据管理 与 查询。

---------------------------------

中心分布式比较适合，分点式稳定性更差，中间需要考虑的额外因素更多。网络 停电 之类都可能导致系统局部瘫痪。
而中心服务器可以在应用级别上做冗余
说实话就现在你的业务需求 2000W级的其实鸭梨不大 只要用对了模型
别试图在网站程序的级别上搞定这个需求，换个思路 其实很简单

-------------------------------

引用 6 楼 u013776828 的回复:

中心分布式比较适合，分点式稳定性更差，中间需要考虑的额外因素更多。网络 停电 之类都可能导致系统局部瘫痪。

我持有不同意见。

1、即便是中心集中（或中心分布式），局部发生停电或断网，该局部照样没法用系统；如果一旦中心发生瘫痪，则是大家一起完蛋，根据推广情况直接影响十数家甚至数十家医院。
2、分布式方案（但仍然要有中央数据中心），运维仍然可以由中央来远程负责，即便中央数据中心瘫痪，局部的系统仍可应急使用（具体开放功能情况可与需求部门商定）。
3、中心集中式，对中心到各个局部的互联网络带宽要求高，因为不仅仅是数据，所有的页面、样式、图片等内容，全都要从中心服务器上下载，中心慢就所有人一起慢。
4、分布式方案（但仍然要有中央数据中心），大部分信息本地就能处理，而本地网络往往随意可以上到100M甚至1000M，也没啥线路租用成本。
5、分布式方案增加了医院自主权，医院可以根据自身情况和经费增加本地服务器集群数量（这就是新的项目投资）；还可以依托本地服务器来进行一些二次开发工作，更方便实现与医院内部系统的二次对接或集成等功能（这也是新的项目投资）。

------------------------------------

对于分布式的 结合以前做过的项目 只有一个结论 跑死人不偿命
中心式的 避免了医院网管的低级失误
可靠性和维护的便利性会更高

-------------------------------------

同时分布式方案 最大的问题是 当你需要调用的数据在失效的node的时候 你的结论肯定是错的
作为一个医疗系统 这种错误实际上是不应该允许的  一个NODE的失效 实质上整个系统也没有使用的价值了
这种系统反而更强调完整性 所以 分点的方式是最不可靠的 

-----------------------

引用 9 楼 u013776828 的回复:

同时分布式方案 最大的问题是 当你需要调用的数据在失效的node的时候 你的结论肯定是错的
作为一个医疗系统 这种错误实际上是不应该允许的  一个NODE的失效 实质上整个系统也没有使用的价值了
这种系统反而更强调完整性 所以 分点的方式是最不可靠的 

还是持有不同观点：
1、这个不是一个医院使用的系统，是N个医院，而且根据楼主的描述，还要跨省市服务；总体系统可用性的问题是决定性的压倒一切；
2、我提出的分布式方案并不是绝对意义的分布计算，而是带有中央数据中心的，所有数据唯一性由中央数据中心负责，并不存在一个Node失效影响整个系统，这一点跟你所理解的有偏差；换个说法：我的方案是个两级部署方案，可以认为是1个中央系统+N个前置系统；
3、我提出的方案并不需要医院网管去维护啥，本来系统就可以远程维护。


最后，我觉得其实分布式系统是常态，比如：网银就是我所说的分布式的，有个中央交换网络加N个银行独立系统接入，工行挂掉了，不会影响建行跟农行之间继续开展业务对不对？电信系统也是类似的，之前汕头电信机房发生大火，全汕头市座机瘫痪，但是不会影响广州、深圳等地互相打电话和费用结算对不对？


有探讨就有进步，非常高兴能跟u013776828继续交流～～～

------------------------------------

我知道的有一个案例 最开始也是各个局做的分布式数据库 通讯也是你这样处理的
最后还是集中了
对于这种不允许有单点失败的系统 分布式还是很尴尬的

------------------------------------

引用 11 楼 u013776828 的回复:

我知道的有一个案例 最开始也是各个局做的分布式数据库 通讯也是你这样处理的
最后还是集中了
对于这种不允许有单点失败的系统 分布式还是很尴尬的

你说的这个案例很有价值，因为任何一种架构模型，都一定有它合适的场景或不合适的场景，否则某种架构模型早就“一统江湖”了。

另外架构模型本身也有规模性问题，从一个大范围来看可能是个分布式 或者 分散式，而其中单个系统或子系统也许又是集中式甚至网格式。

我之所以建议楼主采用这种二级部署的分布式架构，也是考虑到他有几个特征：
1、业务简单：以海量查询为主，带一定量的简单数据更新；
2、业务非关键：如果该业务不能用，医院还是必须能用自己的管理系统给病人开药，也就是说这个系统实际上是个辅助系统；
3、无极强的实时一致性要求：病人不太可能在短时间（隔天）内重复开同一种药品，那么数据更新可以有一定时延；
4、各用户单位（每个医院）相对独立（自负盈亏）.



如果不涉及商业保密问题的话，希望你能简单分享下你所了解案例中碰到的主要问题，或者说不适合的原因。

|

|

|

|

--------------------------
并发每秒5万，也不算太高，很好处理的。你首先要确定每秒5万个连接，每个连接的平均收发数据大小，一共的大小，足不足够你服务器所用的带宽？如果带宽不够，程序做的再好也做不到。

其次就是服务器硬件的处理能力，这个需要在工程完成后做压力测试，来判断硬件是否满足要求。

最后才是程序的数据结构，使用最合理的设计模式去编写程序。

.net   加上 sql server每秒几百万，几千万也没问题。

但是由于数据量过于庞大，查询sqlserver 毕竟有耗时，一个两个查询看不出来，成千上万个同时查询，就看出来延迟非常大了，所以一定要使用缓存技术。第一个用户第一次查询直接查询数据库，同时将该查询语句的所有查询数据存入缓存，之后的所有用户都查询该缓存，这样并发再高查询速度几乎0延迟。

也许会人要质疑了，将数据库数据独立到缓存中那么有更新数据怎么同步？回答是，在数据库更新后清空缓存。只要缓存为空，就可以重新写入，缓存不为空，就直接查缓存。这样就做到了时刻同步。

如果使用缓存技术，一定要确保你的服务器内存足够大，缓存是长期占用内存空间的，而且根据数据量大小，会持续增加。如果你的数据量今后会越来越大，达到几个G，那么你内存最好也上够32G，这样才保险，否则服务器有可能挂掉。

以上所说的是单服务器的最大化效率做法，但是一定会由于种种原因，主要是硬件和环境原因，根本无法达到你的预期效果，那就需要做分布式的存储方案了。根据查询需要和分类，将操作分布在不同的服务器，然后大量的数据交换在服务器和服务器之间的内网进行，全部数据使用异步方式处理，这样就均摊了服务器的压力。


但是你这个是医保系统，肯定不会像春运时铁路订票网站那样百万级的大并发，最开始，春运第一天就挂掉了，很多人都无法登录，每一秒同时点登录的人都上百万，我不知道带宽环境怎么样，就先去忽略它。

然而数据库的查询都是队列形式的，不可能两个人以上同时查询一个数据库（如果你学过vc语言就会深刻的理解windows消息），因为操作系统无法同时接收两个消息，在消息循环中，只能是一个消息一个消息的接收，那么同时请求的那么多消息就要临时存储到消息队列中去等待。如果消息等待数量过于庞大，几百万了，等待时间就会很长，这时，服务端或者客户端连接就很容易超时。由于很多人却不知道服务器已经快扛不住了，即使登录不上也一直登录，就会导致持续的无效高并发，在服务器资源耗尽的时候，就挂了。我分析服务器挂掉的原因多是因为这个原因。要不是服务器处理能力差，他这个就跟被ddos攻击一样的效果，原理都很相似，只不过不是被肉鸡攻击的，而是被实实在在的上百万人的每个点击攻击的，很可笑吧。

所以你要设计的方案不要光考虑数据结构的合理性，更多的要注重实用性，如果光考虑原理，单服务器如果设计的非常完美，多大量都没问题，但是实际中却并非如此。就两个字，时间，会让你的设想全部落空，耗时问题从来都是大问题。