2024年开发过程中遇到的问题（持续补充）

下文将添加一些个人或团队在2024年开发过程中遇到的问题，主要用于反思和总结。

1. 压力测试，出现到了某一个QPS之后，无法继续提升

• 发生时间：2024-04
• 发生阶段：测试

最近在进行话费系统压力测试时，遇到一个比较奇怪的问题，就是在某一个QPS之后，无法继续提升，一直维持在这个QPS水平。 web服务器的日志也没有出现异常，数据库也没有出现明显的性能问题。

1.1 尝试解决方案

1. 追加服务器节点，提升服务器负载能力。
   • 措施：服务器节点从2追加到4
   • 效果：压力测试，QPS仍然维持在原有水平。
2. 追加服务器CPU和内存资源，提升服务器性能。
   • 措施：服务器CPU从2核增加到4核，内存从4G增加到8G
   • 效果：压力测试，QPS仍然维持在原有水平。
3. 排查数据库，Redis，MQ等是否存在性能瓶颈。
   • 排查结果：无瓶颈现象。
4. 排查网络，服务器，路由器等是否存在网络问题。
   • 排查结果：无网络问题。

1.2 最终排查结果

经过各种尝试，最终排查到是由于外部数据库（非同一供应商）限流导致流量一直上不去，压力测试QPS无法继续提升。

1.3 总结

1. 数据库等外部服务依赖，要注意是否有限流策略。
2. 减少外部依赖，尽量使用内部服务。
3. 避免使用不同供应商的云产品，避免网络问题。

2. 某一简单SQL语句，执行时间长

• 发生时间：2024-05
• 发生阶段：开发

近日开发一个功能，需要关联查询两个表，一个简单的关联查询，但是返回结果非常慢，耗时几十秒，SQL语句如下：

SELECT
	s1.name,
	s1.province,
	s1.city,
	count( merchant_code ) AS totalall,
	s1.menid 
FROM
	store_mxbc s1
	LEFT JOIN rongshu_coupon_order AS s2 ON s1.menid = s2.merchant_code 
	AND s2.create_time >= 1714492800 
	AND s2.create_time <= 1716566399 
    AND s2.reseller_id = 25455 
GROUP BY
	s1.id 
ORDER BY
	s1.province_sort

2.1 问题排查

1. 数据库表结构是否存在索引？

答： s1和s2表都存在索引，其中s1.menid和s2.merchant_code都有索引。 另有create_time和reseller_id索引。

2. 数据量是否过大？

答： 数据量不大，10万+条记录。

3. explain分析SQL语句，是否存在性能瓶颈？

答： explain分析结果，正确使用索引。但是ref显示func，说明sql执行过程中出现了内部函数运行，需要进一步分析。

2.2 最终分析结果

• 通过分析表结构，发现s1.menid和s2.merchant_code字段编码不一致，导致mysql自动进行类型转换，导致查询效率降低。

2.3 总结

• 索引的建立，字段的类型选择，explain分析，都可以有效提升查询效率。
• 统一数据库字段编码格式，避免类型转换，提高查询效率。

3. 代码中存在bug，导致线上环境大量订单失败

• 发生时间：2024-03
• 发生阶段：正式

开发时，为了方便测试，注释掉某些方法，导致推送线上环境，导致线上环境大量订单失败。

3.1 问题经过

• 开发为了测试方便，注释掉了某些方法，提交代码时未进行严格检查，导致线上环境大量订单失败。
• 线上环境订单失败，导致客户投诉，影响客户满意度。

3.2 总结

1. 代码提交前，应进行严格检查，避免引入bug。

• 追加代码多人review机制，追加上线环节多人审批机制。
• 追加预发环境，预发环境接入少量流量，测试功能是否正常。
• 发布版本时，增加回滚机制，避免长时间服务不可用。

2. 线上环境出现问题，应及时上报，及时沟通。

• 及时上报问题，及时沟通，避免造成损失。