核酸檢測系統崩潰場景淺析
簡述
核酸採集人員用手機掃描用戶的核酸碼進行資訊錄入，掃描後遲遲是泛白的介面，這裡就簡單分析下。
一則消息：//cd.bendibao.com/live/202292/143899.shtm
整體流程
說明
實際場景中，細節比較多，這裡為了便於理解，只分析大體的流程，如有問題，歡迎指正。
對象
● 用戶：獲取核酸檢測碼。此時伺服器應該插入一條用戶數據，核酸檢測狀態為未檢測。
● 核酸採集人員：掃描用戶核算檢測碼。此時伺服器應該更新該狀態為檢測中，表示即將送檢。
● 核酸檢測和錄入結果的人員：將採集到的拭子進行檢測，檢測結果錄入到系統。更新檢測結果。
● 查詢核酸資訊的人員：用戶自身，核酸機構人員，相關管理人員等。查詢一個或多個用戶數據。
● 核酸系統伺服器：提供核酸檢測碼獲取，核酸採集，資訊查詢和存儲等。
寫數據階段
即是核酸從採集到檢測的過程。
讀數據階段
平時的健康碼展示，核酸系統數據查詢等。
分析與解決方式
根據上面的過程，出現泛白的介面，很大可能的原因是應用服務被大流量打掛，或者資料庫掛了。
這裡從整體架構上來說（不涉及應用服務外部），核心解決方式就是要保護服務：
● 服務保護：限流，艙壁，請求入MQ，批量pull隊列消息進行批量處理，以及服務集群，負載均衡等。
● 高效寫數據：例如可以用ClickHouse集群批量存儲或更新數據。
● 查詢快取與數據的弱一致性：Redis集群做快取查詢，數據容忍度在兩小時內，某城市人口2119.2萬，每5分鐘進行一次100萬數據的快取更新，或者更細的數據或時間粒度，或者更長容忍度時間，具體壓測情況具體分析。
