To avoid scenarios where consumption results need to be stored in a relational database and consumer continue to consume when the database is down
http://kafka.apache.org
Check a lot of source code are recorded, save the next time to filter the source code.
- If the results of the consumption is being stored in a relational database, storing the offset in the database as well CA n allow committing both the results and offset with a single transaction. Thus either the transaction would succeed and the offset would be updated based on what was consumed or the result would not be stored and the offset won ' t is updated.
If you store the results in a relational database, storing offsets in the database can also allow you to submit results and offsets in a single transaction ... Therefore, either the transaction succeeds, the offset will be updated based on the consumed content, or the result will not be stored and the offset will not be updated.
Each record has its own offset, so to manage your own offsets, you just need to do the following:
- Configure
enable.auto.commit=false
- The use of the offset provided with the
ConsumerRecord save your position.
- On restart restore the position of the consumer using
seek(TopicPartition, long) .
Here to share a person's source code analysis:http://blog.csdn.net/chunlongyu/article/details/52663090>
Atomic operation (Atomic operations): An interruptible or a series of operations, like an atom, can no longer be split, is already the smallest unit, of course, there is no unit only operation.
Manually control the Kafkaconsumer offset with Java code