成都核酸檢測結果查不到「關于成都核酸檢測系統崩潰我想說點啥」 _淘寶為什么打11峰值

一個如此簡單的場景，會接二連三的崩潰，東軟的架構師可以下崗了。就這個系統如果硬件資源到位，一個APP開發工程師一個后端開發工程師3天就開發出來了，而且比現在穩定，為什么這么說看看我下面的分析，你就知道了。
核酸檢測涉及幾個系統：1、居民使用的健康碼系統（天府健康碼，里面存放居民個人信息及核酸檢測結果）2、核酸檢測登記系統（就是大白使用這次崩潰的系統）3、醫院核酸檢測系統（出核酸檢測結果的）。
核酸檢測原理就是居民打開健康碼讓大白通過核酸檢測登記系統掃碼進行核酸檢測批次和居民健康碼進行綁定登記，因為大家否是混檢，檢測結果是按批次進行出結果的，大白手上的APP每10個人就是一個批次，這個批次號和核酸檢測采樣管上貼的批次是一致的，所以這個APP就是負責把進行核酸檢測的居民健康碼和核酸檢測批次號進行綁定并上報記錄到后臺，待本批次核酸檢測結果出來就默認是這個批次綁定的10位居民核酸結果了，所以大家被捅喉嚨的棉簽都放在那一個采樣管里面。
那核酸檢測登記系統需要登記哪些信息呢？在我看來，只需要登記：核酸檢測批次號、居民健康碼唯一編號、檢測時間、檢測位置、檢測人編號幾個信息就足夠了。核酸檢測批次號由核酸檢測系統自動生成，居民健康碼編號由健康碼系統生成，這個編號可以查出居民的所有身份信息，檢測位置是大白自己登基的臨時核酸檢測點位置，檢測人就是大白自己登記的醫護人員信息的編號。
這樣看是不是很簡單，不需要之前網傳的幾萬個表字段，只需要5個字段就夠了。那系統為啥會崩呢？本人猜測和東軟系統設計不合理有關系。假如四川全省同時有兩萬個大白使用核酸檢測APP上報登記，那這個系統的并發就是每秒兩萬，假如單臺服務器查詢和寫入能支持1000/s, 那大概需要20臺服務器，這個對于政府不是啥問題，但是這20臺服務器的并發寫入直接寫入一個單機數據庫，除了類似阿里云的云分布式數據庫沒有哪個數據庫能抗的住，但本人猜測東軟用的肯定是mysql和oracle里面的一種，那是不是就說這兩種數據庫不行，其實不是數據庫不行是用的人不行，用的不對，單臺數據庫的最大連接數是有限的，正常1000左右，所以如果是向單數據庫直接寫，肯定不行。我看有網友說用CK，是可以的，但也要控制寫入頻次，否則會報錯，而且就那5個字段在我看來用mysql就足夠了，所以那些說mysql不行的人，應該不是IT行業的。
接下來我會說下我的看法，歡迎大家評論區留言。什么是高并發，就是在同一時刻訪問到網站服務器的流量超過一個很高的值導致服務器性能下降或者癱瘓，不同網站由于設計的不同扛高并發能力差異也很大，比如京東淘寶雙十一峰值流量估計都要上每秒幾十萬、12306春節搶票每秒能上百萬，那怎么設計系統才能讓系統扛高并發能力變強呢？可以從硬件配置、高并發系統架構、系統保護、系統監控、系統運維幾個方面來提升。
12306網站在15年之前基本遇到長假必崩，后來經過幾次優化現在基本不崩了，他們做了以下優化，包括不同站點分時段放票（降低同一時段搶票的人數）；余票查詢上阿里云；全緩存數據庫（以前登錄都崩，沒做緩存直接查數據庫一看就是外包做的）；引入下單排隊機制（其實就和大家在購票窗口排隊一個原理）；下單扣減庫存超時未付款釋放庫存；兩地雙中心雙活共同提高服務（其實應該兩地三中心實現異地容災）等等。