通過優銳課核心java學習筆記中，我們可以看到，碼了很多專業的相關知識， 分享給大家參考學習。
之前，我們討論了MySQL分片的應用程序和設計挑戰以及可能導致並影響你的業務靈活性的一些相應業務挑戰。 但是，MySQL如何應對DevOps挑戰呢？
作爲參考，以下是有關MySQL分片的簡要說明：MySQL分片是將MySQL應用程序工作負載劃分到多個不同的MySQL數據庫服務器上的策略，從而允許查詢和數據CRUD操作散開。 它圍繞MySQL的單一寫主體系結構工作，儘管具有權衡取捨，但仍具有擴展寫和讀的能力。 這是一個很大的DevOps項目。
而且，由於我們已經瞭解了MySQL分片對業務規則支持的挑戰，因此我們來看看“屋後”：MySQL分片的DevOps挑戰。
1.數據維護
一旦選擇了分片密鑰，就需要在MySQL服務器陣列中物理分佈數據。 這些服務器中的每一個都將需要其自己的數據庫才能擁有自己的一組數據分區。 初始數據分發可以是手動的； 那更多的是“一次性設置”。但是，隨着工作量的增長會發生什麼？ 理想情況下，每個碎片都平均增長，但有時生活會發生...
碎片增長和熱點
MySQL分片陣列存在兩個主要的正在進行的數據維護能力挑戰：
- 碎片增長
- 碎片熱點
分片增長意味着你的一個或多個分片已準備好超過基礎服務器的存儲容量。熱點意味着你的一臺或多臺分片服務器即使沒有達到存儲容量，也正在爭用CPU或網絡流量。分片增長和熱點都會導致服務器性能下降，並且都具有類似的解決方案：拆分本地分片，然後將數據（例如一半）移至其他MySQL服務器。這爲DevOps帶來了巨大的工作。
從業務角度來看，碎片增長是積極的；增長是好的。但是，這種增長代表着一些DevOps挑戰，因爲這意味着進一步的數據分發是必要的。簡而言之，每個MySQL服務器都需要足夠的“備用空間”來增長，否則事務將開始變慢，甚至不會失敗。最佳做法是至少有40％的可用存儲空間，平均CPU利用率在60％到70％之間。一旦存儲量超過90％，將對MySQL性能產生影響。服務器要麼需要對其磁盤和/或SAN進行升級，要麼需要拆分本地分片，將新的“半”分片移至其他MySQL服務器。理想情況下，將分片移動到新服務器以最大程度地增加增長潛力，但有時CAPEX預算要求合併。在“加倍”分片的情況下，確保新的拆分分片不會在其新的共享服務器上創建競爭非常重要，否則你將不得不再次移動它。這很容易造成一些重大的MySQL分片DevOps挑戰。
分片熱點意味着訪問/數據偏斜。充其量只是暫時的，並且隨着時間的流逝會自行解決。最糟糕的是，這意味着MySQL分片密鑰（策略）有問題，可能需要重新研究。這將需要重新分片整個數據工作量，這意味着大量的停機時間或大量的冗餘硬件支出。分片增長耗盡了本地存儲，而分片熱點會引起網絡，CPU和/或潛在的存儲爭用。熱點不是存儲容量的問題；可能還有很多磁盤空間。但是，數據庫使用模式取決於本地服務器上駐留的數據，因此處理此類熱點的最直接方法是進一步分區本地分片，這意味着MySQL分片會帶來更多的DevOps挑戰
管理分片拆分可能很棘手。對於DevOps，最簡單的解決方案是使碎片脫機，拆分，將新的一半碎片移至新服務器，更新shard：server映射LUT，然後將脫機的碎片重新聯機。這將導致應用程序（正常）由於脫機分片上的所有事務而失敗。從業務角度來看，這意味着使部分客戶，功能部件或功能脫機。例如，某些大型遊戲公司具有定期維護，並且正在修改的分片上的所有客戶（數千）都離線了幾個小時。
但是對於需要高可用性的高容量/高價值MySQL應用程序，由於每個分片都是冗餘的（例如，每個分片都有用於HA的從屬），因此可以在該從屬上進行分片更改，而不會影響生產。 分割並移動分片後，就需要複製以使從站追隨主站的位置。 當準備就緒時，提升從屬，降級爲主並進行轉換。 這樣可以以最少的停機時間來換取更多的DevOps努力。
一旦分片被分割，並且一半的工作負載與新的分片一起移動到另一個（理想情況下是新的）節點，現在包含一半數據的原始本地服務器的工作負載將減少50％。如果不是，則可能需要重複分片過程。如果例如由於預算限制而將新創建的分片改爲移動（共享）另一臺就地服務器，則這尤其可能。在這種情況下，需要仔細檢查該服務器的新使用模式，否則可能會發生“搶劫Peter付錢給Paul”的情況。
分片合併可能會定期有用。如果業務變化，會發生什麼？或者用戶訪問模式出現高峯/季節性變化，例如，黑色星期五，黃金時段或單身一天？在一個季節性高峯期，可處理3到5倍以上訪問者的MySQL分片陣列在今年餘下時間嚴重超出了容量。但事實證明，由於分片合併所需的工作量與分片拆分所需的工作量相似，因此許多企業級MySQL分片部署都無需擔心。在這種情況下，所有後續的分片拆分都將移至共享當前使用的MySQL服務器，而不是部署新的。
2. 基礎設施維護
“數據維護”的另一面是基礎架構。 無論是碎片增長，熱點，分裂還是shard：server映射，上述每一項都需要DevOps來部署，升級，維護，備份和淘汰/替換服務器。 這些任務中的某些任務可以在雲上簡化，尤其是部署速度，但仍然需要管理，並且仍然對分片的MySQL應用程序構成挑戰，並給MySQL分片的DevOps挑戰帶來很多挑戰。
具體來說，分片MySQL應用程序面臨三個主要的基礎架構挑戰：
- 服務器物流。
- 服務器備份。
- 高可用性（HA）。
MySQL分片陣列的服務器物流分爲三大類：MySQL服務器本身（對於HA可能是冗餘的），shard：server映射以及整個陣列所需的任何複製策略，例如，以避免跨節點事務。 MySQL服務器非常簡單。 以最佳性價比購買（或租用）實例大小。 但是，隨着分片陣列的增大，節點開始處於生命的各個階段。 某種類型的定期背景心跳和/或冒煙測試對於確定哪些服務器性能下降以及將被替換的服務器很有用。 由於HA，所有這些都翻了一番。 在MySQL中，HA通常是通過一個從屬實例完成的，該實例是主實例/主實例的完整副本。 因此，這是需要購買/租用（CAPEX）和進行管理（OPEX）的MySQL服務器數量的兩倍。 總之，DevOps需要做更多的工作。
碎片：服務器映射對於MySQL碎片數組至關重要。應用程序必須始終知道每個事務哪個MySQL服務器包含數據。通常，這種映射是通過Redis或Memcache完成的，即快速的內存中鍵/值存儲，它們在PK，分片鍵，數據庫名稱，服務器ID，服務器IP等之間提供LUT（查找表）交集。允許應用程序進行動態查找，而對運行中交易的影響最小。這還需要部署和維護其他LUT /映射服務器。它們確實應該是多餘的；沒有這些數據，分片的數組就會癱瘓。
跨節點複製對於本地分片上所需的任何數據都是必需的。這允許本地分片上的事務避免跨節點事務，並且需要對應用程序進行重大修改以提供參照完整性和ACID保證。如果需要跨節點複製，這將爲DevOps增加全新的複雜性，確保在每個節點上創建從屬進程，在必需的主服務器上設置binlog，並且監視/確保複製滯後在合理範圍之內。
備份MySQL分片陣列的挑戰
由於陣列中沒有一個RDBMS負責所有MySQL服務器，因此沒有編程的方法來獲得一致的備份。可以使用MVCC啓動備份，以確保每臺服務器的事務狀態一致，但是即使使用NTP（甚至本地原子時鐘），本地服務器時間也不會與其他服務器完全匹配。如果每個服務器都完全獨立運行，則問題不大。如果業務規則嚴格避免跨節點交易，那麼“足夠接近”就足夠了。但是，在與許多公司的許多DevOps負責人交談之後，他們都對備份策略感到不滿意。選項包括使用塊存儲卷，並在單個時間點同時進行塊複製。一些雲提供商在其託管產品中也具有快照備份選項，但是跨陣列中每個節點的同步快照仍需要同步。同樣，從備份中恢復節點可能很棘手，需要使用複製來前滾以匹配其他節點的事務狀態。最後，有時再次同步所有MySQL分片可能需要跨分片滾動重啓。談論MySQL分片DevOps的挑戰！
所有這些複雜性導致某些部署更加關注HA，而不是確保一致的備份。
3. 高可用性（HA）
最後，讓我們討論與高可用性（HA）相關的MySQL分片挑戰。通常，需要分片提供規模程度的MySQL應用程序會提供需要高可用性的高容量/高價值交易。
這意味着DevOps需要確保每個MySQL服務器都是完全冗餘的，即每個“碎片”實際上將至少由兩臺服務器組成，無論是主/從配置還是主/主配置。主/從是最容易設置的，但不能保證事務的一致性。主機/主機，特別是基於證書複製的主機/主機，可確保輔助主機在主主機COMMIT之前擁有交易信息的副本。這樣可以保證，如果主服務器在COMMIT之後但在輔助服務器COMMIT之前發生中斷，則輔助服務器仍可以完成該事務並兌現主服務器發送迴應用程序的ACK。不出所料，與常規的主/從異步複製相比，這種級別的事務一致的HA涉及的設置更多。用高昂的HA交易OPEX。簡而言之，創建了許多其他的MySQL分片DevOps挑戰。
爲什麼自動快照不足以實現HA
AWS RDS每隔五分鐘自動提供一次快照備份。乍一看，這似乎比爲HA部署冗餘服務器要簡單得多，更不用說設置和維護所需的所有複製（例如，與RDS中已經提供的只讀副本不同的不同RDS主服務器之間）。
但是，五分鐘的延遲意味着五分鐘的事務丟失。這與丟失“進行中”交易不同；如果服務器出現故障，MySQL會（如果不是很常見）丟失“正在進行中”的交易。由於這些交易未完成，因此不會向數據更新發送COMMIT，也不會嚮應用程序發送ACK。但是，例如，如果交易完成了，就接了訂單，並且客戶收到了訂單確認號，那麼客戶有合理的期望，如果隨後發生服務器故障，交易將繼續進行。如果客戶的付款方式有所減少，則他們可以根據法律管轄權尋求法律追索權。但是，如果沒有HA，即使信用卡公司這樣做，該電子商務提供商也將沒有該交易的記錄。
這是一種笨拙的做法，它會造成不良的新聞報道，受污的品牌烙印等，並退回到DevOps及其MySQL分片上。
還有一個難題，如果你沒有在雲部署中租用預留實例，這意味着五分鐘的備份延遲將大大延長，同時新實例將聯機。
摘要
儘管分片MySQL當然是解決MySQL應用程序可伸縮性需求的一種公認策略，但必須睜大眼睛來對待。 需要創建和審查體系結構和物流計劃，以幫助避免可能對OPEX和CAPEX預算造成的MySQL分片DevOps挑戰。 分片MySQL總是很困難，它的折衷方案可能很多，尤其是在你的DevOps團隊維護分片陣列繼續進行時的連鎖反應。 提前做出決定是很容易的，DevOps最終將爲此付出努力和資源，而MySQL應用程序可能因此失去信譽。
> 喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術乾貨、職場趣事、海量面試資料等等
> 如果你對java技術很感興趣也可以＋ qq羣：907135806 交流學習，共同學習進步。
> 不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代
文章寫道這裏，歡迎完善交流。最後奉上近期整理出來的一套完整的java架構思維導圖，分享給大家對照知識點參考學習。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java乾貨加vx:ddmsiqi 領取啦
