In fact, still have to think about the business combination, give me a few ideas:
For example, you get a data write database, you first check based on the primary key, if it has the data, you do not inserted, update it right.
For example, you are writing Redis, then no problem, anyway, every time set, natural idempotency.
For example, you are not above two scenarios, that do little more complicated, you need to allow producers to send data each time, which add a globally unique id, order id like similar things, and then you here to the consumer after, according to this first id such as Redis in check, before the consumer before? If you do not consume too, you deal with, and then write the id Redis. If you consume too, then you do not deal with, and do not repeat the process to ensure that the same message can be.
Based on such a unique key database to ensure that data is not repeated a plurality of repeated insertion. Because of the unique key constraint, duplicate data insertion error will not result in stale data in the database.