基于消息队列的多进程匹配及进程数的确定及并发数与qps的关系

如题，由于业务需求，需要在规定时间内完成数万用户的互相匹配，当然，匹配时间越短越好。

如何获取最匹配的对象这一步由es实现，通过restful api 的方式访问es。

在整个匹配流程中，进程需要依次访问es、redis、mysql，可以认为是三个独立的网络i/o操作。

如图是简单的匹配过程示意图。

假装有图~

为简单起见，假设这三个网络i/o的rt都在10ms。

单进程情况下，进程依次访问，总共耗时30ms。

也就是整个流程的响应是时间是三个操作时间的相加，t_single_process = t_es + t_redis + t_mysql

多进程情况下，不同的进程可以同时访问es、redis、mysql。

多进程由消息队列实现，如下图所示

假装有图~

平均每次匹配耗时由以上三个操作中耗时最大的操作决定，t__multi_process = max(t_es, t_redis, t_mysql)

很显然，在平均情况下，多进程的匹配速度会快于单进程。

并且，每个独立网络i/o的耗时越相近，多进程的优势越明显。

实际应用中需要通过合理的流程拆分，使得各个耗时操作能独立并且耗时尽量相近，以最大程度的发会多进程的优势。

同时，进程数应大于等于独立的耗时操作数，太少则不能充分压榨每个独立耗时操作的吞吐量，太多也没用，还得等待~

另外，我们平时说的高并发与qps是什么关系呢？

特意去查了一下，qps = 并发数 /平均响应时间。

假设qps = 100，且每个请求的响应时间相近，则平均响应时间 = 10ms,

辣么，并发数 = 100，

数值上和qps一样诶~

有没有不一样的场景呢？

 

转载于:https://www.cnblogs.com/jiage666/p/11094762.html