欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。
目录
- 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)
这部分规范主要针对涉及机器学习、数据处理等场景，强调样本质量、模型评估和数据生产流程的管控。
在数据驱动的业务中，“垃圾进，垃圾出”。高质量的数据和严谨的算法模型是产出有价值结果的前提。
规范：
- 样本质量要保证： 训练模型所用的样本数据必须具有代表性、无偏性，并经过严格的清洗和标注。
- 特征提取要谨慎： 特征工程是模型效果好坏的关键。提取的特征需要有明确的业务含义，并进行充分的验证。
- 模型选择要评估： 需要根据业务目标、数据特点和计算资源，选择合适的模型，并从多个维度（如准确率、召回率、性能）进行综合评估。
- 数据生产：
- 节点新增需管控： 新增数据生产或处理的节点，必须经过评审，明确其必要性和对上下游的影响。
- 开发生产莫混用： 严禁在生产环境进行数据开发和测试，必须建立隔离的开发测试环境。
- 执行效率调最优： 对于数据处理任务，需要持续优化其执行效率，降低资源消耗。
)
