精粹汇总:大厂编程规范(持续更新)
欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧,偶尔也分享一些杂谈💬。
有很多很多不足的地方,欢迎评论交流,感谢您的阅读和评论😄。
目录
- 1 引言
- 2 并发控制 (Concurrency Control)
- 3 事务控制 (Transaction Control)
- 4 数据库与缓存 (Database & Cache)
- 5 远程调用 (Remote Procedure Call)
- 6 异常处理与日志 (Exception Handling & Logging)
- 7 算法研发与数据生产 (Algorithm & Data)
1 引言
看到蚂蚁的编程军规有点触动,让AI汇总来一下各大厂编程规范,去掉了基础的命名规范,看一些常见但偶尔总有同事会忽略的。
内容由AI生成,本人做整理核对。如有错漏,还请联系更正,感谢。
2 并发控制 (Concurrency Control)
并发控制是指在多线程或多进程环境下,对共享资源的访问进行有效管理,以避免数据竞争和不一致的问题。这在处理高并发场景时至关重要。
在高并发场景下,如果缺乏有效的并发控制,多个线程同时读写共享数据,很容易导致数据错乱、更新丢失等严重问题。例如,经典的“库存超卖”问题就是典型的并发控制不当造成的。
规范:
- 一锁二判三更新: 在更新共享资源时,首先获取锁,然后再次判断是否满足执行条件,确认无误后才进行更新操作。
- 并行查询超时: 当需要并行查询多个外部服务时,应为每个查询设置合理的超时时间,避免因某个服务延迟而导致整个请求长时间阻塞。
- 乐观锁与悲观锁: 根据业务场景选择合适的锁策略。对于读多写少的场景,可以使用乐观锁(如版本号机制)来提高吞吐量;对于写多或冲突严重的场景,则需要使用悲观锁(如synchronized或ReentrantLock)来保证数据一致性。
3 事务控制 (Transaction Control)
事务控制是确保一组数据库操作要么全部成功,要么全部失败的机制,是保证数据最终一致性的核心手段。
在许多业务场景中,一个完整的业务操作可能包含多个数据库读写步骤。如果其中任意一步失败,整个业务操作都应该被回滚(视业务场景而定),以防止出现数据状态不一致的“半拉子”工程。例如,在转账操作中,扣款和收款必须在同一个事务中完成。
规范:
- 悬挂监控要及时: 对于跨服务、长周期的分布式事务,需要有完善的监控和告警机制,及时发现并处理“悬挂”(长时间未完成)的事务。
- 必须防止空回滚: 在进行事务回滚操作时,必须先判断对应的正向操作是否已经执行,防止因网络延迟等原因导致的回滚请求先于正向请求到达,造成数据不一致。
- 定是最终一致性: 在分布式系统中,强一致性往往会牺牲可用性。因此,在很多场景下会采用最终一致性的方案,通过可靠消息、定时任务补偿等方式,保证数据在一定时间窗口内最终达到一致状态。
4 数据库与缓存 (Database & Cache)
这是关于如何高效、安全地使用数据库和缓存的规范,旨在提升系统性能和稳定性。
数据库是系统的核心数据存储,其性能直接影响整个系统的响应速度。而缓存则是提升性能的利器,但如果使用不当,也可能引入数据不一致、缓存穿透等问题。
规范:
- 查询执行走索引: 所有数据库查询都必须经过EXPLAIN分析,确保利用到了合适的索引,避免全表扫描。对于大数据量的归档表,要根据查询场景建立合适的索引。
- 链接要看机器数: 数据库连接池的大小需要根据数据库实例的规格和应用的QPS进行合理配置,避免连接数过多耗尽数据库资源。
- 缓存使用:
- 数据过期要控制: 为缓存数据设置合理的过期时间,并通过被动失效(LRU等)和主动更新相结合的方式,保证数据的时效性。
- 缓存击穿要兜底: 当热点数据失效时,大量请求会直接涌向数据库,造成“缓存击穿”。可以通过加锁或者使用分布式锁的方式,只允许一个线程去查询数据库并回写缓存。
- 存储容量要考虑: 缓存资源是有限的,需要评估业务数据量,合理规划缓存容量,并制定清晰的数据淘汰策略。
5 远程调用 (Remote Procedure Call)
远程调用是指一个服务调用另一个独立部署的服务所提供的接口,是构建分布式系统的基础。
在微服务架构下,系统被拆分为多个独立的服务,服务之间通过远程调用进行协作。如果远程调用不稳定,会直接影响整个系统的可用性。
规范:
- 接口规约要明确: 服务提供方需要提供清晰、稳定、向后兼容的接口定义。调用方必须严格按照接口规约进行调用。
- 请求返回超时: 必须为所有远程调用设置合理的超时时间,并配置相应的重试机制。
- 考虑调不通: 在设计上必须考虑到任何远程调用都有可能失败的情况。需要有相应的降级、熔断、限流策略,保证在下游服务不可用时,核心业务流程依然能够继续或者优雅地失败。
6 异常处理与日志 (Exception Handling & Logging)
这是关于如何规范地处理程序运行时的异常情况,以及如何记录有价值的日志信息的规范。
健壮的异常处理机制是系统稳定性的重要保障。而清晰、规范的日志则是排查线上问题、进行数据分析的唯一线索。
规范:
- 日志打印要规范:
- 日志级别(INFO, WARN, ERROR)要使用得当。
- 禁止打印无用日志,避免日志泛滥。
- 敏感信息必须脱敏。
- 日志中必须包含唯一的请求ID(TraceId),以便串联起整个调用链路。
- 降级限流需落实: 在系统负载过高或依赖的服务出现问题时,为了保证核心功能的可用性,需要主动降级部分非核心功能或限制流量。
- 监控校对全覆盖: 必须对系统的核心指标(QPS、延迟、错误率)、业务指标(订单量、用户数)以及资源使用情况(CPU、内存)进行全方位的监控,并设置合理的告警阈值。
7 算法研发与数据生产 (Algorithm & Data)
这部分规范主要针对涉及机器学习、数据处理等场景,强调样本质量、模型评估和数据生产流程的管控。
在数据驱动的业务中,“垃圾进,垃圾出”。高质量的数据和严谨的算法模型是产出有价值结果的前提。
规范:
- 样本质量要保证: 训练模型所用的样本数据必须具有代表性、无偏性,并经过严格的清洗和标注。
- 特征提取要谨慎: 特征工程是模型效果好坏的关键。提取的特征需要有明确的业务含义,并进行充分的验证。
- 模型选择要评估: 需要根据业务目标、数据特点和计算资源,选择合适的模型,并从多个维度(如准确率、召回率、性能)进行综合评估。
- 数据生产:
- 节点新增需管控: 新增数据生产或处理的节点,必须经过评审,明确其必要性和对上下游的影响。
- 开发生产莫混用: 严禁在生产环境进行数据开发和测试,必须建立隔离的开发测试环境。
- 执行效率调最优: 对于数据处理任务,需要持续优化其执行效率,降低资源消耗。