100个人在各自电脑上操作同一个表单页面，并且他们同时往服务器提交表单，为啥不会串数据？

[anj3]

如题，是IIS什么技术保障入库时数据不发生错乱？

[inuyasha1]

数据库层面，数据库是有锁的，比如说表锁，行锁，

[King奕航]

之前还真遇到过类似的问题，通过我的业务场景和解决办法，LZ看下有没有什么启发。 之前的场景：是两个人同时提交单据，获取编号时，会出现重复，一个运行3年的系统，居然现在才发现这个问题。。。 起初我以为是缓存的问题，后来发现代码里根本没有类似“锁”的东西来控制。之前我还想过，按理说数据库应该会有相应的控制，但后来一细想，在没有事务的前提下，如果两条线程同时更新到数据库的一条数据，这样是允许的，在数据库不做调整的情况下，只能在代码的角度去考虑。 修改之处：在提交时加lock锁定，在一次请求完成之后，再执行另一次请求，编号获取不再重复。 仅供参考。

[以专业开发人员为伍]

"两个人同时提交单据，获取编号时，会出现重复"这并不是“串数据”现象，而是脏读。 串数据是指部分数据是A事务的、部分数据是B事务的，逻辑并不完整一致。而脏读、不可重复读和幻读数据等都是在已经保持数据库更新操作一致性的前提下，出现的设计错误。

[以专业开发人员为伍]

数据库系统最起码地，会保证每一个事务对数据库的更新一致性（要么成功更新、要么失败回滚）。 脏读是指事务A还没有提交之前，事务B就读取到了有冲突的脏数据。数据库系统默认地保护级别就是这样的。所以大多数人都知道，多用户系统数据持久化，使用数据库引擎进行设计开发，非常简单方便（尽管性能最低）。

[以专业开发人员为伍]

数据库系统默认地保护级别就是这样的 --> 数据库系统默认地保护级别就是防止脏读的 所以对于”运行3年的系统，居然现在才发现这个问题“这类问题，用简单的数据库事务概念，可以取代什么lock 设计问题（实际上，一般人也很难理解如何跨服务器来lock）。 而数据库事务是基础。 而 lz 问的问题，其实是这个基础的下一层概念，lz 还没有理解和问道数据库事务的概念。 而现代的高性能分布式大数据处理系统，则是把这个传统的做法看作一种糟粕，设计理念根本不同！

[以专业开发人员为伍]

从设计上就会仍然那么粗糙 --> 从设计上就不会仍然那么粗糙 将来的设计语言会更彻底地面向对象，更强调惊人数量的活生生的对象各自独立占有一个进程（管程）并且相互通讯，而弱化什么线程、进程之类的底层概念。这时候会在问题的解答中看出区别！ 不是说你“一会儿学这个语言一会儿那个语言”的问题，不管你学什么都会遇到这个深度问题，都会发现过些年服务器端大数据分布式和智能化对程序设计架构产生了改变，就好像20年前强调“三层架构”一样地，将来会去随随便便地就以分布式的架构为操作系统基础，那么程序设计时天生就不再用什么加锁、同步、线程之类的概念作为回答这类问题的抓哟术语了，而是换了一套设计知识。

[以专业开发人员为伍]

lz 这个问题，其实连“脏读”都没有涉及到，而仅仅是问“为什么不会串数据”的问题。 比如说对于同一个银行账户，一个操作要给其增加100元，另一个操作并发地要给其减少200元，lz的问题并不是涉及到了有关脏读、幻象读而造成数据结果错误的问题，他还只是问为什么不会产生”增加200元“这种混乱结果、而总能看到保证是一个操作完整规范地执行完毕。 这个问题，是多用户改写数据库数据的知识，最底层的一个知识。一点都不涉及到策略，就好像我们学解二元一次方程组做应用题之前，先要学习四则运算一样，如果连加减乘除都不会那么更不可能开始在二、三年级学习解二元一次方程组。

[以专业开发人员为伍]

现在的程序设计——以至于大多数程序员的思维定势——许多还是用结构化的过程方式来理解，尽管手中用着 OOPL，口中已经玩弄了十年OOAD名词儿术语，可能对于大数据编程时仍然还是结构化过程的思维方式。这就好像是一堆”傀儡进程“，在不断地拼命地去发指令给数据库系统去争抢数据库事务瓶颈控制权。 而大数据高并发的算法设计，是屏蔽了数据库层，把对象分布在网络上，整个网络就是一台计算机（或者说是大脑）。这样的基础之下，回答这类问题的底层知识就彻底改变了。

[weixin_43183110]

100个人各自操作自己的数据不会串，这个和开发语言没有关系，完全是数据库系统的事情了，另外IIS的每一次请求，IIS都会分配一个工作线程来处理。

[outby]

我只知道ASP.NET里面有个锁，这个锁就是当在共同操作的临界点加上去，无论有多少个用户过来，每次都只能一个用户进入，其他用户等待这个用户操作完出来后再进来。我知道你的意思是每个用户操作后可能还要加以判断然后再作出其他的操作，操作完了再让其他的用户进来，所以这个锁合适你。

[闭包客]

简单地说，不排队就会串数据，要保证不串数据就要排队。一般这个排队的逻辑是在数据库处理的，因为这是数据库常见的应用场景。

[King奕航]

当时用的和这个方案类似，https://bbs.csdn.net/topics/391943405，发现CSDN每个角落都有这位大神的存在...

[以专业开发人员为伍]

引用 34 楼 boatking 的回复:

首先感谢指点。 想请问，"简单的数据库事务概念，可以取代什么lock问题" 中使用数据库事务如何解决？

你可以学习 ADO.NET 的 BeginTransaction 语法，当然更主要地是学习数据库事务。 将多个数据库修改语句显式地放在一个事务中，最后统一 Commit 操作，才能保证事务要么完整提交、要么失败回滚。而不会只保存一部分事务数据（串数据）。

[以专业开发人员为伍]

并不是跨进程 lock 阻塞。数据库事务机制并不是盲目阻塞多用户多进程并发访问数据库系统。如果盲目阻塞，那么数据库系统性能早就崩溃了、早就被废弃了。

[以专业开发人员为伍]

当两个进程分别 update 同一条数据库记录时，即使没有显式声明事务，数据库系统也会默认地指定事务，来保证 update 语句要么完整更新成功、要么失败回滚，绝不会只执行一部分 set 数据命令。 即使是允许脏读的事务保护级别（最低一级的数据库事务级别）也会保证提交或者完整的一致性。这是事务的根本。

[正怒月神]

iis不管数据库链接的问题。 而是每个用户请求时，当对数据库进行操作时，会先到数据库连接池拿取链接，然后进行操作数据。 所以不同的用户使用不同的数据库连接池，也就不会错乱了。 用完了之后，会放回池子里，等下一个用户继续使用。

[token不能为空]

IIS不负责数据写入的 楼主可以一步步来，先了解下线程池相关知识 毕竟这些东西用起来简单，但实际是结合了众多设计和优化出来的 可不是三言两语就解释清楚的

[King奕航]

引用 32 楼 sp1234 的回复:

数据库系统默认地保护级别就是这样的 --> 数据库系统默认地保护级别就是防止脏读的 所以对于”运行3年的系统，居然现在才发现这个问题“这类问题，用简单的数据库事务概念，可以取代什么lock 设计问题（实际上，一般人也很难理解如何跨服务器来lock）。 而数据库事务是基础。 而 lz 问的问题，其实是这个基础的下一层概念，lz 还没有理解和问道数据库事务的概念。 而现代的高性能分布式大数据处理系统，则是把这个传统的做法看作一种糟粕，设计理念根本不同！

首先感谢指点。 想请问，"简单的数据库事务概念，可以取代什么lock问题" 中使用数据库事务如何解决？

[以专业开发人员为伍]

例如不同线程分别（同时）对数据库发起不同的会话去修改冲突的内容，例如不同进程分别（同时）对数据库发起不同会话去修改冲突的内容，例如不同机器上（上的进程）分别发起会话修改数据库.......如果说的是数据库问题，那么这一切问的其实都是数据库原理知识。 如果说的是其它底层数据持久化或者网络服务对象持久化架构，则是要用别的知识来回答。

[张天星]

引用 3 楼 zhexiaode 的回复:

[quote=引用 2 楼 yenange 的回复:]
你先确定是不同的人操作自己的相关记录， 还是100人操作同一条记录？
如果是不同的人操作自己记录， 就是各回各家， 各找各妈， 当然没什么问题。
如果 100 人操作同一条记录， 串数据是肯定的， 只能用时间戳之类的来防止。

跟 C# ， IIS 没什么关系， 任何语言都是一样， 只是个业务问题而已。

是不同的人操作自己记录，“各回各家”是这么回事，但是我是想问.net平台是怎么支持的，是不是IIS为这100人同时分出100个子进程？因为进程间隔离。[/quote]
web是多线程，一个人一个线程。
操作自己的数据不串，这个是数据访问层做到的，不是web或者iis做到的。