Ali distributed open Messaging Service (ONS) Principles and Practice - finishing notes

1, MQ Scene
    1) Order asynchronous decoupling
    2) to solve the problem of distributed transactions
    3) applies to chat platform
    4) large-scale machines Cache synchronization
    5) MySQL BinLog subscription data distribution
2, ONS scenarios
    asynchronously, decoupling, eventually consistent parallel
3, the design assumes
    1) each PC machine could not service the machine down
    2) any cluster may lack the processing power
    3) worst-case scenario will happen
    4) within the network environment requires low latency to provide you the best user experience
4, the key design
    1) distributed cluster
        a, theoretically infinite processing capacity
        B, high availability cluster level
    2) strong security data
        a, single redundant disk level
        B, a single set of multi-level redundancy queue
        C, a plurality of sets message queue redundancy
    3) accumulation of massive amounts of data
        a, push mode: simple logic subscriber
        B, pull mode: Follow certain fast
        C, combined push and pull: queue notify the consumer, consumers to pull (twice interaction)
        D, using Ali polling and connection length: polling to pull, the pull there, no connection is maintained long to wait until a message
    4) millisecond delay delivery
5, key concepts
    1) Topic: a first stage message type, the main title
    2) Tug: message type second stage, subtitle
    3) sends a group: Manufacturer where the cluster
    4) subscribed: where consumers cluster
    5) RocketMQ not one to one, not many, one random
    6) network three states: succeeded, failed, did not respond
6, scrambled message problems: the message server does not process, required to fix exactly
    1) sending the message ID
    2) there is only one set of messages to subscriber processing (Sharding)
    number (i.e., "lock granularity") 3) a group of messages as small as possible
7, message duplication
    1) was repeated Cause: network unreachable
    2) idempotent: No matter how many times an operation is repeated, the results are the same (no solution, high performance)
    3) non-idempotent, to weight
        a, ensure unique tag ID of each message;
        B, to ensure the success of the message processing table weight log simultaneous
    4) go heavy price: the extra tps and qps
8, distributed transaction optimization
    1) transaction 1 -> MQ Server -> transaction 2
    2) at the same time successfully, but failed:
        a, message;
        b, performing transaction. 1;
        C, an acknowledgment message sent Feeding;
        D, delivery message to the consumer
    3) processing timeout issue (repeat): 2 add message confirming the transaction table (de-duplication table)
    4) failure message (transaction 2 fails): After recording the manual handling (small probability events)
----------- ----------
author: monkey brother 1024
source: CSDN
original: https: //blog.csdn.net/qq_21033663/article/details/73379103
copyright: This article is a blogger original article, reproduced, please attach Bowen on the link!