/**
* Declaring forwarders and types available forwarders type direct Topic Headers fanout
* Direct exchange– handles routing keys. A queue needs to be bound to the switch, requiring the message to exactly match a specific routing key.
* Fanout exchange– does not handle routing keys. You simply have to bind the queue to the switch. A message sent to the switch is forwarded to all queues that are bound to the switch.
* Much like a subnet broadcast, each host in the network receives a copy of the message. Fanout switch Forwarding message is the fastest.
* Topic exchange– to match the routing key with a pattern. At this point the queue needs to be bound to a pattern. The symbol "#" matches one or more words, and the symbol "*" matches no more than a few words.
* therefore "audit.#" can be matched to "audit.irs.corporate", but "audit.*" will only match to "Audit.irs".
*/
Channel.exchangedeclare (Ex_log, "fanout");
/**
* Specify queue
* Queue: Queues Name
* Durable: Whether persistent, the queue declaration is stored in memory by default, if the RABBITMQ restart is lost, if you want to reboot after the existence of the queue will persist,
* Saved to the Mnesia database in Erlang, which will be read when RABBITMQ is restarted
* Exclusive: Whether exclusive, there are two functions,
* 1: Connection.close () the queue is automatically deleted when the connection is closed;
* 2: Whether the queue is private,
* If it is not exclusive, you can use two consumers to access the same queue without any problems,
* If it is exclusive, the current queue is locked and other channel channels are inaccessible.
* If mandatory access reports an exception, it is generally equal to true if a queue can have only one consumer to consume the scene
* Autodelete: Whether automatic deletion, when the last consumer disconnected after the queue is automatically deleted,
* You can view the number of consumers in a queue by RABBITMQ Management, and the queue will be automatically deleted when consumers = 0 o'clock
* Arguments: When will the messages in the queue be automatically deleted?
*/
Channel.queuedeclare (Queue_name,false,false,false,null);
Send
/**
* Exchange: Forwarders
* Routingkey: Specify Routingkey
* Props: Message for persistence--messageproperties.persistent_text_plain
* Body:msg bytes
*/
Channel.basicpublish (Ex_log, Queue_name, Messageproperties.persistent_text_plain, Msg.getBytes ());
Receive
/**
* Response mechanism
* ack= True:round-robin Forwarding consumer is killed, message will be lost
* Ack=false: Message answer, in order to ensure that the message is never lost, RABBITMQ supports message reply (msg acknowledgments).
* The consumer sends a reply to RABBITMQ, tells it that the information has been received and processed, and then RABBITMQ can delete the information freely.
* If the consumer is killed without sending a response, RABBITMQ will assume that the information has not been fully processed and will be retransmitted to other consumers.
* In this way, you can verify that the information is not lost, even if the consumer is occasionally killed.
* It is permissible for consumers to spend a particularly long time.
*/
Boolean ack = FALSE; Open answer mechanism
Channel.basicconsume (queue_name, Ack,consumer);
/**
* Fair forwarding, set the maximum number of service forwarding messages, only when the consumer is free to send the next message, at the same time each send a message to a worker.
* FIX: When a producer with multiple consumers, avoid RABBITMQ server may always send multiple messages to one worker while the other may hardly do anything.
*/
Integer prefetchcount = 1;
Channel.basicqos (Prefetchcount);
Channel.basicconsume (queue_name, Ack,consumer);
/**
* Send Answer
*/
Channel.basicack (Delivery.getenvelope (). Getdeliverytag (), false);
RabbitMQ Partial API parsing