在冷風中我凌亂了半小時，只因健康碼刷不出來

作為程式設計師的我就開始了內心的吐槽大會：這咋做的啊，不行呀，這就打不開了，肯定沒做優化，肯定沒用快取，肯定沒做壓力測試。。。。。

下面作為技術的視角來分析下這個場景的實現，以及可以怎麼去優化。這只是我yy哈，真實場景別人是怎麼實現的我也不清楚哈。

每個人都有乙個對應的健康碼，健康碼分為幾種顏色，也就對應了幾個狀態。本質上就是通過健康碼的顏色能否區分這個使用者是否去過高風險位址。

首先第乙個問題就是需要根據多維度的資料去計算出這個碼的顏色，比如根據使用者的行動軌跡去分析。至於實際上有哪些維度我也不知道，大概猜測行動軌跡肯定是其中一點。

大概的儲存也很簡單，就是userid code等字段，這個場景如果需要歷史資料可以單獨歸檔即可，只留最近一天的資料提供查詢即可。

最簡單的方案就是每次查詢實時去分析，這樣結果的真實性更高，不足點在於體驗不是很好，如果邏輯多的話肯定是無法在1s內給使用者響應的，所以在上面分析的時候我們設計了一張表進行儲存，肯定是提前計算好的，比如一天一次，半天一次之類的形式。

那我們基於已經有表的形式去做分析，這個業務場景就是很典型的讀多寫（凌晨寫）少的場景。如果不做任何改動，每次請求直接查詢表直接響應即可。在高併發場景下只能依賴資料庫的併發能力來扛住這些請求，很容易出現系統掛掉，響應慢的情況，也就是為什麼我在門口等了半小時的原因。

最好的方式就是加快取了，直接將碼的內容快取起來，前端根據內容生成健康碼即可。首先這種場景不能再查詢之後加快取，因為大部分人的監控碼可能也就早晨進公司的時候用一次，所以不適合查詢後再寫快取的操作。

需要在凌晨計算每個人健康碼的時候，同時將資料寫乙份到快取中，當然這個可以根據平時的訪問的資料進行分析，哪部分人每天都會用到，只預先快取這一部分人的即可。

快取後，基本上90%的請求都能命中快取了，因為每天上班的這部分人基本上不會有太大的變化。剩下的請求用資料庫去扛，如果還是扛不住可以加大快取儲存量，用空間換時間。或者資料庫多搞幾個從節點即可。

在架構設計中，隔離也是非常重要的一環。隔離的作用就是為了在出問題的時候將故障範圍降低到最小。

這個健康碼需要做什麼隔離？

可以獨立出乙個或多個從節點給對應的服務進行隔離，比如內部服務用庫1，外部服務用庫2，相互不影響。

庫隔離了不能解決根據問題，服務還得隔離。區分內部服務，外部服務。open api只連線外部服務，內部的閘道器只連線內部服務。

關於作者發起人。