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

[xiaoc19]

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

[prasanta]

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

[xiaoc19]

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

[owt5008137]

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

[xiaoc19]

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

[mringg]

用 redis 维护队列不错

[owenliang]

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

[reus]

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

[xiaoc19]

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

[xiaoc19]

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

[xyjtou]

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

[owenliang]

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

[owt5008137]

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

[reus]

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

[owenliang]

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

[wplct]

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

[leeg810312]

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