您的當前位置： > 關注 > > 正文

天天即時：分布式集群化設計——MySQLServer

來源：CSDN 時間：2023-03-22 10:48:31

(資料圖片)

1、MQ場景 1）訂單異步解耦 2）解決分布式事務問題 3）應用于聊天平臺 4）大規模機器的Cache同步 5）MySQL BinLog訂閱數據分發2、ONS應用場景異步、解耦、最終一致、并行3、設計假定 1）每臺PC機器都可能down機不可服務 2）任意集群都可能處理能力不足 3）最壞情況一定會發生 4）內網環境需要低延遲來提供你最佳用戶體驗4、關鍵設計 1）分布式集群化 a、理論上無限處理能力 b、集群級別高可用 2）強數據安全 a、單機磁盤級別冗余 b、單組多隊列級別冗余 c、多組消息隊列冗余 3）海量數據堆積 a、推模式：訂閱者邏輯簡單 b、拉模式：關注吞吐量，快 c、推拉結合：隊列通知消費者，消費者去拉取（兩次交互） d、阿里采用長連接和輪詢：輪詢去拉，有則拉取，無則保持長連接等待，直到有消息 4）毫秒級投遞延遲5、關鍵概念 1）Topic：第一級消息類型，主標題 2）Tug：第二級消息類型，分標題 3）發送組：生產者所在集群 4）訂閱組：消費者所在集群 5）RocketMQ不是一對一，也不是一對多，是隨機一對一 6）網絡三種狀態：成功、失敗、沒響應6、消息亂序問題：Message服務器不處理，恰好不需要解決 1）發送時對消息進行編號 2）一組消息只有唯一一個訂閱者處理（sharding） 3）一組消息的數量（即“鎖的顆粒度”）越小越好7、消息重復問題 1）重復原因：網絡不可達 2）冪等：某個操作無論重復多少次，結果都一樣（不需要解決，性能極高） 3）非冪等，去重 a、保證有個唯一ID標記每一條消息； b、保證消息處理成功與去重表日志同時出現 4）去重代價：額外的tps和qps8、事務的分布式優化 1）事務1-->MQ Server-->事務2 2）同時成功，同時失敗： a、發消息； b、執行事務1； c、確認消息發送； d、投遞消息到消費者 3）處理超時問題（重復）：事務2增加消息確認表（去重表） 4）消息失敗（事務2失敗）：記錄后人工處理小概率事件

責任編輯：

標簽：

上一篇：觀熱點：壓阻式壓力傳感器/壓力變送器的類型有哪些？壓力傳感器/壓力變送器的類型
下一篇：最后一頁