ben548

@msaionyc 牛逼，这样做确实不用联表也不用子查询也避免了 not in ，用这个方案了

@RoninZc 可以是可以，我也是这么想的，不做缓存失效，因为可能存在缓存失效后一直更新失败的情况，那么会出现缓存一直为空接口返回数据也为空的状态。
现在想的优化是是不是在高并发的情况下是不是可以减少竞争锁的请求量，比如已经有一个用户触发了异步更新，那么我就直接返回。
比如有用户触发了异步更新就直接设置一个标志位这种处理方式，如果这个标志位存在就不去更新，更新成功后就删除这个标识位，但是又可能存在更新失败的可能，还有这个标志位删除失败导致永不更新的情况。所以细想其实还是有很多细节值得考虑的，我是在想有没有更简单的处理方式。

@lanlanye 没记错的话另起一个协程，也要等这个更新缓存的协程执行结束才能返回结果吧，而且这个更新缓存获取数据的操作需要依赖外部接口，有请求失败的可能

@icql 而且 bitmap 如果存用户的 uid 的话，uid 是雪花算法生成的的 32 位的数字，用 bitmap 其实非常占内存，本质上用 bitmap 基本上就是为了省内存，不过感觉这种场景下也完全没有节省到内存，甚至比用 zset 占用更多

@icql bitmap 只能查状态和总数吧，不能遍历关注用户。。。不能拿到关注的用户数据的话，push 怎么发呢？

@nealHuang 大佬的方案有点高端啊。。。

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

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

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