数据很多，限制内存，如何去重
对于大数据量去重的场景，我们可以考虑使用位图(Bitmap)
Bitmap 是使用二进制来表示某个元素是否存在的数组。用0和1来表示存在与不存在
使用Bitmap的话，一个数字占用1bit，大大减少内存消耗量
Bitmap 的常见应用场景如下
- 去重:如果需要对一个大的数据集进行去重操作，使用 Bloom Filter 来记录每个元素是否出现过。比如对巨量的 QQ号/订单号去重。
- 数据统计:Bitmap 可以用来记录某些特定事件发生的情况，例如某个用户是否登录某个用户是否点赞过某个视频等
- 布隆过滤器:布隆过滤器是一种基于 Bitmap 的数据结构，主要用于判断一个元素是否存在于一个大的集合中。相较于Bitmap，占用的空间更少，但其结果不一定是完全准确的。（所以如果使用了位图去重后，还想进一步节省空间并允许一部分差错，可以使用布隆过滤器）
Redis实现延时任务（订单，红包等超时如何实现）
延时任务常通过Redis 过期事件监听来实现
Redis 过期事件监听实现延时任务功能的原理?
Redis 2.0 引入了发布订阅 (pub/sub) 功能。在 pub/sub 中，引入了 channel(频道)的概念
pub/sub 涉及发布者(publisher)和订阅者(subscriber，也叫消费者)两个角色
运行流程如下：
- 发布者通过 PUBLISH 投递消息给指定频道
- 订阅者通过 SUBSCRIBE 订阅它需要的频道。订阅者可以订阅多个频道
Redis 过期事件监听实现延时任务功能的缺点?
4. 时效性差
过期事件消息是在 Redis 服务器删除 key 时发布的，而不是一个 key 过期之后就会就会直接发布。
过期数据的删除策略有两个:
1.惰性删除:只会在取出 key 的时候才对数据进行过期检査。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
2.定期删除:每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响
定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有干秋， Redis 采用的是定期删除+惰性删除
因此，就会存在到了指定时间 key 还未被删除，进而没有发布过期事件的情况
5. 多服务实例下存在消息重复消息的问题
Redis 的 pub/sub 模式只有广播模式，这意味着当发布者向特定频道发布一条消息
时，所有订阅相关频道的订阅者都能够收到该消息。这时，会出现多个服务实例重复处理消息的问题，这会增加代码开发量和维护难度
