这个文章的背景
最近抖音上不是对这个签到功能究竟用redis实现还是mysql实现吵得挺厉害的吗？这个需求我从个人的工作经验来说一下自己的看法。
补充一下我对签到功能的理解，就是很多app上的，一般给你一个显示今天是否签到的功能，然后显示这个月签到的天数，哪一天签到了，哪一天没签到。签到够了多少天有奖励之类的功能。
简单来说，就是有人说，签到数据应该要放mysql，2000w数据没有问题。有的人说要用redis，用bitmap。
不知道怎么说，各有各的说法，只是没想到互联网新赛道是抖音，这都能在抖音上互相阴阳。
下文纯属个人看法。
先说说redis
redis 嘛，传统意义上的三方缓存组件，查询速度快，支持的qps比较高。如果是一个月度统计的功能，例如说每个月每天都要签到啊，每个人每个月一个bitmap就行了。创建的时候算一下什么时候到月末，设置一下过期时间。
当然，如果需求复杂一点，由统计需求的，那是另外的说法。
例如：简单一点的，连续签到7天，给一个奖励。（感觉用户签到的目的就是为了拿奖励吧，不然签到来干嘛，没有奖励我肯定不会点签到。）
bitmap 有一个 BITCOUNT方法，可以统计指定范围内1的数量。用户签到的时候算一下最近7天的位移里面是不是7个1就行了。
或者说，查询连续签到7天的用户。。。。。。。我当时看的时候，视频里面的博主说他面试别人的时候，别人的回答简单总结：遍历。当然，博主的支持的是放到mysql里面。（后面我说说我对mysql 的看法）
我不知道现在大家怎么想的，这种需求，直接用数据分析不行吗？阿里云odps也不贵吧？数据分析那么多实现，为什么一定要用redis 或者mysql。。。。。。
至于mysql 方案
我的想法（单纯个人对数据库使用的看法），如果我要把某个业务的数据存放到mysql，可能会有以下考量：
- 更新频率：基本不更新，如日志类型的就没必要了
- 数据的重要性：丢失了会不会有问题
- 是否需要事务
- 数据结构的复杂性：数据结构经常改动的，比较适合nosql
- 存储成本
- 等等
这个案例来说，如果存储到mysql，如果存储的是每个用户当天的签到记录，我个人觉得真没必要。即使加一个连续i去签到的天数字段，也很不灵活。前7天连续签到了，做数据统计的时候当天没有签到，那算不算连续签到了？分库分表吧，你要提前设计好分库或者分表的数量和路由键等等，做统计的时候一样麻烦，多库查询。
哦，还有历史数据问题，这种签到功能总不能连续几个月的数据都保留吧，保留了有什么业务价值我暂时想不到。如果是不需要保留的，那就数据归档或者清理也要额外的工作（redis直接过期就没了）
我的看法
bitmap和mysql 各有各的局限，bitmap 快速简答高效实现签到功能，有数据统计的需求走odps，然后数据回流mysql业务表，然后根据业务表做相关的业务操作。
都什么年代了，还用MySQL 做数据统计，不是不行，但有更好的方法。
