Q1：爲什麼不考慮MGR架構？

A：17年MGR剛出來極不成熟，只是測試了下，Bug很多，不想當實驗品。

Q2：爲什麼會選擇DBLE呢？

A： 分佈式訪問層實際上很麻煩，並不是好的建設規劃，當時比較了網易DDB、淘寶TDDL、MySQL Proxy、 MySQL Router、DBLE，也就DBLE還可用，而且相較於MyCat優化了很多，所以最後也選擇DBLE去做簡單的分佈式訪問層，但是其配置比較繁瑣，對開發人員不友好，所以我們進行深度開發和改造，同時建立了統一配置中心（類似於diamond center）纔開始使用。

Q3：請問底層存儲是什麼樣的，分佈式主要體現在哪個環節？

A： 底層基於IAAS，採用SSD去做持久化。分佈式體現在2方面：

• 伴隨着分佈式服務，帶來的輕量級分佈式數據庫，可以彈性擴展；

• 數據的分片存儲以及分佈式數據訪問層。
  

Q4：使用double中間件，原始表還在嗎？

A： 沒有所謂的原始表，分片表名字都是一樣的。

Q5：分佈式事務在double上支持嗎？如何解決事務問題呢？

A：不支持，應該通過應用的擴展（基於我行的分佈式事務框架）去做分佈式事務處理，如果對事務有強一致性要求，可以通過XA（2pc或3pc）處理；除此以外，還可以將事務拆分爲主輔事務，輔事務通過分佈式消息隊列進行消費處理。

Q6：通過Hash分128片，每個片使用一主三從，是這樣的架構嗎？

A：印象中每4片集中部署的，可以根據實際方式調整分片的集中部署和拆分策略。目前最新是1主4備，3個半同步，1個異步（異地）。

Q7：128個分片，分片規則考慮了哪些因素呢？

A： 這個要根據業務規則去考量選擇具體的分片算法，脫離實際場景的分片實際上沒有意義的。比如有些表可以用身份證號、卡號、地區號等取模或一致性Hash，沒有統一的要求。

Q8：有沒有應用會一次訪問128個分片的？

A：沒有，規範不允許這麼訪問。

Q9： 工行在MySQL上容器這方面，遇到過哪些問題呢？性能能扛得住嗎？感覺會有很多坑。

A：主要就是容器IP的漂移、IO瓶頸，同時要注意分庫。

• IP漂移的問題，工行是通過擴展K8s實現，業界是通過operator去處理（推薦你用這個）；

• IO瓶頸是通過使用SSD。

Q10：MySQL容器化數據持久化是如何做的呢？

A：底層基於IAAS，採用SSD去做持久化。

Q11：請問IAAS上的網絡和存儲是使用的什麼方案？

A：FC-SAN和SSD。

Q12：請問10ms的低延遲是怎麼做到的呢？

A：高配設備、高配網絡、事務拆小。

Q13：對於TCC最終一致，銀行一般是要求強一致吧？哪些典型場景要用到TCC？

A：這個不見得，要看具體業務，本質上每個業務可以拆分成主輔交易，然後主交易成功即可，這點阿里和騰訊都是這麼玩的；對於併發要求不高和強一致性要求的，基於2PC實現，所以說，工行鍼對不同的場景有不同的方式。

Q14：MySQL都是用operator創建出來的嗎？

A：工行基於K8s、SDN、IAAS建設持久性的狀態容器運行集羣，通過SDN實現容器網絡資源的自動化申請，通過底層擴展K8s實現容器的固定IP，業界一般會採用K8s Operator實現容器的有狀態資源綁定，也包含了固定IP綁定。

Q15：半同步退化是怎麼解決的呀？

A：1）降低事務大小，原則要求1萬條提交一次，如果是大SQL，10萬條以內。2）每張表都有遞增主鍵。

Q16：半同步怎麼保證rpo-0呢？

A：1）降低事務大小，原則要求1萬條提交一次。2）數據庫有主備數據一致性的監測,同時應用層需要將數據放置到分佈式緩存中，當主備切換時，如果出現數據問題，進行事務補償。

Q17：數據庫跨節點關聯查詢對嗎？性能是怎麼暴漲的？

A：不建議跨節點查詢，原則上應指定到具體節點，如果跨界點查詢，說明設計不合理，或者可以通過Spark或Flink進行處理。

Q18：能否介紹一下分庫分表分區鍵選的情況呢？是按客戶還是按機構？全行同一策略，還是應用分別定義？

A：由應用分別定義，其實不同的應用，分區鍵不一樣的，比如信用卡，那就是用卡BIN；人員，那就是身份證的後幾位、區號等等，設計師。

Q19：三表以上的關聯複雜查詢要怎麼解決？

A：說明設計不合理，檢查下設計是否滿足3NF或BCNF，如果不可避免，建議通過時間換空間的方式進行冗餘存儲。

Q20：工行的四類分佈式事務處理使用場景可以再詳細地描述一下嗎？

A：涉及賬務處理且交易量併發度極低的用XA（2PC或3PC），交易併發量大的應用使用分佈式事務框架（TCC或SAGA）處理，但是TCC要求說實話有點高，所以現在應該SAGA會更有優勢，特別是阿里和華爲就是SAGA。

Q21：工行目前整個的數據模型管理是怎麼做的呢？

A：工行有自己的系統去管理相應的數據模型，同時該系統已與流水線整合，版本時會自動串聯之前生成的腳本。

Q22：請教一個問題，批處理和聯機交易都訪問同一MySQL，如何避免批處理異常時，把數據庫連接佔滿而導致的聯機交易失敗呢？

A：不允許，規範要求批量和聯機要分開處理，避免影響聯機交易。

Q23：多中心多活部署時，是否存在交易路徑上多個應用間的跨廣域網訪問問題？如果存在，是如何解決的呢？

A：不存在，否則網絡延時不可控。

Q24：工行的MySQL高可用架構是怎樣的？應用異地多活的話，數據庫同步的方式能不能講講？

A：分享時說了，1主4備，3個半同步，1個異步（異地），最早使用磁盤複製實現災備，一方面成本比較高，另一方面是冷備，無法熱切換，RTO至少半個小時以上。

Q25：請問雙活的應用，連的是同一個庫還是異地的庫？

A：MySQL羣組（1主4備）應配置唯一域名，實現應用配置與具體數據庫節點的配置的解耦，這樣DNS可以自動調整域名指向主庫的VIP，同時也會確保只有主庫的VIP處於綁定狀態。

Q26：請問從Oracle遷移到MySQL，要注意哪些坑？

A：簡單說下，多表關聯、分庫分表（必須）、設備運維（爲什麼要上雲）、存儲過程轉換爲JAVA處理的內存和事務控制、SQL調優等等，說多了都是淚。

Q27：從Oracle到MySQL，sequence是怎麼轉換的？

A：我行是自己實現的sequence處理，所以無所謂Oracle還是MySQL，同時你可以使用雪花算法自己生成，很多玩法。

Q28：MySQL的版本是不是太低了？

A： 16年底開始5.7是當時最好的版本了，8.0當時極其不成熟，問題很多。

Q29：老師對MarialDB有了解嗎？和MySQL有什麼差異呢？

A：MariaDB和MySQL的版本不一致，且不兼容問題很多，這個在網上能搜出來很多資料，看自己選擇。

Q30：工行Redis的應用情況是怎樣的呢？分佈式緩存用的Redis，大致是什麼架構呢？

A：工行的分佈式緩存用Redis實現的，最早是SSDB，後來被Redis給PK掉了。

Q31：老師您是開發還是DBA？您的成長路線是怎樣的？

A：我是技術管理和安全管理以及生產問題支持人員，最早是開發人員，然後考了Oracle和MySQL的OCP，可以解決從JAVA、數據庫、安全等各項問題，一定要開闊自己的視野，不要被工作所侷限，你會發現本質都是一樣的。

時代給予傳統金融業的危機感從未停止過，不論是互聯網的衝擊，還是疫情引發的新一輪挑戰。爲此 Gdevops全球敏捷運維峯會北京站 精選出近10家銀行的金融科技探索，分享其在中臺建設、數據庫遷移、運維轉型上的實戰經驗，助力Fintech戰略落地。部分主題：

相關文章