常见并发问题有哪些？大佬给你总结了！（下）

lsekfe

极限值并发的问题
　　由极限值而导致的并发问题，那么什么又是极限值呢？
　　极限值：标准要求的数值范围的界限，“极限值"也被称为"极限数值”、“临界值”、“界限数值”。
　　我们举例来说明，某个party上要搞一个抽奖环节，具体安排为：当天23:00 ~ 23:59还在场的朋友，每人一个礼物；每个人另外有3次抽奖机会；发朋友圈的，还能再获得1次抽奖机会；已经抽到一等奖的，不能再获得二等奖和三等奖；中奖概率按照预估概率进行计算；如果已中奖数量达到上限，必须停止抽奖。
　　根据这些设计的并发测试场景：
　　①当天时间23:00 ~ 23:59，给在场每个人一份礼物；
　　②在场每个人有3次抽奖机会；
　　③高调发朋友圈，可以再来一次抽奖机会；
　　④已获得一等奖的，不能再获得二等奖和三等奖；
　　⑤中奖概率按预估概率进行设定；
　　⑥已中奖数量达到奖品数量上限，该奖项停止。
　　在这个场景中，先分析测试对象分别有：活动时间、抽奖次数、中奖概率、奖品数量上限、中奖规则。
　　那么设计的并发测试用例覆盖点为：
　　①测试活动：不在活动时间范围内，也能参与抽奖；
　　②抽奖次数：未分享朋友圈炫耀的，抽奖次数超过3次；
　　③抽奖次数：朋友圈高调炫耀的，抽奖次数超过1次；
　　④中奖概率：设置中奖概率有效的小数位数；
　　⑤简化数量上限：奖项数量上限控制；
　　⑥中奖规则：已中一等奖，是否还能中二等奖、三等奖。

　　压力并发的问题
　　由压力负载而导致的并发问题，可以归类于性能问题，今天我要说一些数据库事务的隔离级别。
　　隔离级别有4个，由低到高依次如下：

　　Read uncommitted
　　未授权读取、读未提交，即事务B读取到了事务A未提交的数据。
　　如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过"排他写锁"实现。
　　该隔离级别避免了更新丢失，却可能出现脏读。

　　Read comitted
　　授权读取，读提交，即事务A先读取了数据，事务B紧接着更新了数据，并提及了事务，而事务A再次读取该数据时，数据已经发生了改变。
　　读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。该隔离级别避免了脏读，但是却可能出现不可重复读。

　　Repeatable read
　　可重复读取，读取数据的事务将会禁止写事务，写事务则禁止任何其他事务。
　　该隔离级别避免了不可重复读取和脏读，但是有时可能出现幻读。这可以通过"共享读锁"和"排他写锁"实现。

　　Serializable
　　序列化，提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个执行，但不能并发执行。
　　如果仅仅通过"行级锁"是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚刚执行查询操作的事务访问到。
　　序列表是最高的事务隔离级别，同时代价也花费最高，性能最低，一般很少使用。在该级别下，事务都会乖乖的顺序执行，不仅避免脏读、不可重复读，还避免了幻读。
　　那么，什么是脏读、不可重复读、幻读呢？

　　脏读
　　一个事物读取到了另一个事务未提交的数据操作结果。

　　更新丢失
　　更新丢失包含以下两种情况：
　　回滚丢失，当2个事务更新相同的数据源时，如果第一个事务被提交，而另外一个事务却被撤销，那么会连同第一个事务所做的更新也被撤销，即第一个事务做的更新丢失了。
　　覆盖丢失，当2个或多个事务查询同样的记录然后各自会以最初的查询结果更新该行时，会造成覆盖丢失，因为每个事务都不知道其他事务的存在，最后一个事务对记录做的修改将会覆盖其他事务对该记录做的已提交的更新。

　　不可重复读
　　Non-repeatable Reads，一个事务对同一行数据重复读取2次，但是却得到不同的结果，包括以下情况。
　　虚读：事务R1读取某一数据后，事务R2对其做了修改，当事务R1再次读取该数据时得到不同的值。
　　幻读：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者取消了第一次查询中出现的数据（不要求两次查询的sql语句相同）。这是由在两次查询过程中由另外一个事务插入数据造成的。
　　通常的数据库设置默认隔离级别为Read committed（授权读取、读提交）。

　　异常数据干扰并发的问题
　　对于这类情况的异常数据测试也可以称之为系统健壮性测试。
　　测试重点是，要根据业务逻辑或系统相关的配置情况构建能够造成异常的测试数据，要求这些数据不能被当做正常数据处理，也不能影响其他正常数据。
　　例如：测试人员构建测试场景为不断触发定时批处理任务，如果码农在代码中忽视对异常数据逻辑处理，就会造成数据库连接池饱满、内存溢出、遇到异常数据直接报错中断（待执行任务队列越来越多）等问题。
　　此类并发测试关注点不是同步并发，而是逐步加压的并发数量。
　　这个难点相对于前几个问题，提升了一个level，因为这要求对测试人员了解系统架构配置及数据流逻辑，所以，这就需要测试的大佬们多多努力。争取全都是全栈~