@starxg 哈哈，go-zero 的延迟队列貌似用了这个组件

@mineralsalt 确实，但是公司目前只有 kafka 这一个 mq ，如果有类似 rabbitmq 那样的组件，那处理起来就很容易很简单了（当然也是依赖加消费者。。。）

@guxingke ？你这个是数据库的 order by 吧，redis 不能这么干

@SorcererXW 好麻烦

@leogm9408leo 查 90-100 条，有 200 个分片的话，就要查出 20000 条数据出来排序后再分页，这有点伤啊

@sunhuawei 我也想到的是这个，WHERE start_time <= last_start_time AND id < last_id ORDER BY start_time, id DESC ，这个语句应该是能解决我的问题了

@SakuraSa score 一样的情况不是会丢数据吗

@rrfeng 确实是这样，性能影响非常有限，我也是自己去思考，总结一下，这玩意面试的时候有的时候爱问，思考完理解透了面试就不慌

@tsutomu 对的，这些都是 big key 的坏处，然后也不是不可以解决，hash 分片就行，分的足够碎就不会有这样的问题了

@awalkingman 百万级别的 hash 不是 big key 吗？我理解是的，big key 和 many key 是怎么划分的呢

我自己想了一下，其实可以先存 redis 里面，然后监听 redis 的变更，订阅变更事件，同步更新 local cache 的数据，查询优先查 local ，查不到就查 redis ，并且查完存 local ，这样应该就是一个多级缓存的概念了，这个其实也是我想要的效果

@seth19960929
中策 bitmap 的方案有一个比较大的弊端，如果 userid 不是那种连续递增的类型，会导致大量空间浪费，目前我们的用户 id 是雪花算法生成的 18 位长 id ，我感觉不太适合用 bitmap 了
下策的方案 big key 还是不太建议的，带来的不仅仅是 getall 的 O(n)操作导致的阻塞问题还有很多其他的问题，要用 hash 还是会考虑分片

@awalkingman big key 还是不太建议的，带来的不仅仅是 getall 的 O(n)操作导致的阻塞问题还有很多其他的问题，要用 hash 还是会考虑分片

@cloudzhou 这个差不多就是我的想法了，第二次做我应该会直接存 hash 里面，然后再做分片，晚点去写个测试案例，来试试是不是用 hash 存储会比用几十万个 string 存更省内存

@nicreve 目前是需要同步给他们的，我理解是这样会更好一些吧，因为这样数据部门不与业务绑定，相互隔离会是更好的设计吧，不然我们这边的规则改了，他们也要跟着一起改吗？很多时候没有及时通知容易出问题

@octobersnow 因为需要记录是不是第一次生成，只有第一次分配桶，才触发同步数据部门，我需要记录这样一个是否已经分配过的状态，来判断是否需要同步分桶结果给到数据部门

@matrix1010 就是 0 ，1 ，2 ，3 这种数字，分到对应桶的用户都是一个 value

@nicreve 因为需要记录是不是第一次生成，只有第一次分配桶，才触发同步数据部门，我需要记录这样一个是否已经分配过的状态，来判断是否需要同步分桶结果给到数据部门

@xiaofan2 是 long 类型，目前设计不是用 hash ，考虑用 hash 是想着 100w 的 string key-value 数据内存占用应该是大于一个 100 万 key-value 的 hash 数据的（没做测试，只是靠印象和经验）