所就职的公司是一家互联网视频公司，存在大量的实时计算需求，计算uv，pv等一些经典的实时指标统计。由于要统计当天的实时

UV，当天的uv由于要存储当天的所有的key，面临本地内存不够用的问题，异常重启后会丢失本地缓存，造成计算结果不准确的问题。；如果使用外部缓存比如redis，memcache等，在高并发时会出现效率问题。

在不断的实践中，不断改进方案，积累了如下经验：

1.使用bitMap可以节约内存。

使用redis的bitMap,并发时候会有问题。

a .只使用本地内存

由于reidis在数据量较大时，并发会达到瓶颈，干脆绕过redis，全部使用基于本地内存的bitMap方案。这样即省内存，又避免了redis的并发达不到性能要求的问题。

b.使用备份来解决DAU异常恢复问题。

实时任务异常时，由于历史缓存丢失，造成数据不准确问题。

定时或者定量将本地缓存的b的redis持久化的一个redis，hdfs，kafka中，这些数据只起到副本备份的作用。

当worker异常重启时，先从备份中恢复历史的历史的redis中的DAU的数据。然后再开始实时计算。

c.如何备份？备份哪些数据？

---

解决思路：

使用redis，hdfs等来存储备份数据，

bitMap的数据序列化，保存到文件，然后上传到hdfs上，或者redis上面。

dauBolt，接收到消息时，在execute方法中先后台恢复本地缓存，恢复成功后，再进行后续的业务处理。

---

使用kafka来备份当天的uuidSet  ：需要备份当天的所有的uuid 

副本的备份每5分钟备份一次：使用kafka作为副本备份，可以 每1分钟或者每积累2W条UUID，就将这些UUID封装成一个msg，发送到kafka的一个topic主题队列uuidSetTopic里面，谁先到达执行条件就先执行那个？ msg中要包含备份时候的时间戳发送时候的当前时间。

DauBolt:用来恢复当天到目前为止的uuidSet；dau相关的指标统计等；DauBolt会接收到uuidSetTopic的数据，还有userActionTopic的数据。

处理逻辑：

1.DauBolt的计算逻辑：

如果接收到的是uuidSetTopic的数据：

取出数据中的时间戳，

判断是否是当天的备份数据，如果不是，就不处理，丢弃掉。

判断是否本地缓存已经恢复，如果恢复，就不处理，同时通知dauSet_Spout不再读取uuidSetTopic的数据了。

如果没恢复， 就解析uuidSet，并逐个恢复到bitMap中。

判断恢复完成的逻辑：

取uuidSetTopic的数据中的时间戳dt。

dt 和当前时间的差小于1.5分钟，（uuidSetTopic 最迟是一分钟一条。1.5分钟可以保证这个时间段内只有一个因为凑不够2w条的强制发送的）并且msg的uuid个数小于2w，则说明恢复进入尾声了，基本上追上了当前时间。

连续两次差小于1.5分钟，uuid个数小于2w，也说明追上了最新的值；

dt 和当前时间的差 小于1.5 分钟（90s）， 假设当前时间差是50s，msg的uuid个数等于2w，说明目前数据较多，不到一分钟就生产了2w条数据；接着往下取数据，将时间差的阀值缩小当前的差值50s；继续该逻辑，直到时间差大于设置的值，说明追上了最新的数据，本地缓存恢复成功。

如果当前时间和bolt的启动时间的间隔差超过15分钟（也就是允许有15分钟来恢复dau的计算的本地缓存），也认为恢复完成（不能无限期的等待它恢复啊，但是要在日志中打印出来这种情况）。

2.如果接收到的是userAction的数据：

取出数据中的uuid

当前的本地缓存是否已经恢复: 如果恢复，取出uuid，判断是否在本地的bitMap中，如果不在，更新DAU的值。

如果没有恢复，不进行uuid是否在bitMap的判断。

将uuid 发送到uuidSetSave_bolt.

恢复线程需要根据时间来判断是否恢复成功了。

当storm 任务启动前，先向dauBakTopic发送一条消息，UUID为空set，时间戳为当前时间。