研究这个需求是因为朋友开发公众号遇到一个问题，问题是这样的：100个用户同时去扫一个二维码关注公众号，公众号在调用我们服务器的接口，我们收到关注事件，然后去数据库查询该用户是否存在，不存在就添加，存在就修改状态，但是问题出来了，1000个请求同时发过来的时候，数据库里惊奇增加了几条重复的数据，也就是说一个用户在数据库中有2-3条数据（部分用户）。
这显示是不对的，但是导致这个问题的原因是什么呢？去网上搜了一下，之前对并发没什么概念，这一搜，大概找到根源了，原因就是出现了脏数据。
脏数据：当一个事务正在访问数据，并且对数据进行了insert/update/delete操作，而这种操作还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这
个数据。因为之前对这个数据的操作是还没有提交，那么另外一个事务读到的这个数据是脏数据(Dirty Data)，读取脏数据的过程称为脏读，依据脏数据所做的操作可能是不正确的。
出现脏数据的原因原来是并发导致的，所以接下来就是并发，之前一直不理解并发，原因是以为请求的处理是一个一个的，上一个处理完了才会开始下一个，就是代码执行一样，上一一条语句执行完了才执行下一条，天，我之前是多么天真啊！如果是这样，支付宝的大神们也不至于在过年总烧高香祈祷服务器不要崩溃。了解并发，先知道下面这些关键字的概念是比较好的。
并行：真正意义上的同时执行，但是这种情况一般只出现在多核CPU，但是对于内存单元上的数据而言
，同一个数据每次只能给一个线程操作，
也正是有与这样的等待导致了IO阻塞，然而数据库的锁机制却是处理在操作A的时候，不能操作B，防止B操作影响A，和前面的一个数据每次只能给一个线程操作好像有点矛盾，
其实是因为系统为每个线程都分配了执行时间的，比如操作A的线程这个操作本身需要1秒，但是系统只分配了0.5秒，那么A操作肯定执行不完，系统就开始执行B操作了，
等B操作执行0.5S的时候，A操作再回来执行，如果B操作时删除，这时候记录不在了，A再回来执行就出问题了，数据库的锁其实就是让后面线程的等待当前的A操作执行完，
在这期间，操作系统不会再让其他线程进来，直到A执行完毕。
并发：串行，一连串蜂拥而至，服务器一会处理A，一会处理B，交替处理，导致感觉是在同时处理，也就是并发的现象。
并行和并发可以理解成电路的并连和串联。
Q.E.D.
Comments | 0 条评论