@clocean 我们也是，真的很烦，大家都不愿意去，但是又好像不得不去一样

@KevZhi 国内地址证明是必须的吗？租房没有信用卡怎么证明国内地址呢？

@buf1024 这种情况，我情愿被裁

@xiebiao 扎心了老铁

@qeqv 躺平啊

@dsb2468 确实是这样，我也觉得要有个全局观，了解现在是什么情况再说具体要怎么处理

@kita 可能种植牙也有不同材料的吧，或者根本就没问清，其实是另一种治疗方案，也说不准

@kita 这个也是个需要考虑的因素，不过感觉华齿口腔还行吧，我印象中它在上海也算是开了好多年了，印象中牙科这个生意挺暴利的，没有那么容易倒闭

@ssqygyddxfsh 能种植当然是最好的方案了，就是太贵了，一口牙一辆轿车的钱，哎，所以可能还是退而求其次，选活动义齿吧

@metavacuum 确实这个种植牙不是这个价格，我感觉应该是别的方案吧，感觉倒也不算骗

@setsunakute 半年没交公积金就可以销户提取了，具体你度娘找找就可以看到相关文章了

@4pmBaoZi 无所谓了，反正不可能在上海买房，取出来能重新开户就行

@KKLeon 北京离大谱

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

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

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

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

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