用业务幂等设计替代重量级事务机制，应对at least once带来的重复数据

Kafka这类上游数据源，只要保证的是at least once（至少一次成功）而不是exactly once（恰好一次）语义，数据源在正常运行过程中出现重复数据就是一个必然会发生、而不是偶发异常的情况。面对这种必然存在的重复数据风险，Storm本身提供了事务机制作为解决方案，但大众点评在实际业务中选择了不启用事务——原因在于事务机制虽然理论上能保证数据处理的精确一次性，但会对性能产生比较大的影响，这个代价是否值得，需要结合具体业务自行权衡。他们的实际做法是：在不使用事务的前提下，转而要求业务本身具备幂等性——如果业务处理逻辑本身是幂等的（同一条数据被重复处理多次，最终结果和只处理一次完全一样），那么上游数据源产生的重复数据就不会造成任何实际问题，不需要靠昂贵的事务机制去从根源上消灭重复，而是从容地接受重复数据的存在，把”重复处理是否造成影响”这个问题化解在业务逻辑设计本身上。这个案例给出了一条应对分布式系统里”精确一次”这个经典难题的实用思路：面对”上游可能产生重复数据”这个几乎无法从根本上消除的现实约束，有两条截然不同的应对路径——一条是花费高昂的性能代价去引入更强的一致性机制（事务），试图让重复数据这件事本身不再发生；另一条是接受重复数据会发生这个现实，转而在下游把业务逻辑设计成对重复不敏感（幂等），让重复数据发生了也不会造成任何实际影响。两条路径没有绝对的优劣之分，但幂等设计路径的性能代价通常远低于引入完整事务机制，只要业务逻辑本身具备设计成幂等的可行性（比如用”设置为某个最终状态”代替”在原有状态上累加”这类操作），优先考虑幂等设计往往是投入产出比更高的选择。