首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Curator学习笔记(二)- 防重复提交

    上一篇文章中我们大概了解了Curator做读写锁的原理和过程。根据了解,我们可以使用curator的读写锁来做一个分布式防重复提交的策略。为什么采用curator来做这个事情的原因是curator提供的读写锁能够跨线程和jvm进行加锁。如果不加锁,那么因为网络抖动或者线程切换,谁都不知道防重复提交的token标志是否被其他请求修改。因此这块必然要采用加锁的方式。通过锁的创建和删除来保持多个重复请求的有序性,在保证有序性之后,我们就可以按照逻辑对token进行修改,这样其他线程就能够判断自身是否为重复请求。除此之外,在加锁的时候我们采用临时znode,在会话结束之后就可以自动销毁。因此可以避免zk服务端被累计打满的情况。当然这块的会话时间是可以根据业务需求设置的。对于放重复提交的一般规则来说,我无非就是将session提取出来,而session则是和用户绑定的,因此这块我们将userId作为放重复提交的判断标志,将token表示该用户下次提交的表单的有效token,因此同一时刻,只允许同一用户提交一个表单,否则就会因为抢占token,而导致后一表单提交被认定为重复的提交(这块需要优化,下一个版本再优化!)。

    01
    领券