做用户随机匹配的正确做法是？直接在内存存储还是使用数据库？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2729 天前的主题，其中的信息可能已经有所发展或是发生改变。

需求是在 2 分钟内随机匹配一个用户，
目前使用的是 PostgreSQL，
请问有什么框架可以直接支持，
或者有经验的指教一下如何设计这个匹配比较合理

第 1 条附言 · 2017-06-04 09:16:03 +08:00

需求是 2 分钟内双方都在线，
Alice 和 Bob 都向服务器发送了他们要进行匹配的请求，
一旦匹配，具有排他性，不与他人匹配

匹配

postgresql

随机

指教

16 条回复 • 2017-06-04 13:06:33 +08:00

prasanta

2017-06-04 09:16:08 +08:00 via Android

当然是先把用户必要字段放到 redis 里面啦，后台开 celery 定时任务

xiaoc19

2017-06-04 09:29:16 +08:00 via iPhone

@prasanta 没啥经验，操作起来难度如何，哈哈

owt5008137

2017-06-04 09:31:19 +08:00 via Android

如果是做游戏匹配的话我会自己写。放内存

xiaoc19

2017-06-04 09:33:50 +08:00 via iPhone

@owt5008137 我想实现的就是类似斗地主这样，但只有两个人，能说说你的思路和做法吗

mringg

2017-06-04 09:50:38 +08:00 via iPhone

用 redis 维护队列不错

owenliang

2017-06-04 09:54:41 +08:00 via Android

我也想知道不走内存的方案

reus

2017-06-04 09:55:34 +08:00

你用 postgresql，难道数据就不在内存了么……
buffer 开大点，随便搞。
何况 postgresql 也有 notify 功能，完全没有用 redis 队列的必要。

xiaoc19

2017-06-04 09:57:09 +08:00 via iPhone

@prasanta
@mringg
是否 Kafka 也能胜任，而且更简单点？

xiaoc19

2017-06-04 09:58:01 +08:00 via iPhone

@reus 两者性能还是有差距的吧？

xyjtou

2017-06-04 09:59:42 +08:00 via Android

@reus
sql 的 buffer 开大点（比如 16G~32G 内存使用），和 redis 允许使用同样大小的内存，效率差别大吗？

owenliang

2017-06-04 10:00:49 +08:00 via Android

我理解这种全内存简单吧，内存里只放用户 id，客户端心跳保持。数据结构需要线性，考虑用堆吧。

owt5008137

2017-06-04 10:07:26 +08:00 via Android

匹配这种心跳都可以省了。
收到发起匹配请求的游戏服先取消原先匹配，（再随机匹配服务器，匹配服收到请求后进匹配策略池，进超时淘汰队列），匹配成功后推送匹配结果回来，完。
括号里的可以加服务器自动重试。或者客户端直接定时发匹配重试请求好了

reus

2017-06-04 10:08:48 +08:00

@xiaoc19
@xyjtou
效率只需要达到设计要求就可以了，这个要自己测试优化，pg 没问题的，又不是多麻烦的需求。
如果需求变复杂，例如说不是随机的，是有一些条件的，用 sql 数据库就比 redis 方便得多。

owenliang

2017-06-04 10:10:54 +08:00 via Android

sql 有啥好算法吗考虑时间复杂度 b 树和 hash 都难以实现高效的随机吧。

wplct

2017-06-04 11:25:21 +08:00

没必要随机吧，开几个队列好了

leeg810312

2017-06-04 13:06:33 +08:00 via Android

匹配表里用随机函数 select 2 个用户进行匹配，然后从匹配表中删除，这个过程作为一个事务，也就具有排他性了。像楼上所说，考虑扩展功能，需要放在表中，redis 相比之下就无法满足需求了。要说性能，pg 也是很强的。