并发研究
『 QPS（Quest Per Second每秒请求数） 』
QPS = req/sec = 请求数/秒
qps 是 new 的请求，叫每秒新建链接数， 很多连接进来的链接，已经 tcp 三次握手的完成内容交互之后的，没有超过 tcp 的断开时间，虽然是活动状态，但是已经基本不消耗服务器资源了， 这种是最大活动链接数， 每台机器65535个链接数，这个链接数基本不考虑。
PV = Page View
pv 是指页面被浏览的次数，比如你打开一网页，那么这个网站的pv就算加了一次。
由于互联网有一个传说中的“3秒定律”，可能当下更多的网站技术指标要求1.5秒以内加载整页，或者至少可以达到阅读的标准。如果要较真什么“同时在线”，毫不客气的说，对于HTTP这类短链接的网络协议来说，在WebSocket还不普及的时代，能统计在线纯属扯淡，唯一能做的只是取个时间段，计算下访问用户而已。
『 Web网站的几个并发量级 』
50QPS以下 —— 小网站（新手开发的个人网站）
50～100QPS —— DB极限型（注册用户3万以下）
300～800QPS —— 带宽极限型（共享百兆带宽、首要考虑是CDN加速／异地缓存，多机负载等技术）
500～1000QPS —— 内网带宽极限＋Memcache极限型（未知？）
1000～2000QPS —— FORK/SELECT，锁模式极限型（未知？）
2000QPS以上 —— C10K极限（未知？）
『 一个系统的最大并发用户数为1100，怎么能推算出该系统的支持最大用户数 』
『 在线用户数和并发用户数的区别和比例关系 』
在线用户数：用户同时在一定时间段的在线数量
并发用户数：某一时刻同时向服务器发送请求的用户数
一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20%
比如，某网站存在注册用户数为10W人，但同时在线最多1W人，但这1W个人，可能只有500人会浏览帖子，500人会进行发帖，只有这1000个人对服务器才有交易，那我们计算并发量的时候，就可以以1000为标准！
使用一台服务器大概50MB的内存来存用户ID，足够存1000W个int型数据，然后在程序里给不同的ID段分配不同的数据库服务器，这样你想支持多少人在线查都没问题，主要看你服务器够不够多。
并发每秒5万，也不算太高，很好处理的。你首先要确定每秒5万个连接，每个连接的平均收发数据大小，一共的大小，足不足够你服务器所用的带宽？如果带宽不够，程序做的再好也做不到。
其次就是服务器硬件的处理能力，这个需要在工程完成后做压力测试，来判断硬件是否满足要求。
最后才是程序的数据结构，使用最合理的设计模式去编写程序。
.net 加上 sql server每秒几百万，几千万也没问题。
但是由于数据量过于庞大，查询sqlserver 毕竟有耗时，一个两个查询看不出来，成千上万个同时查询，就看出来延迟非常大了，所以一定要使用缓存技术。第一个用户第一次查询直接查询数据库，同时将该查询语句的所有查询数据存入缓存，之后的所有用户都查询该缓存，这样并发再高查询速度几乎0延迟。
也许会人要质疑了，将数据库数据独立到缓存中那么有更新数据怎么同步？回答是，在数据库更新后清空缓存。只要缓存为空，就可以重新写入，缓存不为空，就直接查缓存。这样就做到了时刻同步。
如果使用缓存技术，一定要确保你的服务器内存足够大，缓存是长期占用内存空间的，而且根据数据量大小，会持续增加。如果你的数据量今后会越来越大，达到几个G，那么你内存最好也上够32G，这样才保险，否则服务器有可能挂掉。
以上所说的是单服务器的最大化效率做法，但是一定会由于种种原因，主要是硬件和环境原因，根本无法达到你的预期效果，那就需要做分布式的存储方案了。根据查询需要和分类，将操作分布在不同的服务器，然后大量的数据交换在服务器和服务器之间的内网进行，全部数据使用异步方式处理，这样就均摊了服务器的压力。
但是你这个是医保系统，肯定不会像春运时铁路订票网站那样百万级的大并发，最开始，春运第一天就挂掉了，很多人都无法登录，每一秒同时点登录的人都上百万，我不知道带宽环境怎么样，就先去忽略它。
然而数据库的查询都是队列形式的，不可能两个人以上同时查询一个数据库（如果你学过vc语言就会深刻的理解windows消息），因为操作系统无法同时接收两个消息，在消息循环中，只能是一个消息一个消息的接收，那么同时请求的那么多消息就要临时存储到消息队列中去等待。如果消息等待数量过于庞大，几百万了，等待时间就会很长，这时，服务端或者客户端连接就很容易超时。由于很多人却不知道服务器已经快扛不住了，即使登录不上也一直登录，就会导致持续的无效高并发，在服务器资源耗尽的时候，就挂了。我分析服务器挂掉的原因多是因为这个原因。要不是服务器处理能力差，他这个就跟被ddos攻击一样的效果，原理都很相似，只不过不是被肉鸡攻击的，而是被实实在在的上百万人的每个点击攻击的，很可笑吧。
所以你要设计的方案不要光考虑数据结构的合理性，更多的要注重实用性，如果光考虑原理，单服务器如果设计的非常完美，多大量都没问题，但是实际中却并非如此。就两个字，时间，会让你的设想全部落空，耗时问题从来都是大问题。
『 游戏服务器并发 』
想起来一个很常见的例子，网络游戏单服务器并发100多万是很常见的事情，我曾经研究过传奇2的服务端，程序运行以后，将所有的数据库数据都加载到内存中，然后所有的数据交换都在内存中进行，然后异步向数据库中更新数据，这样在并发非常高的时候，不会因为处理速度原因而造成延迟，而仅仅考虑带宽和内存就可以了，cpu使用率是很低的。
『 如何解决高并发问题 』
1、静态化
2、MySQL 的主从、读写分离
3、缓存
4、文件服务器、业务服务器、数据存储服务器、缓存服务器、路由服务器、容错服务器
