这是一个创建于 2961 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近项目有做群发的需求，要求根据标签筛选人群后发送，需要避免重复发送。每次发送量在 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