资深研发进阶
一个菜鸟后端开发工程师进阶到资深开发的评判标准之一就是是否拥有工程化思维,因此这篇博文总结一下工作时的常见技术问题,以及资深研发应该如何考虑一个需求
# 常见技术问题
做一个系统,在实现功能后常常会遇到以下情况,这种时候需要考虑这些情况是否需要处理,对业务影响是什么:
# 数据一致性
- 原子性保证:业务中某个操作是否需要完整执行或完全回滚
- 分布式一致性:多节点间数据同步的一致性模型选择(强一致、最终一致等),
- 中间态数据不一致:需要考虑业务场景中,中间态时数据不一致是否对业务有影响
- 双写一致性:系统迁移或灰度时双写场景的数据同步问题,需要考虑数据丢失的风险,是否需要采用事务型双写或异步双写,数据迁移时如何保证平滑切换
- 事务管理:跨服务、跨数据库的分布式事务处理,是否引入 seate 框架,选用何种模式(AT、TCC、SAGA 等),事务执行过程中数据对其他事务是否可见
- 顺序保证:消息顺序性、操作顺序性
# 数据可靠性
- 数据丢失防护:异步写入时的持久化保证,可以使用如消息队列持久化、定时任务重试等
- 数据去重:如何防止重复写入或重复消费,一般可以使用分布式锁+表内唯一索引来实现
- 并发控制:乐观锁、悲观锁、分布式锁
# 高可用与容错
- 单点故障:识别并消除系统中的单点,所谓单点是指这个组件如果失败,会导致整个系统失败,因此需要引入冗余组件,不只是一个机器可能会挂机,可能一个机房也会挂机
- 故障转移:主从切换、故障检测与自动恢复机制,可以参考心跳检测、gossip、一致性协议(选主)、故障转移策略这个流程来处理
- RPC 高可用设计:熔断、限流、降级、超时、负载均衡、失败策略(重试、快速失败、访问集群中其他机器等等)
# 性能与扩展性
- 水平扩展能力:无状态设计、数据分片策略
- 缓存策略:缓存层级、缓存更新策略、缓存穿透/击穿/雪崩等分布式缓存常见问题如何处理
- 数据库性能:索引设计、查询优化、读写分离
- 性能优化:判断动作是否可以异步处理,比如使用消息队列削峰填谷等;是否可以批量操作,合并请求;是否可以使用缓存,减少数据库压力
# 数据存储与访问
- 分库分表:分片键选择、是否需要考虑扩容方案、跨片查询(一般是存到 es 中)
- 冷热数据分离:归档策略、存储成本优化
- 数据备份与恢复:备份频率、恢复时间目标(RTO)、恢复点目标(RPO)
- 多数据源管理:数据源路由、读写分离的延迟处理
- 大数据量处理:分页策略、游标方案
- 容量规划:流量预估、资源评估,可以参考历史业务做判断
# 可观测性与安全性
- 日志、监控、告警:日志级别、日志聚合、链路追踪的 TraceID、核心指标监控(QPS、延迟、错误率)、告警阈值设置、分布式调用链跟踪
- 灰度发布:流量控制、快速回滚能力;需要考虑向前向后兼容、接口版本管理
- 故障演练:混沌工程(通过主动注入故障来验证系统韧性的实验性方法)、灾难恢复演练、事先定好故障预案等
# 遇到线上问题时
遇到线上问题时,如果不是你负责的项目,可能无法很快定位问题,因此一个资深研发会遵循以下 SOP,来快速处理问题
1,如何发现问题
- 系统的监控指标和日志,如 CPU 占用率、内存占用率、请求响应时间等,是否存在异常
- 用户反馈、营运同学、合作方告知有异常发生。出现这种情况,说明系统可观测性做的不好,理论上我们应该在用户之前感知到这个问题
2,如何定位问题
理论上我们应该先定位后止损,但是也存在长时间问题定位不到的情况,这时候需要根据具体情况来判断是否需要紧急处理。一般问题都是根据日志、监控、报警来定位的,这就需要考虑一个系统的可观测性做的是否完善。一个系统的可观测性是根据日志、追踪、度量来评估的
3,如何止损
- 第一时间通知相关人员、上级,告知问题发生,询问是否需要紧急处理
- 如果线上需要很快处理问题,请在下面5种方法中选择一个来紧急处理:重启、扩容、关开关、回滚、摘流
4,如何修复
改代码重新上线,根据监控系统确认问题是否解决
5,扩展分析
需要横向比较一下,所负责的系统中是否存在其他类似问题。比如线上出现问题是,锁粒度太大了,你就需要考虑整个系统中是否有其他地方所使用的事务锁粒度大,是否可以优化一下锁的粒度
最后更新: 2/25/2026, 8:20:00 AM