增删改查是大部分框架的功能,如果有两个并发请求修改同一个数据怎么办?或者插入本来应该是唯一却重复的数据怎么办?或者插入和修改有其他辅助动作比如保存到另外的表比如校订审计日志。
你会首先想到“事务”,事务确实能够让一组操作一起可靠安全执行,要么全部执行,要么一个也别想执行,如果有两个同时发生的并发事务怎么办?使用事务隔离级别,这是ACID中的定义,关系数据库内部机制中就是这么做的。
但是,如果使用隔离级别,比如可串行化serializable (以及可重复读),你的系统会变得很慢,依赖于不同关系数据库,同时发生的事务也许需要应用代码编码指定重试几次,这就很复杂,其他不是很严格的隔离级别则会带来更新丢失或幽灵phantom 读。
即使你正确地设置了合适隔离级别,你也能用代码正确处理了事务的失败错误情况,但是隔离并不能解决所有并发问题,比如应用级别的数据约束,也就是说,是一种复杂的业务逻辑约束或规则,很难使用数据库的表键约束来实现的;单纯使用数据库技术也不能解决重复插入的问题;更不能解决应用级别的并发问题;不能解决数据并发等问题。也许你试图通过获得数据库锁来解决这些问题,但是锁是可怕的,锁有写锁 读锁和排他锁,如何避免死锁?不是每个程序员能够有经验和锁打交道的。
双重提交问题是经典问题,它说明了不是所有问题都可以通过数据库方式单独解决的,双重提交很多人的解决办法是:使用一个token代表每个请求,并存储在数据库,使用数据库的唯一键约束,这样,重复记录就无法插入,这种问题使用API比较复杂,因为你得