【打卡功能实现思路】

做打卡功能的思路

打卡大概流程

首先生产消息

首先进行一些人员信息校验之后往mq存入消息同时把这个打卡信息添加到缓存进行用户的及时反馈
然后呢在往mq存消息的时候可能会出现消息丢失这个几种原因吧 首先mq本身出现问题比如说宕机了。这个宕机的问题我们利用集群主从的方式来去避免宕机的情况 宕机的情况的时候我们也可以用熔断的机制来进行及时的解决。
需要查看自己的打卡情况这时我们的数据可能没有完全的落入数据库这时需要从缓存去查这个用户的打卡信息），缓存的打卡信息我们是利用的hash的一种数据结构
因为这个打卡信息需要一项目的维度去查看所以我们在创建缓存的时候大的key我们设置为日期的八位数+项目id 然后里面的元素的key设置为
用户id+（0或者1，0代表上午打卡1代表下午打卡）然后去异步的往mq进行丢数据 然后回调失败的时候进行一个处理就是把打卡失败的直接往一个重试打卡数据表里面
这样我们在某个时间段进行定时任务去往这个打卡表里面塞入数据，这个失败次数到了一定数量之后我们会选择熔断的一个机制，失败数量多了起来代表我们的mq那边出了一些问题所以暂时不能打卡操作

消息到mq后的处理

首先消息存到mq之后我们要保证不丢失，mq默认是异步刷盘的一个机制，我们需要修改成同步刷盘来保证消息的不丢失。就是每次进来消息进行一次持久化存入磁盘，这样可能会引起吞吐量的降低但是可以保障消息的不丢失因为这些打卡消息很重要涉及到薪资的发放。
我们部署的时候肯定不会单体部署，需要横向扩展进行多主多从的架构来部署这一样可以保证我们的mq高可用高性能的一个状态。

消息的消费

接下来就是到了消费消息的时候了我们采用的是先消费后确认的一种方式来完成，这样的有点在于我们消费者消费的时候可保证消息的不丢失，
但是这样还有一个问题就是重复消费，这个问题呢rocketmq本身是没有办法解决的所以我们需要从业务上进行解决我用了两种方案
第一个就是利用缓存进行判断是否重复消费我们可以利用不布隆过滤器来解决这个问题，我们在生成消息的时候用雪花算法生成一个唯一的key
这样我们往bitmap存数据的是否可以减少哈希冲突的问题，然后在sql上也进行一次优化或者是在打卡数据表里面进行添加一个唯一索引来保证消息的唯一性
整个打卡过程大概就是这个样子的

总结

这个是我在我实习公司做的一个功能实现方式大概就是这样的