多入口重复签到问题

12/12/2015来源:Java教程人气:960


背景

前台的变更:

app3.0版本将原先在app上的签到入口转了h5页面中。

后台的变更:

签到不再调用原先app-api模块的接口,而是调用creditmall-api的接口,也就是说将签到从那边转了过来。

数据库

签到表从dbapp转移到了dbcreditmall

产生的问题:

android,ios的3.0上线时间是不一样的,积分商城签到的上线时间与以上2个也是不一样的。
如果积分商城先上,那么会出现2个签到,app+积分商城h5。
如果android/ios先上,那么会出现没有签到入口。
签到得积分的规则是每天:5.10.15.20.20.20...因为签到表的不同,新的表是空的,所以头3天不管用户累计签到了多少天,都只能从5分开始累计。而且如果以后需要统计签到总的记录时,会比较麻烦。

解决的思路

多签到问题:

因为2个版本的客户端,以及积分商城的h5上线时间都是不一样的,所以出现2个签到的入口时不可避免的。
现在要避免的是:用户一天签到2次,其实就是往2个数据库的2张表里插了2条数据,又分别给用户加了积分。
而我这恰好又有积分记录明细表,可以通过这个表来判断用户是否签到过了,然后h5中再决定是否让这个按钮失效,这样是比较友好的。
这样做我这边是没有问题了,他那边签到完了再来我这页面,我能够知道他已经签到过了,能假装是同一个入口。
但是如果用户是先进的h5(我这)签到,再去app上签到,这就没有办法了,这再去修改原先签到的判断接口。
所以第一种解决方案就是:修改签到状态判断的接口。新旧2个模块同时修改。

不管新的旧的,签到的时候都得调用积分商城service的加积分服务。
如果我把上面的判断加到了这个地方(虽然听上去有些不合理),那么只需要修改这一个地方就行了。
但是与上面不同的是:上面做的能够使得签到按钮变成已签到状态,做到以假乱真;而这里只能做到点了签到后不给你加分,或者是再告诉你你之前签到过了。

第一种方法比较合理,但是麻烦;第二种方法稍微简单了一点,但是感觉不怎么合理。
所以我们采用了第三种方法:不管了,,,让他多签到一次又何妨!!

累计签到断点问题

要解决这个,相比上面的问题,是要简单的多。
虽然没有签到记录表可以差,但是又积分记录明细表可以查。
选择指定用户id,积分类型为签到,然后再来个日期范围,直接就查到数据,知道现在应该是第几次签到了。

所以最终的解决方案就是:前后差不了几分,不管他了。。。。

总结

应对多签到问题:

新旧入口都加判断

应对签到断点问题:

没签到表查的时候去查积分明细表再加以分析

最终的解决方案:

不管他