高并发求优化

[巫妖天下]

有个接口，是用来调取自己的工资信息的，他的格式是：http://www.baidu.com/api/gz.aspx?usr=xxx&pwd=xxx&startID=xxxx

我的逻辑是：
1.判断其账号密码正确。
2.根据startID，获取 id>startID的数据。

问题如下：
当同时3万多人同时调用接口的时候就出问题了。。好卡。。我在想，可否优化判断账号密码的部分，因为这部分要查数据库，同一个用户调用多次接口就会做很多次重复工作，用什么办法可以解决？能不能把曾经验证过的信息放到内存上，判断是不需要查数据库？

[以专业开发人员为伍]

.net Cache 类本来就是做这个的啊。

[以专业开发人员为伍]

使用 .net framework 中的 Cache 类，这本来是非常必要、非常重要的程序设计技术。 但是现在好多人都是只能理解最底级的刚学编程时的老师让抄写（应付面试）的那些笔记，而没有培养出研究、设计、学习架构的习惯，所以对于入门书上不容易找到的设计知识，都不太了解。 Cache 是一个比较繁忙的服务系统的核心设计概念。没有它，效率就要下降几十倍。

[以专业开发人员为伍]

Cache 的核心知识点其实并不在于“把曾经验证过的信息放到内存上”。你说这个说明你还没有理解 Cache。 Cache 的核心控制点在于尽量避免“脏数据”，尽量提高命中率。 比如说把一堆数据都读取到内存，然后当个别数据改变的时候又反复刷新整体数据，那么这种“抖动”不但让程序反而变慢几十倍，而且也严重浪费了内存。有些人为了“省事儿”，干脆就用脏数据。 当个别数据改变的时候，Cache单元数据要清空。所以Cache中的数据单元是小数据，例如一个业务 sql 查询的结果就可以以这个 sql 语句（或者其md5）为key，保存查询到的几条数据，就够了。那么核心控制点就在于你设置 CacheDependency 参数上。有好几种现成的形式，可以根据 Duration 绝对时间、最后访问时间、磁盘文件是否被修改、数据库表是否被修改、其它Cache单元是否被级联地被修改、以及其它你自定义的（从CacheDependency类继承的）Dependency 代码来触发，自动让Cache脏数据清空。 可以说，懂了设置 CacheDepenency，才是懂了怎样使用 Cache。

[编程有钱人了]

1:表做好索引 2:做好依赖缓存（参考上面说的），要缓存有用的数据 3:再者就是换数据库，这种事最坏的打算

[正怒月神]

本月工资可以缓存起来。

[飞天凤凰601]

引用 4 楼 wangjun8868 的回复:

1:表做好索引 2:做好依赖缓存（参考上面说的），要缓存有用的数据 3:再者就是换数据库，这种事最坏的打算

这位说了，索引是非常重要的

[Forty2]

引用 楼主 bibbykwan 的回复:

...同一个用户调用多次接口就会做很多次重复工作，用什么办法可以解决？能不能把曾经验证过的信息放到内存上，判断是不需要查数据库？

把曾经验证过的信息放到内存上 这种方式不好，原因是不能纵向扩张（即不能通过添加服务器来扩张）。 在负载平衡的环境下，一个用户调用多次接口，可能是由不同的服务器处理的，因此本地缓存（内存）的效果不好。 可否优化判断账号密码... 用户调用多次接口就会做很多次重复工作 一个有效的方式是采用‘授权令牌’。 第一次判断账号密码后，产生一个‘授权令牌’，它包括了 1、实效时间（可以是几分钟等）。 2、授权范围（可以是）。 3、签名（服务器可快速验证的信息，防止客户伪造或篡改）。 4、等... 服务端并不需要保存‘授权令牌’，而是把它发给用户。 用户在随后的请求中，附上‘授权令牌’，服务器（任何实例）可以快速验证，不用在令牌失效前查询数据库。

[xuzuning]

假如的的服务器允许的并发数为 100，平均每个请求的处理时间是 30ms 那么 3万人全部处理完就需要 30000 / 100 * 30 = 9000ms = 9s 如果你不能接收这个时延的话，那么应扩展你的服务器的硬件。仅靠软件是不能解决问题的

[大然然]

工资不是适时数据，不会时时刻刻都在改变，也就一个月动一次， 你只需要把工资数据读出来放在内存里，然后请求去内存查，比你每次访问数据库要快

[wanghui0380]

额 1.当同一客户重复做为啥要重新验证？ 2.工资信息属于个人隐私数据，你应该采用更可靠安全的手段访问。不然闹出麻烦事了，你项目被砍只是小事，要整出啥大事了就不好收拾了