它们都是衡量软件好坏的标准

 1 1.qps：Queries Per Second，每秒查询率，一台服务器每秒能够响应的查询次数，每秒的响应请求数
 2         -如何估算自己项目的QPS？--取决于：并发量和平均响应时间
 3             0.1s * 10 =1s
 4             -并发量：同一时刻，能并发几个，假设并发量是1 
 5             -平均响应时间是0.1 
 6             -qps是10
 7 
 8 
 9 2. TPS：Transactions Per Second，是每秒处理的事务数，包括一条消息入和一条消息出，加上一次用户数据库访问
10     TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。
11     例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个T，产生三个Q（代表3次请求）
12 
13 
14     
15 3.并发量
16     系统同时处理的请求或事务数，可以直接理解为：系统同时处理的请求数量
17     QPS = 并发量 / 平均响应时间 
18     并发量 = QPS * 平均响应时间 
19     例如当前系统QPS为1w，每个请求的响应时间都是2s，那么并发量就是2w 
20 
21 
22 4.PV
23     PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到--->
24         比如咱么路飞项目--》记录课程访问量
25         查询课程详情接口中---》加入 redis自增（course_view）
26 
27 
28 5.UV
29     UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到
30 
31 
32 
33 6. DAU(日活)
34     DAU(Daily Active User)，日活跃用户数量。常用于反映网站、app、网游的运营情况。
35     DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似
36 
37 
38 
39 7.MAU(月活)
40     MAU(Month Active User)：月活跃用户数量，指网站、app等去重后的月活跃用户数量

什么是接口幂等性问题，如何解决？

 1 # 幂等：幂等（idempotent、idempotence）是一个数学与计算机学概念
 2     -一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同
 3     -接口幂等性：无论调用多少次，产生的效果是一样的
 4        -get 获取数据天然幂等
 5        -put 修改数据天然幂等
 6            -修改库存（数字加减）：不幂等
 7        -delete 删除 天然幂等
 8        -post 新增数据，会出现不幂等的情况，要把它做成幂等性的
 9         
10 # 解决方案：
11    # token机制
12         1、下单接口的前一个接口，只要一访问，后端生成一个随机字符串，存到redis中，把随机字符串返回给前端
13         2、然后调用业务接口请求时，把随机字符串携带过去，一般放在请求头部
14         3、服务器判断随机字符串是否存在redis中，存在表示第一次请求，然后redis删除随机字符串,继续执行业务。
15         4、如果判断随机字符串不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行
16         
17         
18   #  乐观锁机制---》更新的场景中
19        update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1
20     -扣减id为2的商品库存---》进入到扣减页面---》数据库中查一下这个数据的version号[假设是10]
21     -访问扣减库存接口---》带着之前的version来了
22     -后端的sql如下：
23     update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 10
24     -第一次可以顺利扣减
25     -第二次：带的版本号还是10---》sql执行失败了--->扣减不了了
26     
27     
28  # 唯一主键
29     这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键
30     
31  # 唯一ID(unique)
32     调用接口时，生成一个唯一id，redis将数据保存到集合中（去重），存在即处理过
33     前端来到下单页面，前端生成唯一id，只要下单，带着这个唯一id到后端---》后端取出来--》存到reids中--》继续后续操作---》带着同样的id过来，redis中有了，这个就不继续执行了
34     
35  # 防重表
36     使用订单号orderNo做为去重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。
37     这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。
38     
39  # 前端：
40     按钮只能点击一次
41     
42 
43 ---------------------------------------------------------------------------------
44 补充：悲观锁乐观锁
45 
46 悲观锁和乐观锁是多线程并发编程中的两种思想，主要用于解决在并发环境下对共享资源的访问和修改问题。以下是关于这两种锁的详细解释：
47 
48 悲观锁
49 定义：
50 
51 悲观锁假定在修改数据的时候，其他线程很可能也会同时修改该数据，导致数据的不一致。因此，它采取一种保守的策略，即在修改数据之前先对数据进行加锁，阻止其他线程对该数据进行访问或修改。
52 实现原理：
53 
54 悲观锁最典型的实现方式是使用数据库的排他锁（Exclusive Lock）或数据库的行级锁。
55 当一个线程尝试修改数据时，它会先尝试为该数据加上排他锁。如果加锁成功，则可以进行修改；如果加锁失败（表示该数据正在被其他线程修改），则当前线程需要等待或抛出异常。
56 在整个修改过程中，数据都会被锁定，直到事务完成并提交后才会释放锁。
57 特点：
58 
59 以更多时间的代价来保证数据的完整性。
60 效率低，但安全性高。
61 乐观锁
62 定义：
63 
64 乐观锁则假定在修改数据时，其他线程一般不会同时修改该数据，因此它不会立即对数据进行加锁。而是在数据提交更新时，才会正式对数据的冲突与否进行检测。
65 实现原理：
66 
67 乐观锁的实现主要基于版本号（Version）或时间戳（Timestamp）机制。
68 在每次更新数据时，都会先获取当前数据的版本号或时间戳，并在更新时检查该版本号或时间戳是否与数据库中的版本号或时间戳一致。
69 如果一致，则表示数据没有被其他线程修改过，可以执行更新操作，并将版本号或时间戳进行自增；如果不一致，则表示数据已被其他线程修改，更新操作会失败。
70 特点：
71 
72 效率高，但安全性相对较低。
73 适用于多读少写的场景。
74 总结
75 悲观锁和乐观锁各有优缺点，适用于不同的场景。悲观锁适用于写操作频繁的场景，可以确保数据的一致性和安全性；而乐观锁则适用于读操作远多于写操作的场景，可以提高系统的并发性能和吞吐量。在选择使用哪种锁时，需要根据具体的应用场景和需求进行权衡。