The rabbitmq cluster cases, the consumer how to guarantee the same message is only a consumer spendi-CodePudding

The rabbitmq cluster cases, the consumer how to guarantee the same message is only a consumer spending

CodePudding user response:

Queue the message should only be a client consumption, but in abnormal cases could message back in back in the queue, so the client still want to be idempotent

CodePudding user response:

Idempotent is saved with global id redis? Or to check the database, data return

CodePudding user response:

refer to the second floor whyyouhitme_ response:

idempotent is saved with global id redis? Or to check the database, data will return

Practice a lot of, can be determined according to the business, such as the unique key (the only exist in the field of business), such as the message body, a uuid to a table, do the idempotent uuid field to do the only key can also ensure that couldn't repeat the problem, using a database transaction to ensure the only, or add a distributed lock + specific query to ensure that only perform a
The second can be done from the business general, other associated with strong business

CodePudding user response:

Are all not understand talk nonsense,,,

CodePudding user response:

Wait for a great god give an accurate answer, rather than talking nonsense

CodePudding user response:

You are not a topic can only be consumption

CodePudding user response:

reference 4 floor AnXiaoRan however response:

is all not understand talk nonsense,,,

Talk nonsense? To ask where to talk nonsense

CodePudding user response:

refer to 7th floor maradona1984 response:

Quote: refer to 4th floor AnXiaoRan however response:

Are all not understand talk nonsense,,,

Talk nonsense? To ask where is ridiculous

Do you think you can this idea to use in a production environment, with the message is to reduce the pressure of a database, to a table, do the idempotent uuid field to do the only key can also ensure that couldn't repeat the problem, the use of a database transaction to ensure only,

This form the amount of data you considered, efficiency

CodePudding user response:

AnXiaoRan however, 9/f, reference response:

Quote: refer to 7th floor maradona1984 response:

Quote: refer to 4th floor AnXiaoRan however response:

Are all not understand talk nonsense,,,

Talk nonsense? To ask where is ridiculous

Do you think you can this idea to use in a production environment, with the message is to reduce the pressure of a database, to a table, do the idempotent uuid field to do the only key can also ensure that couldn't repeat the problem, the use of a database transaction to ensure only,

This form the amount of data you considered, efficiency

This form can be regular cleaning, do not feel how data volume, can make a separate components, almost no additional complexity, table into the business, you can, of course, but with the business code coupling, table also adds an additional fields, and the only constraint, the pressure of the database is not more than a separate into a small table, separate table can clean up after all, can truncate, you can't, that a big table, index maintenance is also a big cost.
Different choice only, how is talk nonsense? And reduce the pressure of the database is mq? Peak in performance is to cut and architecture is decoupling, mq will not reduce the number of database operations, the cache can greatly reduce the pressure of the database, and of course it's not good for the database completely is false, but the effect is not so obvious

CodePudding user response:

Repeated consumption problem I understand is the ack to manually regardless of how many consumers are listening to the queue, only get there will be a consumer, the principle of first in first out! I don't know my answer right or wrong please correct me bosses,

CodePudding user response:

refer to 12 floor a597192251 reply:

repeated consumption problem I understand is the ack to manually regardless of how many consumers are listening to the queue, only get there will be a consumer, the principle of first in first out! I don't know my answer right or wrong please correct me bosses,

What you said is a very ideal environment, but you have to think about, system during the consumption data is down or restart the situation, consumption, whether to add a transaction of this is to look at the business transaction is against the database, then when you are in the received data ACK or acks before the end of the consumer? If the former, how to ensure that an ACK after all data are indeed have consumption? Consume half of the data. What should I do? If the latter, spending time long will lead to an ACK timeout? Timeout will back into the queue, if avoid the other side to repeat the data (which is idempotent prevent consumption)?