阿里分布式開放消息服務(ONS)原理與實踐——筆記整理

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和qps
8、事務的分布式優化
    1）事務1-->MQ Server-->事務2
    2）同時成功，同時失敗：
        a、發消息；
        b、執行事務1；
        c、確認消息發送；
        d、投遞消息到消費者
    3）處理超時問題（重復）：事務2增加消息確認表（去重表）
    4）消息失敗（事務2失敗）：記錄后人工處理（小概率事件）
---------------------
作者：猴子哥哥1024
來源：CSDN
原文：https://blog.csdn.net/qq_21033663/article/details/73379103
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！