这是一个创建于 2589 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近项目有做群发的需求，要求根据标签筛选人群后发送，需要避免重复发送。每次发送量在 3000w 左右。
由于是根据筛选条件筛选后再做发送的，所以如果是实时分页查询然后进 MQ 的话可能会有重复，比如： 根据某个标签循环分页查询，同时有管理员对人群做打标操作，结果分页乱掉，有些已经被查询过的人可能会被“挤”到后续分页。
这种情况有什么比较好的规避方法？ 这个量级是不是可以先把人 id+发送任务 id 做唯一索引做个单独存储 相当于做个快照，然后再对这份“死”数据分页查询？
看微信公众号后台也有根据标签做群发的功能，不知道是咋实现的？
 |
1
RainFinder 2017-11-20 17:38:02 +08:00  1
发完标记个状态不就好了
|
 |
2
sunnyfinger OP @RainFinder 嗯，是可以的。主要担心这些数据会比较多，不过好像也没什么太好的办法- -
|
 |
3
daemonghost 2017-11-20 17:59:23 +08:00
@sunnyfinger 试试用 redis 的 set 来去重
|
 |
4
owenliang 2017-11-20 18:04:28 +08:00 via Android 4
思路不对。
发送方要保障的是必达。 接收方要保障的是幂等。 发动方为了必达，一定会重试，at least once。 如果接收方直接是客户端，那么就客户端去重。 如果接收方是一个信箱，那么就数据库去重。 |
 |
5
yougeren 2017-11-20 18:06:23 +08:00
bitmap,haperloglog
|
|
7
owenliang 2017-11-20 20:03:15 +08:00 via Android
从选型角度来说，hbase 适合 scan 场景，可以按 timestamp 区间 scan，只推送某个时间点之前的用户，具体自己学习 hbase。
|
|
8
sunnyfinger OP @owenliang 嗯，这样按职责划分就很清晰了。本来想发送端去取的时候就尽量规避可能重复查询的情况，这样看来意义可能也不是很大，还是需要有个唯一 messageId 去区分才是
|
Select Language