如何避免订单或表单重复提交？
这个用术语来讲，是保证用户操作的幂等性。有以下思路：
- 前端对按钮点击事件做好处理，避免短时间内可以点击两次，且都能成功调用后端服务接口。比如对按钮设置状态，在后端接口正常响应前再次点击无效或禁用按钮。
- 后端接口执行逻辑前，先查询，判断之前未做相关处理。即插入数据前先查一下数据是否已存在，更新数据前比如判断下行的版本号（每次更新后版本号不一样，需自己维护），避免重复操作。不太推荐。
- 缓存表单token。即每个表单提交前，前端先从服务端接口获取一个token，作为表单隐藏字段或header提交时带上。服务端生成并保存该token，在接收到操作请求后，先验证该token是否在缓存中存在，存在则为首次提交操作，操作成功后，服务端删除该表单token；若不存在，则考虑请求伪造或重复提交。推荐，这个是缓存可以借助session或redis。
如何保证数据（比如某商品库存）并发更新的安全性？
比如商品库存，下单成功后会减少，在并发下单时，保证依次递减，不出现一些数据异常比如销售量高于实际库存的情况？
方案1：借用c#中的 lock 语句
非集群的系统，可以借用c#中的 lock 语句 ，基于Monitor。它将会锁住代码块的内容，并阻止其他线程进入该代码块，直到该代码块运行完成，释放该锁。这在非分布式系统中，可以很好的解决线程安全问题，具体如何使用请自行百度。
锁这个用处，可以想象动车里的卫生间，有人进去后门就立马锁上了，别人进不去，想进去得等待。等上一个人进去办完事儿出来了，卫生间门的锁开了，下一个人才可以进去。
方案2：借用Redis的setnx(key,value) 命令
参考：c# 多线程编程、线程安全 - AI大胜 - 博客园 (cnblogs.com) 最下面一节。
10万人同时在1000台设备考勤打卡如何设计程序架构和考勤数据流转？
工人通过前端人脸识别设备进行考勤，考勤数据最终存储到远程数据库。假设有 1000 台人脸设备，10万人同时考勤。请描述该场景下你会如何设计程序架构和考勤数据流转？
来自：一次面试时的笔试题。
接口访问的并发量最多1000，不用考虑高并发和集群，一个web站点就OK了。
每次打卡一条数据，也就每天30w-60w，最多不超过100w的数据量。所有数据存取是重点。
方案一：内存缓存+后台定时任务将数据批量插入SQL数据库。
每次个人打卡，将记录存放到内存缓存中，用并发集合存放打卡记录信息。最好每个设备一个key一个集合。写个后台任务在固定的时间点，往数据库批量插入一次记录，同时从缓存中剔除。
数据库没只保存近两个月的大卡记录，之前的记录归档到月打卡记录统计，并只详细记录异常打卡情况，比如迟到的。
持续更新……
更新于：2023.5.26