这是一个创建于 1384 天前的主题，其中的信息可能已经有所发展或是发生改变。
当前有比较多的 set，每个 set 大约在 500-2000 个，需要频繁地进行 sunionstore 操作，并且需要产生交集的两个集合概率均匀，当 sunionstore 比较多的时候，由于单个 redis 打满了单核 CPU，导致阻塞。
尝试方案如下：
1. 集群方案，由于频繁同步，CPU 虽然打满了，但是只能提高一点点性能
2. 优化代码，不使用 set，但由于业务代码复杂，需要时间改动
请问有没有更好的方法，能够实现快速“扩容”的效果呢？
尝试方案如下：
1. 集群方案，由于频繁同步，CPU 虽然打满了，但是只能提高一点点性能
2. 优化代码，不使用 set，但由于业务代码复杂，需要时间改动
请问有没有更好的方法，能够实现快速“扩容”的效果呢？
1 条回复 • 2021-02-06 17:21:11 +08:00
 |
1
keakon 2021-02-06 17:21:11 +08:00
不知道你的业务场景是怎样的，我弄了 1 万个 set，每个 set 1000 个整数，sunionstore 1 万次不同的 set 也就 200 多 ms 。但是因为修改比较多，会触发 bgsave，可以关闭掉在 slave 去做。
如果这也是瓶颈的话，在应用层读出来合并再写回去会慢一个数量级。 不过如果不需要保存 sunionstore 的结果，这样虽然慢，但是可以节省 redis 的 CPU 。 |
Select Language