雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
金融行業的核心需求與策略
傳統 IT 架構挑戰
大家可能都知道，工行最早是基於 IBM 大型主機搭建的核心繫統，以及基於 Oracle 和 IBM WAS 搭建的 OLTP 系統，在分佈式體系大熱之前處於同業領先地位。
當然現在也是處於同業領先的，但是科技成本也相對較高，所謂的一份價錢一分貨就是這個道理。
但是隨着分佈式技術的成熟，傳統的 IT 架構面臨着四大挑戰：
①從處理能力層面來看，傳統應用（也叫巨石型應用）系統規模龐大，採用集中式架構設計，使用單一系統垂直擴展模式，擴展能力相對來說是有限的。
另一方面，大數據時代引發海量數據分析處理和存儲處理的問題，對擴展性、可靠性和吞吐量提出了較高要求。
②從運行風險層面來看，客戶對金融行業的系統有着更高的業務連續性保障要求，對不可用問題實際上是零容忍的，比如要求 7*24 小時業務不能中斷。
③從快速交付層面來看，傳統巨石型應用實際上與快速交付是相悖的，應用內部模塊、應用與應用之間耦合度高，使得軟件開發和產品服務交付週期長，無法滿足業務快速上線的需求，從而逐漸泯然衆人矣，淹沒在茫茫的金融行業洪流中。
大家可以看到不論是金融科技還是科技金融，一大堆的金融公司已經淹沒在前浪裏。
④從成本控制來看，大型主機運營費用昂貴，商業產品 License 費用高，買個機器和服務隨隨便便就幾千萬上億的支出，真的是太貴了，所以隨着業務系統做大做強，產品成本可能會成爲壓死駱駝的最後一根稻草。
爲此，我們可以首先得出三點需求：
應該優化應用架構、數據架構和技術架構。
應該建設靈活開放、高效協同、安全穩定的 IT 架構體系。
能夠強化對業務快速創新發展的科技支撐。
雙十一壓力
說到這裏，就不得不吐槽阿里的“雙十一”，將購買壓縮到一天，對顧客和金融系統來說造成雙重壓力，相較而言，京東的 618 就比較人性化，每天都可以剁手。
我們可以看下雙十一的峯值變化情況，從 2009 年開始，峯值只有 400 筆/秒，相較主機而言，有很大的差距，當然這也與他們當時的名氣小有關。
但是 2015 年開始，藉着雲化和分佈式的大旗，以及當時 BAT 的領頭羊地位，僅 4 年時間，就從 2015 年的 14 萬筆/秒迅速攀升至 2019 年的 54 萬 4 千筆/秒。
這就給金融行業的系統建設帶來了四個問題：
①高併發問題，我們可以看到，阿里爲了提升峯值，做了大量的緩存，鼓勵使用花唄，降低與外系統的交互，但是依然對金融行業產生額外的壓力。
②高可靠性要求，確保系統穩定可靠，客戶可以穩定支付成功，避免因不佳的客戶體現導致用戶流失。
③高成本壓力，大幅擴容的設備，以及隨之產生的運維成本，以及昂貴的商業 liscence，給金融行業帶來一定的成本負擔。
④同業競爭要求，大家都在做競品分析，和同行進行比較，所以別人 ok，你掛了，你面子上還掛的住麼，所以各機構在雙十一前進行大量的模擬測試，類似於高考前的黑暗日子。
金融行業分佈式的核心訴求及策略
爲此，金融行業分佈式的核心訴求及策略可以總結爲以下五點：
①應該具備企業級的業務支撐能力，支持高併發、可擴展和海量數據庫存儲及訪問；原則上應支持同城雙活，實現集中式向分佈式的轉型。工行的兩地三中心容災體系在國有大型銀行中屬於第一梯隊。
②應能大幅降低使用成本，可以基於通用的廉價的 X86 硬件基礎設施；降低商業產品依賴，擁抱開源產品，互聯網企業已經給我們做了一個很好的參考。
③應該提升數據庫的運維自動化和智能化能力，支持與自身系統進行適配性定製，工行即實現了行內系統適配定製。
④金融行業還應考慮到社會聲譽性要求，客戶對金融行業的期望很高，特別是對銀行等金融組織，所以要求也更加嚴格，原則上應該是 7*24 小時的不間斷服務。
像當年支付寶在 2015 年的支付癱瘓事件僅僅上了下熱搜，但是 2013 年工行因爲 IBM 主機 Bug 的問題卻上了新聞聯播，這就是所謂的愛之深責之切吧。
⑤要考慮到政治因素風險，雖然全球化要求技術無國界，但是從去年開始的貿易戰，以及美國的實體管制清單，我們可以看到技術是有國界的。
近期 HashiCorp 發佈公告，其企業版產品禁止中國使用已經引發了一種擔憂。說起 HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的產品 Consul，可以簡化分佈式環境中的服務註冊與發現流程，大家一定耳熟能詳。
最後中國人民銀行在 2019 年 8 月 23 日發佈了《金融科技（FinTech）發展規劃（2019-2021）》中提到“做好分佈式數據庫金融應用的長期規劃，加大研發與應用投入力度，妥善解決分佈式數據庫產品在數據一致性、實際場景驗證、遷移保障規範、新型運維體系等方面的問題，這也給金融行業指明瞭方向。
選型的發展歷程（方案選型歷程）
接下來，給大家介紹下如何選型以及工行的選型歷程。
工行分佈式轉型發展歷程
大家可以看下工行分佈式的發展歷程：
其大致可分爲 2 個關鍵階段，2016 年初-2017 年末爲基礎研究及試點階段，之後爲轉型實施及推廣階段。
大致有如下五個關鍵時點：
2016 年初工行進行分佈式體系研究，建立了基於 Dubbo 框架的分佈式生態服務。
2016 年底藉着人民銀行對於個人賬戶的管理要求，實行三類賬戶的場景，開始了基於分佈式的 OLTP 數據庫研究，並確定了基於開源 MySQL 的 OLTP 數據庫解決方案，因爲 MySQL 8.0 的不成熟，所以我們採用了 MySQL 5.7。
2017 年末，我們完成開源 MySQL 初步能力體系的建設，涵蓋了基礎研究、配套方法論、應用試點等等。
2018 年開始大規模的實施和推廣，我們逐步建立企業級的數據庫服務能力，包括引入了分佈式的中間件，在高可用、運維能力的提升，資源使用率的提升，MySQL 上雲及自主服務的建設等等，同時開啓了對 OLTP 的分佈式數據庫進行了研究。
2019 年 11 月我們實現了國產分佈式數據庫產品 GaussDB 試點上線。
方案選型調研
大家可以看下工行的選型過程，希望可以給大家帶來一定的參考：
工行的技術規劃是相當嚴謹的，所以當時我們從五個層次進行了考量：OLTP 分佈式數據庫、NewSQL 數據庫、支持分佈式架構、自主可控、開源抑或商業。
當時我們的第一個疑問是，到底是選 NoSQL、NewSQL 還是關係型數據庫。
當時 MongoDB、Redis、Cassandra、HBASE 等 NoSQL 數據庫開始在某些場景下大熱，但是可用場景不滿足我們的 OLTP 業務場景需求。
NewSQL 隨着 Google 的 Spanner 和 F1 開始進入大家的視野，但是國內可以考據的只有相關的 paper；國產的 TiDB 也是小荷初露尖尖角，但是畢竟還是幼兒期。
而 DB-Egines 發佈的《2016 年全球數據庫大盤點》，Oracle、MySQL 和 SQL Server 三大數據庫產品遙遙領先。
MySQL 當時在互聯網公司的名氣是越來越響，谷歌、淘寶、百度、騰訊、豆瓣、網易、臉書等都使用了 MySQL。
一方面 MySQL 提供了免費版，另一方面 Oracle 收購 Sun 後，可以很明顯的看到 MySQL 越來越規範，5.5、5.6、5.7 均可以看到很明顯的提升，5.7 號稱性能是 5.6 的 3 倍，5.6 號稱是 5.5 的 2 倍。
爲此，我們經過謹慎的驗證，選取了 MySQL 作爲分佈式數據庫的第一選型，畢竟業界有很多豐富的案例。
而且在互聯網企業裏面得到了很好的實踐，在業界資源案例和周邊產品都很豐富，能應對我行的高併發、彈性擴展需求。
同時其具有如下特點：
開源，基於 GPL（GNU 通用許可證）可以免費使用修改，當時很多公司都基於 MySQL 進行了深入定製，但是在與他們的交流過程中，發現版本歸併真的是一種夢魘。
高可用，具有優秀的架構設計及相當豐富的周邊產品，實現了企業級的高可用性和高擴展性。
免費，有效降低企業運行成本。
趨勢，產品成熟度、排名一直遙遙領先，佔行業應用的比重增大，產業鏈豐富，從業人員有規模效應。
然後我們選擇了 MySQL 5.7，其相較之前的版本有六個優點：
InnoDB 增強，在線修改 ibp，快速擴展 VARCHAR，UNDO 可回收，可關閉死鎖檢測。
複製增強，多源複製，基於 WRITESET 的並行複製，增強半同步，在線設置 repl filter。
優化器增強，幾乎重構優化器，EXPLAIN 增強，引入 Optimizer Hints。
安全性增強，新增密碼過期機制，支持賬號鎖定等。
功能增強，默認開啓 PFS，新增 sys schema 等。
其他增強，支持多個觸發器，新增 Query Rewrite，支持設置 SQL 執行最長時間。
方案技術棧
基於 MySQL 選型，還應考慮一系列的分佈式架構技術棧，包括分佈式服務、分佈式事務框架、分佈式批量框架、分佈式緩存、交易數據覈對及補償、分佈式消息、配置中心、開發及運維管理。
這裏提醒下大家，在選型上沒有最好的產品，只有最適合自己的產品：
①分佈式事務，業界實際上有多種解決方案，2PC（2 階段式事務提交）、3PC、TCC 和 SAGA 模型等等，我們這 4 種方案我行都有應用在使用，互爲補充，滿足不同業務場景對事務強一致性或最終一致性的要求。
②業務層面，在交易或者應用級層面進行數據覈對及補償，有些場景就是在傳統的 OLTP 的情況下，也會對應用上下游進行覈對和補償。
③分佈式消息，我們選取了 Kafka 作爲分佈式消息中間件。
④分佈式批量框架，在大規模的數據結點上進行批量操作的一個整體的解決方案。
⑤運維層面，我行建立了統一的運維管理平臺，納入所有數據庫節點，實現一鍵式的數據庫安裝、版本升級、基線參數配置等等。並且實現了多種高可用策略配置，包括自動、人工一鍵式切換。
爲什麼要有自動化和人工的兩種切換方式？這裏我要解釋下，一種新的事務上線之前，都會面臨一些挑戰和懷疑的，都是一個循序漸進的過程，特別是是在金融行業，自動真的好麼？萬一搞錯了怎麼辦？決策因素和模型是否設計正確？設計正確了是否編碼正確？
最難的是還要應對不同應用場景的需求，有的應用要求 RPO 優先，有的應用又要求 RTO 優先。
我們之前經過充分調研，預見到該種情況，所以我們提供了多種高可用策略的靈活配置，以便滿足不同應用的個性化要求。
我們的高可用整體上面基於 MySQL 的複製技術，通過半同步複製和多數派共識機制實現冗餘備份，基於 MySQL binlog 日誌實現自動數據補全，保障數據的一致性。
其他考量
除此以外，數據庫選型後，還應完善相關體系，規範設計、開發、測試和運維，實現管控的體系化和自動化，才能避免眼高手低，減少生產安全風險。
①在設計層面，在驗證功能、新特性和配置基線，數據備份恢復的基礎上，我們參考了愛可生、阿里等公司的規約，建立了 MySQL 設計指引，可以說，我們是站在巨人的肩膀上成長的。
加強元數據管理，提出元數據完備性、明確性、具象性和前瞻性的要求，建立應用的元數據標準，統一數據架構設計，架構師設計表結構時均基於元數據進行設計，提升數據架構質量。
此外，我們還開發了表結構設計工具，將其融合在 Excel 中，實現對元數據的自動應用，支持自動生成腳本，簡化架構師的貫標操作，將人員成熟度的要求降至最低，提升設計效能和質量。
②在開發層面，我們制訂了開發規範和 SQL 調優指引，同時基於 sonar 開發了 MySQL 檢查工具，支持對基於 myBatis 的 mapper 文件進行解析，提前發現 SQL 不規範的寫法。
同時將 sonarlint 插件納入開發人員必備插件，實現規則的雲化部署和本地聯動掃描分析，將規範融入開發過程中，提升開發人員的 SQL 編寫能力。
③在測試層面，我們自研壓力測試服務平臺，儘量減少性能瓶頸，提前發現 SQL 性能問題。
④在運維層面，感覺應該是最重要的一個層面，我們需要考慮自動化部署、監控告警、故障分析、自動巡檢以及 SRE 平臺，還有數據遷移、備份恢復、配置管理、版本升級、多租戶等等。
隨着節點的增加，運維實際上是一個很大的挑戰，幾千幾萬個節點，安裝、監控、報警、故障、人工處理等非常麻煩。
必須要實現自動化的安裝部署，進行批量安裝部署，同時批量串行還不行，時間太長了，要並行，並行太高了，網絡的流量又會受到很大的影響，所以很多場景都需要細細打磨，還要按照博弈論的思路建立納什均衡。
監控告警裏有事件等級，如何劃分各種等級，都需要靈活定製支持，建立基線告警，建立應急流程。
像華爲等公司都有基於設備的網絡拓撲圖，問題在哪個節點，可以快速分析和定位，所以說運維是一個很麻煩的事情，像故障分析，完善日誌記錄、採集和分析，建立故障分析規範。
自動巡檢，自動化的巡檢和評分報告，對實例狀態進行健康評分。在這個階段我們實現了同城 RPO=0，RTO=分鐘級目標，RPO 爲 0 的切換，問題可監控，實現了人工或自動的一鍵式切換。
最後我們不得不提到 SRE，很多人會聯想到運維工程師、系統工程師，其實不然，SRE 本質上仍然是軟件工程師。
SRE 最早在十多年前 Google 提出並應用，近幾年逐步在國內外 TOP 互聯網公司都開始廣泛應用。
其中 Google 締造了 SRE，並奠定了其權威的地位，而 Netflix 將 SRE 的實踐做到了極致，Netflix 僅有的個位數的 Core SRE 支持了 190 個國家、數億用戶、數萬微服務實例業務規模的運維。
像數據庫瓶頸，頂配數據庫空間仍然無法支撐業務半年發展；慢 SQL 數量爆發式增長，應用穩定性岌岌可危；人工運維風險極高；人工運維頻率高，研發幸福感下降這些大家都會遇到的問題也會逐漸地遇到。
他山之石，可以攻玉，我們完全可以把別人的挫折拿過來，避免自己走彎路。
MySQL 上雲
在逐步推進的過程中，完善選型體系建設後，爲了確保資源的有效利用，上雲實際上是一種必然的選擇。
從工行來看，經歷 1-2 年的發展，MySQL 數據庫節點就已經增至幾千套，機房和設備實際上已成爲一個瓶頸，再這麼玩兒下去機房容量不足了，所以必須提升資源的使用效率。
我行新建應用時，一般都會進行 1-3 年的一個超前規劃，業界也是同樣的做法，爲了穩定運行，避免出現資源瓶頸，基本上提交資源申請時，都選擇物理機。
但是大規模的申請物理機，而當前應用的交易量又無法達標，所以資源浪費非常嚴重。
根據評測，相較 Oracle，MySQL 數據庫實例單體性能容量較小，數據容量普遍小於 500G，同時超過一定容量的就要進行分庫，但是一臺物理機部署 1 個數據庫的方式並未發生變化，MySQL 的服務器資源密度較低。
同時運維效率低，在服務器、存儲、網絡等基礎設施環節的運維和交付仍然需要大量手工操作。
業界普遍的做法就是將 MySQL 上雲，實現雲化部署，藉助成熟的雲體系實現彈性伸縮和動態擴容。
工行有個優勢，IAAS 和 PAAS 雲處於同業領先地位，有着豐富的經驗積累，爲此結合行內對於雲戰略的規劃，MySQL 上雲是一種必然趨勢。
我們提供了 MySQL 的容器鏡像，提供了一鍵式的環境供給能力，通過上容器把 IAAS、PAAS 全部打通，支持快速搭建符合行內標準的基礎環境，提升環境支持能力。
工行基於 K8S、SDN、IAAS 建設持久性的狀態容器運行集羣，通過 SDN 實現容器網絡資源的自動化申請，通過底層擴展 K8S 實現容器的固定 IP，業界一般會採用 K8S Operator 實現容器的有狀態資源綁定，也包含了固定 IP 綁定。
保守估計，資源的使用效率至少提升了 4 到 5 倍。而且，我們的工作成果也相當喜人，截止當前工行的 MySQL 雲化部署節點已達 4300 多個。
工行實施效果
我們可以看下工行的轉型成效，首先看下數據：
①我們已實施 200 多個應用，高災備等級應用佔比高達 53%。
②6000 多個 MySQL 節點，高災備等級應用佔比高達 87.31%。
③實施的應用涉及很多核心業務，包括個人、對公、基金以及很多高災備等級應用，大多數爲主機下平臺遷移應用，少量應用是從 Oracle 遷移過來的，因爲工行將 PLSQL 存儲過程用到了極致，所以應用層也因此需要重構。
④我們通過 MySQL 支持的核心交易可以達到日均 7 億的交易量，經歷過雙十一和春節的多重考驗，峯值 TPS 至少可以達到 1.5 萬 TPS，同時支持橫向擴展，理論上通過擴展設備還可以無限地增加。
而如果通過主機想達成這個目標，那麼挑戰就會比較大，這就是建摩天大廈和建排屋的區別。
⑤通過良好的架構設計，我們可以滿足兩地三中心的架構要求，做到同城 RPO=0，RTO<60s。
⑥在自主能力方面，初步建立了企業級的基於 MySQL 的分佈式解決的自主能力：首先是分佈式框架+MySQL 的應用級分佈式解決方案，該方案承載了我行很多主機下平臺應用。
其次是基於分佈式中間件 DBLE（原型爲 MyCat，後經愛可生公司優化爲 DBLE，同時我行進行了深度優化和開發）建立數據訪問層，支持應對一些不是很複雜的場景，通過良好設計的分庫分表方案即可滿足需求。
⑦在成本方面，我行在主機上的成本投入明顯下降，近幾年我行的業務交易量每年以 20% 的速度增長，但是主機並沒有進行擴容，投入還逐年降低。
商業產品的數據庫的使用不僅實現零增長，還有所下降。從整個經費上來說，有非常大的降幅。
典型實施案例：信息輔助服務
介紹一下我行的典型案例：信息輔助系統。
從應用場景分析其需求，需要支持高併發、低延時，日均交易量爲 2 億，交易響應延時要求 10ms 以內，業務數據量大概 20T 左右，要求 7×24 小時的聯機服務，這就對應用的高可用提出了新的要求。
爲此，通過統一運維管理平臺，吸納所有節點，實現一鍵式的安裝、版本的升級、參數的配置。
①設計層面通過分佈式數據中間件 DBLE，進行分庫分表，規劃了 128個 分片，並對分片進行了合併部署，雖然相較於阿里的 1024 分片來說較少，但是我們使用了一致性 hash 算法，在資源使用上收益很大。
②DBLE 中間件在日間進行聯機服務，夜間進行批量變更，把主機上的一些數據同步下來，減少批量作業對聯機作業的影響。
③目前我們的高可用架構採用一主三從（1 主庫、1 本地半同步庫、2 同城半同步庫）架構，基於 MySQL 的半同步複製，實現園區級的 RPO=0。
通過 DBLE 中間件和管理平臺聯動完成實現了本地和同城的自動化切換，RPO=0，RTO<60S，完全滿足工行的業務要求。
最後補充說明下，爲了實現數據庫層面的高可用， DBLE 到數據庫的訪問同一配置爲實 IP。
④這裏我補充下我們高可用的發展史，其實我們對高可用方案進行了持續的優化。
同時學習和借鑑互聯網包括分佈式數據庫的一些方案，從 1 主 2 備，本地 1 備和同城 1 備，擴展成 1 主 3 備，通過半同步的機制，做到真正的在系統級去保證 RPO=0。
⑤在異地災備方面。最開始採用磁盤複製實現災備，一方面成本比較高，另一方面是冷備，無法熱切換，RTO 至少半個小時以上。所以我們後期用了 MySQL 異步複製。
在存儲方面採用集中存儲，一套集中存儲上面需要同時支撐上百個 MySQL 實例，IO 性能直接成爲瓶頸，爲了應對高併發場景時的 IO 瓶頸，我們直接引入 SSD 盤，基本上把 MySQL 的 IO 瓶頸給解決了。
轉型中遇到的各種心酸坑
最後我們說下我行轉型過程中遇到的心酸坑。
其實如果使用過 MySQL 5.7 的企業，肯定都遇到過相似的問題，比如超過 MySQL 的默認閒置時間導致的連接超時、dependent subquery 導致的語句效率差、字符集亂碼等等。
以及 MySQL 的自身 Bug，比如 Intel PAUSE 指令週期的迭代引發 MySQL 的性能瓶頸。
畢竟免費的午餐並不是那麼完美，總是會有或多或少的問題需要規避。
我這裏說下讓我痛心疾首的幾個心酸坑吧：
坑一：慢 SQL 數量爆發式增長，應用隱患逐步暴露，在阿里等互聯網公司和我行都是一個痛點，值得大家警醒和重視。
我行 OLTP 之前爲 Oracle 數據庫，藉助於 Oracle 良好的優化器，大家習慣於 5 張表左右的連接，但是遷移至 MySQL 後，習慣沒有及時轉換過來，一個慢 SQL 可能就導致服務不可用，降低用戶幸福指數。
爲此我們規劃了三個方面的改善措施：
①設計層面制定了規範，強調數據設計的合理性，組織 DBA 進行內部複覈，提前規避設計問題，比如 3NF、BCNF 的設計遵循、可控性冗餘處理（空間換時間或時間環空）等等，通過輔助工具的自動化手段，從源頭扼殺風險。
②開發層面我們基於 Sonar 開發了自動化檢查工具，支持分析 mapper 文件，既然開發人員沒空看規範，那我們工具輔助，增加質量門禁，強制將規範融合至開發過程中，進一步降低風險。
但是對新人可能不友好，以前看到一個新人的朋友圈的哭訴，被質量門禁卡的無法提交代碼，一直苦逼的加班整改。
③運維層面我們建立了 SRE 平臺，監測慢 SQL 語句，並分批次要求整改，將結果都擺在檯面上，真的不是我們不給力，而是應用開發不給力啊。
坑二：在 MySQL 5.7 中，表的 TRUNCATE 操作存在 Bug，對應編號 68184，會阻塞整個數據庫實例上的所有其他交易。
所以對大表進行 TRUNCATE 操作會影響整個 MySQL 數據庫的處理性能，即使是訪問不想關的表也會收到影響。
此時你就會收到一羣開發人員的請求，哎呀，數據庫夯住了，求救啊，實際上解決方案也很簡單，因爲 Drop 語句不受影響，所以映射爲 DROP+CREATE 的操作即可規避該 Bug，而 MySQL 8.0 也將其進行了同樣的映射。
所以我們將其固化到設計開發規範中，提醒相關人員進行注意，同時在工具中增加 TRUNCATE 關鍵字識別檢查，做到提前預防。
坑三：MySQL 的超時中斷，wait_timeout 參數，即 MySQL 客戶端的數據庫連接閒置最大時間值（秒），我行設置爲 1 小時。
如果長連接的空閒時間超過該參數設置時間，數據庫連接就會被 MySQL 主動斷開，而中間件的連接池的連接就處於“假活“狀態。
一般的建議方法就是增加心跳監測，使用 dbcp 設置 testWhileIdle、validationQuery 等參數，如果跟我行一樣使用 WAS 的，在 WAS 控制檯上設置時效超時的參數即可。
坑四：Replce Into 引發的自增列主鍵衝突 Bug，對應編號 73563，主庫在執行 replace 操作時，如果有數據衝突，會轉換爲一筆 delete+一筆 insert。
所以主庫無問題，但是 binglog 記錄的爲 update 操作，備庫重做 update 動作，更新主鍵，但由於 update 動作不會更新自增列值，導致更新後記錄值大於自增列值。
當此時發生主備切換時，備庫提升爲主庫，插入的自增列主鍵會取自增列的值，從而引發主鍵衝突。
解決方案也屬於應急方案，可以在發生問題時，通過 ALTER 語句將自增列增加。
另一種解決方案，可以在 replace into 之後開啓一個新的事務，插入一條無意義的記錄然後刪除掉，可以保證主備一致。
最後一種解決方案，是直接用雪花算法計算遞增序列號。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-06-18
本文作者：魏亞東
本文來自：“ 51CTO技術棧”，瞭解相關信息可以關注“ 51CTO技術棧”