A summary of the key problems of RABBITMQ

1. RABBITMQ

1.1 RABBITMQ Data Rate problem

In the case of read-side writing: The rate is only positively correlated with network bandwidth, network usage is up to nearly 100%, and data usage is high (above 90%).

In gigabit network, to 500KB a data for example, reading and writing rate can reach 200/s, about 100mb/s.

In the case of write-only not read: The write rate bottleneck is the hard drive write speed.

1.2 RABBITMQ data Store path change to D disk method

In Windows environment, set environment variables before installation: Rabbitmq_base=d:\rabbitmq_data

1.3 RABBITMQ Disk Full restart data loss problem

Performance: The disk is full after the send, read the program can not connect the service.

Workaround: Set queue, Exchange to durable without data loss problems.

Through a. Close the service; b. Delete the placeholder files, erl_crash.dump;c. Restart the service after the three-step operation, the disk will clean out about 10M of space, then read the data program will work correctly.

A properly designed schema should ensure that the RABBITMQ does not occur when the disk is full of crashes.

1.4 RABBITMQ Cluster

In the case of full network bandwidth, the solution to the problem of insufficient throughput through clustering requires more than one effect.

Assuming that the peripheral throughput is D/s, the probability of the peripheral sending to the RabbitMQ1 is R1, the probability of sending to the RabbitMQ2 is RabbitMQ2, and the probability of forwarding to R3 is R2,RABBITMQ1. The probability that the RabbitMQ2 needs to be forwarded to the RABBITMQ1 is R3. Then RabbitMQ1 into the throughput rate is: (R1*d + r4*r2*d) strip/s≈3d/4/s,rabbitmq2 into the throughput rate is: (R2*d + r3*r1*d) strip/S≈3D/4 strip/s This is certainly lower than the throughput D/s requirements for using only one RABBITMQ.

N Taiwan RABBITMQ Cluster, each average throughput rate is: (2n-1) d/(n*n)/s;n=3, the average throughput is 5D/9, the average throughput is/s;n=4 bar/s.