歡迎來到啾啾的博客🐱。
記錄學習點滴。分享工作思考和實用技巧，偶爾也分享一些雜談💬。
有很多很多不足的地方，歡迎評論交流，感謝您的閱讀和評論😄。

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)

這部分規范主要針對涉及機器學習、數據處理等場景，強調樣本質量、模型評估和數據生產流程的管控。
在數據驅動的業務中，“垃圾進，垃圾出”。高質量的數據和嚴謹的算法模型是產出有價值結果的前提。

規范：

• 樣本質量要保證： 訓練模型所用的樣本數據必須具有代表性、無偏性，并經過嚴格的清洗和標注。
• 特征提取要謹慎： 特征工程是模型效果好壞的關鍵。提取的特征需要有明確的業務含義，并進行充分的驗證。
• 模型選擇要評估： 需要根據業務目標、數據特點和計算資源，選擇合適的模型，并從多個維度（如準確率、召回率、性能）進行綜合評估。
• 數據生產：
  • 節點新增需管控： 新增數據生產或處理的節點，必須經過評審，明確其必要性和對上下游的影響。
  • 開發生產莫混用： 嚴禁在生產環境進行數據開發和測試，必須建立隔離的開發測試環境。
  • 執行效率調最優： 對于數據處理任務，需要持續優化其執行效率，降低資源消耗。