有一个资源（S1）,每次初始化需要花费（T1）的时间。现在的做法很简单，后台首次启动的情况下，会异步初始化（N）个可用的（S1）放在redis队列（Q1）中。每次用户开始请求（S1）时，简单的从队列（Q1）中取一个（S1）返回给用户，同时后台会判断如果队列里可用资源长度小于（M）时会异步生成一个新的（S1）放进队列（Q1）中。但是这样的方案有问题：
针对问题1， 想过使用两个队列进行解决，开始初始化（S1)时，将（S1）push到队列（Q1）中，等（S1）初始化完成推送到（Q2）中，每次取都从（Q2）中获取。但是这样还是存在一些问题...
 |
1
clino Jun 4, 2015
请求用队列,返回就不一定用队列了吧
比如用户请求以后生成一个信箱,将请求和信箱号一起发到队列中,异步处理的地方初始化完以后直接把结果发往信箱即可 这样用户发出请求以后只要一直等自己的信箱有返回就行了 没搞过实际这种情况,根据楼主的信息初步想的 |
 |
2
pubby Jun 4, 2015
预先生成好结果放到队列，只是解决突然的一波请求峰值，持续的高并发还是没法解决。
最后瓶颈还是在T1耗时的那个步骤，如果无法优化只能堆硬件 |
 |
3
fangjinmin Jun 4, 2015
这样只能你通过在生产环境上，取到访问的峰值，在这个峰值基础上优化你的程序。
监控你的S1资源的个数，根据变化调整你的程序吧。 |
 |
4
mhycy Jun 4, 2015
高并发用缓存...
数据有更新的时候同时刷新缓存. |
 |
5
wy315700 Jun 4, 2015
去看看排队论
应该基本上知道用户量， 然后用户的访问时间是一个近似泊松分布 根据每个时间段的用户访问量来设计队列大小 |
 |
6
Septembers Jun 4, 2015
|
|
7
wy315700 Jun 4, 2015
|
 |
8
ltttx OP 谢谢各位，原提问里的作法确实只是解决了并发峰值的问题（谢谢 @pubby ) 。可能问题本身的需求（让用户快速得到资源S）在现阶段是不大合理的，最简单的解决办法就是让用户等待。这样能规避很多问题，同时能解决潜在的资源浪费问题。也谢谢 @wy315700 , @Septembers , 又学到一招，排队理论。
|
Select Language