如何设计签到类后台框架？

[黑主理事长]

各位好，
最近做产品，前期版本经常在用户高峰期出现签到失败的案例，有些情况看起来像是数据库的问题，没记录，导致用户过来质问，我也没有明确的证据

这种架构怎么设计好？
我的看法：
1、签到动作简单化，只插个数据，其他逻辑延时或者迟滞一点再去处理？
这样可以加快签到的并发处理速度和成功率，
另外增加各个步骤的记录，保证签到过程每个步骤都有据可循
2、增加机器、配置。
3、用缓存数据库存这个签到数据？

各位有什么好的建议？

[tianfang]

你的签到都有哪些后台处理？

[X元素]

如果只是一个签到动作的话，楼主还是好好看看代码，没必要使用延迟队列之类的技术，排查一下异常插入的数据 ，由于什么问题引起

[黑主理事长]

引用 1 楼 tianfang 的回复:

你的签到都有哪些后台处理？

典型的处理有高峰期几万人的并发访问，以及做签到处理

[黑主理事长]

引用 2 楼 u011619071 的回复:

如果只是一个签到动作的话，楼主还是好好看看代码，没必要使用延迟队列之类的技术，排查一下异常插入的数据 ，由于什么问题引起

主要是高并发时产生的页面无法访问，或者是签到数据插入失败无数据库记录。当时也没细看日志是啥，就是猜测是高并发导致写数据库失败了。 页面无法访问估计猜测就是并发量太大，但具体原因不懂。您说的延迟队列技术怎么实现能简要给个思路吗？

[tianfang]

使用专用cache/内存表做缓存，（userid，最后签到日期，最后签到日-第一次签到时间戳，连续签到天数，是否已经后续处理），userid做主键/key 根据userid读用户的信息，最后签到日期和今天相同就不更新数据库，否则更新为数据库，后续处理是写历史表等行为，可以发送到jms来异步处理 mysql的内存表的性能足够你处理这个签到性能需求

[黑主理事长]

引用 5 楼 tianfang 的回复:

使用专用cache/内存表做缓存，（userid，最后签到日期，最后签到日-第一次签到时间戳，连续签到天数，是否已经后续处理），userid做主键/key 根据userid读用户的信息，最后签到日期和今天相同就不更新数据库，否则更新为数据库，后续处理是写历史表等行为，可以发送到jms来异步处理 mysql的内存表的性能足够你处理这个签到性能需求

会部署五六个服务器，您的方案对分布一致性支持怎么样？或者说有好的意见吗？

[tianfang]

一致性要求要多高？ 即使短时重复签到，按我上述的签到记录来看，只会影响签到时间戳，后续的处理会是放入消息队列，处理程序再做一次判断当日是否已签到过，就可以避免重复业务处理

[DoZX]

因为没有描述确切的功能 所以也给不出什么建议 但是有几个点我觉的应该可以帮助到你 1：MySQL数据库 1s 可以执行同一行数据的更新 39000+ 次 （不知道你是不是用的MySQL 我想说明的是现在的数据库可处理的并发能力还是很强的） 2：高并发处理 一般是减少延迟(网络延迟/代码逻辑延迟)以及事务处理的时间 3：使用存储过程

[liuyong19832004]

使用事务处理

[liuyong19832004]

使用事物处理，签到记录表中只保留最新的记录，检查表中是否存在用户签到记录，不存在则插入，成功后往历史表中写，存在则更新，并写入到历史表中，插入或更新有返回值，成功后，插入历史，用事物包起来