|
|
|
@ -67,6 +67,8 @@
|
|
|
|
|
|
|
|
|
|
https://mp.weixin.qq.com/s/Q_EvlN9LvkdA5M5EharBBA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 40亿个QQ号码如何去重
|
|
|
|
|
|
|
|
|
|
文件中有40亿个QQ号码,请设计算法对QQ号码去重,相同的QQ号码仅保留一个,内存限制1G。
|
|
|
|
@ -81,3 +83,22 @@ https://mp.weixin.qq.com/s/YlLYDzncB6tqbffrg__13w
|
|
|
|
|
|
|
|
|
|
### 方法四:bitmap
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 群聊消息已读未读功能设计
|
|
|
|
|
|
|
|
|
|
企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当前群里其他群成员都是未读状态,陆陆续续有人看了这个消息,这时候消息的详情变成x人已读,y人未读。每条消息对应一个唯一的`messageid(uint64_t)`,每个用户对应一个唯一的`userid(uint64_t)`,应该如何保存这个消息对应的已读未读详情呢?
|
|
|
|
|
|
|
|
|
|
### 简单粗暴方案
|
|
|
|
|
|
|
|
|
|
对于每一个messageid,存当前`read_ids + unread_ids`,当群成员A已读某一条消息时,把A的userid从unread_ids移除写到read_ids上就好了,客户端更新到messageid对应的详情列表,就可以展示m人已读,n人未读。
|
|
|
|
|
|
|
|
|
|
按照目前的设计,每一条消息已读未读详情就要占用8B × 群成员数的内存,如果一个活跃的200人大群,每发一条消息,已读未读就要1600B,如果平均每天消息量是1k,那每个这样的群,每天就要1.6MB磁盘空间,对于客户端来说,特别是手机端,占用磁盘空间是用户不能接受的,又不能把工作消息删了,对于服务器端来说,用户群体如果特别大,那数据库存储这个成本也不小。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### bitmap方案
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 未支付订单超时关闭
|
|
|
|
|