请求有并发的时候，该怎么处理数据

在程序里，还是在数据库里做，要根据你们自己系统的情况来设计。

如果程序员技术是传说级，并且很勤奋，喜欢加班，那么直接在程序里做会更好，因为压力不会集中在数据库上。在程序里做，如果处理流程不是串行的，需要考虑对被处理的数据进行加锁来防止并发请求对数据的骚扰。分布式的模式下甚至还要考虑分布式锁。

如果程序员技术只是精良级，或者程序员打算偷懒，那么在数据库里做会更方便。比如写个简单的串行存储过程，然后就不用加班可以去美美地喝咖啡了。

第三方回调的时候是否有他们的回调 id，有的话可以在存储回调数据的表里将这个 id 标为主键或唯一索引，然后每一个回调请求过来就尝试执行插入操作，失败就放弃这个请求，成功就继续调用业务逻辑。

为了防止服务刚 insert 成功就挂掉导致业务逻辑没有正确执行，可以在回调数据记录里加一个处理状态，处理成功就更新状态为成功，那么在服务重启的时候可以先去查一下有哪些未处理完成的记录，重新处理即可。可以用事务来保证数据库多次读写的原子性，避免由于程序中断或分布式处理导致的脏数据。

如果你处理回调请求的时间比较长，那么也可以用消息队列，收到第三方回调就把回调数据插入到消息队列，插入成功就立即返回给 第三方成功，这样第三方就不会持续给你发回调。后面的集群以适当的负载匀速消费队列里消息即可。

@libook 嗯 用个唯一索引来保存回调 id 的应该是可行，现在接受后的确还要处理业务逻辑也用了消息队列了

我的理解是根据订单号加个锁就好了吧。redis 分布式锁。

select * from 订单表 where id = ? for update 上行锁
commit 或 rollback 解锁