1、精确一次消费
1.1 定义
精确一次消费（Exact once）：指消息一定会被处理且只会被处理一次；不多不少就一次处理。
如果达不到精确一次消费，可能会达到另外两种情况：
至少一次消费（at least once）:主要是保证数据不会丢失，但有可能存在数据重复问题。
最多一次消费（at most once）:主要是保证数据不会重复，但有可能存在数据丢失问题。
如果能同时解决了数据丢失和数据重复消费的问题，那么就实现了精确一次消费的语义了。
1.2 数据丢失原因
graph TD
A[Kafka] -->|Spark Streamming,提交偏移量offset| B(Mysql,ElasticSearch或Clickhouse)
Kafka是用offset（偏移量）标志数据被消费了，offset可以手动提交和自动提交，偏移量提交方式是在kafkaParam参数中设置的，
设置"enable.auto.commit"的值是true还是false
Kafka自动提交偏移量机制: 通过时间，定时进行提交偏移量,这种情况会导致如果消费宕机了，偏移量又被提交了，这样数据就不能被重新消费了，
我们希望就算消费时宕机了，也能重新设置offset，让数据被重新消费
1.3 数据消费重复
Kafka数据为什么重复: 写完数据后提交偏移量，在这时系统宕机了，这时就会出现数据已经写入ES，但是偏移量offset还没有提交，这样当系统好了后，这条数据就会被重新消费
1.4 解决方法
使用原子性的消费： 事务能够保证原子性消费，事务对分布式使用压力很大且麻烦，事务具有回滚功能，把消费数据和提交偏移量绑定成一个事务，事务都完成了，才是完成. 事务能绝对保证精确一次消费
1.4.1 使用事务：
性能问题:
- 必须向关系型数据库中写，NoSQL不能使用事务，偏移量也存在关系型数据库
- 事务本身性能不好
- 要考虑分布式事务，一般一个事务是多个分区多线程多机器写入，一次偏移量提交，如果事务失败了，要回滚多个线程多个机器数据， spark streamming消费kafka时，driver负责提交偏移量offset，分布式事务会带来管理的复杂性，一般企业不选择使用，把分布式事务变成本地事务，把executor的数据提取到driver(rdd.collect())；collect把executor数据放到driver中。由driver统一写入数据库会变成单线程操作，降低了写入吞吐量；当数据不多时可以这样做
- 只要满足一个条件就可以用事务解决：数据足够少，保证数据一直很少，通常经过聚合后的数据很少
1.4.2 手动提交偏移量+幂等性处理
先保存数据再提交offset，然后使用幂等性修补数据重复问题
幂等性：来同样的数据，能识别这一条数据与上一条数据是否一样；看数据库是否支持幂等性，如果数据库不支持，需要无奈接受重复；能接受数据重复，不能接受数据丢失；mysql之前不支持幂等性。支持upset一般都支持幂等性，
UpSet: 有就写入，没有就覆盖, 有主键，kafka不支持幂等性
缺点：
- 手动提交偏移量能解决，幂等性的存储不一定能解决，受到业务和数据的约束，有可能做不到幂等性；只能满足至少一次消费
问题：
kafka producer 幂等性的发送和我们幂等性有什么关系，kafka不支持幂等性和幂等性发送是否矛盾
幂等性发送：kafka的producer在发送数据时时如果一条数据发送不对，会重新再发送一条，这时候能够识别最新发送一条是否与上一条相同，如果是一条，会把后一条去掉
回答：由于进程重启，新的进程中的producer已经和原来的不一样了，所以如果目标数据库kafka是无法在两个进程中识别是否是同一条数据的kafka的topic分区数量和spark分区是否一致？
回答：默认由线程数core数决定，代码中可以调整，尽量通过core数与kafka分区数相同
1.5 手动提交偏移量操作
1.5.1 手动提交偏移量到kafka中
kafka0.9版本以后consumer的偏移量是保存在kafka的_consumer_offsets主题中。可是如果使用这种方式管理偏移量，有一个限制是在提交偏移量时，数据流的元素结构不能发生转变，即提交偏移量时数据流，必须是InputDstream[ConsumerRecord[String,String]]这种结构。但是在实际中，数据难免发生转变，聚合，关联，一旦发生转变，就无法使用一下语句进行偏移量的提交：
XXDstream.asInstanceOf[CanCommitOffsets].commitAsync(offsetRanges)
因为偏移量放在kafka中有这种问题，所以实际生产中通常会利用<u>zookeeper,redis,mysql</u>等工具对偏移量进行保存
更常用是放在redis，mysql中，使用redis需要保证redis的主从架构高可用。放mysql更安全；偏移量一般每5s中保存一次。
1.5.2 手动提交偏移量到redis中
步骤
Redis中的偏移量是为了故障恢复使用, 偏移量特点：不停更新，偶尔加载，当进程重新启动时加载偏移量。
1.5.3 幂等性处理
ES的唯一性为_id,如果连续来两条相同的_id数据，后一条数据会把前一条数据覆盖。
ElasticSearch要做到幂等性，需要指定_id值，不然会自动生成一个_id,且相同的数据也会生成不同_id。
有时业务中程序做了幂等性处理，可以不要就数据库具有幂等性
