数据库单节点并发与服务端验证

1、时间戳

2、查询某条数据，判断某字段值时，使用排它锁（with (updlock)）进行锁定

3、直接修改，根据ID查询 并且某标识等于符合修改条件的标识，根据影响行数判断是否修改成功（不确定是否能防止并发，但已经将并发的可能降到最小）

　　不是所有操作都需要控制并发的，根据项目的具体需求与进度或并发产生的可能性来权衡，比如，核心数据的操作、抢单、商品买卖或并发导致损失较大的等类似情况，

　　应尽量控制并发。比如，并发产生不会造成影响或影响较小（两个用户同时修改成功，只是增加一条操作日志等）可以不用控制并发。

 

4、服务端验证可以简单的防止重复操作，但无法控制并发，线程A查询某条数据验证某字段值合法后修改，另一个线程B与线程A同时到达或比线程A晚到达，但在线程A修改

之前，线程B查到了该字段值合法，此时A与B均修改成功，A从查到改的这段时间越长发生并发的几率越大，有效的缩短时间间隔，可以大大的减少并发的产生。

　　缩短时间间隔主要就是提升查询和修改语句的性能，在数据库直接验证要比将字段查询到程序中验证或多或少会缩短时间间隔。

5、一条数据可以被多个人同时操作的情况，是否需要控制并发，要看具体的应用场景。

　　由于业务原因或严谨项目有且只有一个人操作成功 应控制并发。

　　可以操作此条数据的用户较少，不会产生大面积的并发，即并发可能性小，即使并发产生的影响较小或可以忽略，可以不控制并发。

6、一条数据只可以被所属用户操作（大多数APP数据），是否需要控制并发

　　客户端的连续两次点击可以造成并发，正常情况下，连续两次点击请求到达服务器是有时间间隔的，如果此时间间隔要是小于第四条中所列出的时间间隔，服务端验证是失效的，也有些时候由于网络的传输原因，先发送后到达，后发送先到达的情况，二者同时到达服务器，导致并发。由于是单用户操作，正常情况下，前端控制重复点击即可。　　

　   如果是APP程序，查询回来都是符合条件的数据，一般情况连服务端验证其实都可以省略，但为了防止多终端同时登陆一个账号进行恶意操作，可以限制只有一个终端可以登陆或服务端进行验证或控制并发，具体怎么如何控制需要根据具体项目的应用场景与严谨性。

　　网页项目，同一操作可以在不同模块中或多个电脑登陆同一账号，解决方案同上。

 

总结：

　　对于严谨的项目，要求可能发生并发并且并发影响不可忽略时，应控制并发对数据造成毁坏，编写代码应考虑全面，那些模块之间会差生冲突或者并发，编写sql时，应严谨，同时工作量与项目周期大幅度提高。

　　对于现在开发的大多数项目，均非以上严谨项目，项目周期压缩至最短，恨不得今天来的需求，下午就得上线使用，对于这种项目，本应严谨的程序，也变得松散，即能够正常使用即可，出现问题在解决问题，如果这个项目真的用起来的话，开发时间是很短，但维护的时间却遥遥无期，真是天下武功，唯快不破啊。

　　即使糊弄，也分个三六九等，好一点的，核心数据比如财务或者涉及到钱的处理并发，其他的地方按需防止重复操作进行服务端验证即可，若并发导致数据，手动修改过来继续使用。坏一点的连服务端验证都省略了，两个模块均有同样的操作，A模块点击执行成功，B模块点击也同样执行成功，当然这样导致数据乱点不怕，但不能影响软件正常使用。

　　在日常开发中，应该养成好的开发习惯，修改、删除之前进行验证的时候，如果不是严格意义上的控制并发，使用 update table set a=1 where id=1 and 某标识=0（即标识为0的时候才可以修改）根据影响行数判断修改是否成功，这样不仅可以提升程序执行的效率，同时也可以大大的降低并发（不确定这种方式是否可以防止并发），倘若修改失败，需要根据具体的状态值返回详细信息，在进行一次查询即可。

my QQ :771775671 欢迎指正。