high-concurrent-cache
  • Introduction
  • Redis
    • redis常用命令
      • 生产环境谨慎使用keys命令
      • Redis 命令参考
    • redis客户端
      • Jedis使用指南
      • redisson
      • redis连接池
      • jedisCluster详解
      • jedisCluster+SpringMVC整合
    • redis主从模式
      • 配置方式
      • 一主多从读写分离架构
    • redis持计划机制的讲解
      • 持久化
      • RDB详解
      • AOF详解
      • RDB与AOF异同比较
    • 哨兵机制详解(sentinel)
      • 哨兵使用架构(sentinel)
      • 哨兵工作原理/哨兵如何监控redis
      • 哨兵如何高可用
      • 哨兵内部通讯原理/自动发现 Sentinel 和从服务器
      • 基于哨兵的redis高可用架构
    • redisCluster集群
      • 架构分析
      • 搭建高可用集群
      • 分区存储详解
      • java客户端使用redisCluster
    • 实战场景
      • 高性能分布式缓存
      • 实现定时消息通知
      • 简单高速队列的实现与应用
      • 实现去重幂等性
      • 数据计数/订单号生成
      • 基于redis实现分布式锁
      • 排行榜
      • 使用Redis bitmaps进行快速、简单、实时统计
      • 利用Redis集合(Set)统计新增用户和次日留存率
    • Redis回收进程如何工作的? Redis回收使用的是什么算法?
    • Redis持久化数据和缓存怎么做扩容?
    • Redis 分区的优势、不足以及分区类型
    • Redis 大量数据插入
    • redis实现简单延时队列
    • 使用 redis 如何设计分布式锁?说一下实现思路?使用 zk 可以吗?如何实现?这两种有什么区别?
    • Redis的bitmap讲解
    • 分布式锁的漫画教程
  • Memcached
    • Memcached概念
    • 安装配置
      • Linux安装
      • Windows安装
    • 集群搭建
    • 常用场景
    • 客户端命令
      • 客户端连接命令
      • Memcached 存储命令
        • Memcached set 命令
        • Memcached add 命令
        • Memcached replace 命令
        • Memcached append 命令
        • Memcached prepend 命令
        • Memcached CAS 命令
      • Memcached 查找命令
        • Memcached get 命令
        • Memcached gets 命令
        • Memcached delete 命令
        • Memcached incr 与 decr 命令
      • Memcached 统计命令
        • Memcached stats 命令
        • Memcached stats items 命令
        • Memcached stats slabs 命令
        • Memcached stats sizes 命令
        • Memcached flush_all 命令
    • Java客户端
    • memcached特点与redis区别
    • 一致性哈希算法原理
    • Memcache 高可用集群之magent实现主从
  • 互联网缓存架构设计
    • 常见的缓存架构方案
    • 缓存雪崩的解决方案
    • 缓存穿透的解决方案
    • 缓存击穿的解决方案
Powered by GitBook
On this page

Was this helpful?

  1. Redis
  2. 实战场景

实现去重幂等性

WEB资源或API方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的。幂等性是分布式系统设计中的一个重要概念,对超时处理、系统恢复等具有重要意义。声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试。例如,在因网络中断等原因导致请求方未能收到请求返回值的情况下,如果该资源具备幂等性,请求方只需要重新请求即可,而无需担心重复调用会产生错误。实际上,我们常用的HTTP协议的方法是具有幂等性语义要求的,比如:get方法用于获取资源,不应有副作用,因此是幂等的;post方法用于创建资源,每次请求都会产生新的资源,因此不具备幂等性;put方法用于更新资源,是幂等的;delete方法用于删除资源,也是幂等的。

常见用来保证幂等的手段:

1.MVCC方案 多版本并发控制,该策略主要使用update with condition(更新带条件来防止)来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中,合理的使用乐观锁,通过version或者updateTime(timestamp)等其他条件,来做乐观锁的判断条件,这样保证更新操作即使在并发的情况下,也不会有太大的问题。例如

select * from tablename where condition=#condition# //取出要跟新的对象,带有版本versoin
update tableName set name=#name#,version=version+1 where version=#version#

在更新的过程中利用version来防止,其他操作对对象的并发更新,导致更新丢失。为了避免失败,通常需要一定的重试机制。

2.去重表 在插入数据的时候,插入去重表,利用数据库的唯一索引特性,保证唯一的逻辑。

3.悲观锁

select for update,整个执行过程中锁定该订单对应的记录。注意:这种在DB读大于写的情况下尽量少用。

4. select + insert 并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方法是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。注意:核心高并发流程不要用这种方法。

5.状态机幂等 在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机,就是业务单据上面有个状态,状态在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。

6. token机制,防止页面重复提交

业务要求:页面的数据只能被点击提交一次 发生原因:由于重复点击或者网络重发,或者nginx重发等情况会导致数据被重复提交 解决办法:

  • 集群环境:采用token加redis(redis单线程的,处理需要排队)

  • 单JVM环境:采用token加redis或token加jvm内存

处理流程:

  • 数据提交前要向服务的申请token,token放到redis或jvm内存,token有效时间

  • 提交后后台校验token,同时删除token,生成新的token返回

token特点:要申请,一次有效性,可以限流

7. 对外提供接口的api如何保证幂等

如银联提供的付款接口:需要接入商户提交付款请求时附带:source来源,seq序列号。source+seq在数据库里面做唯一索引,防止多次付款,(并发时,只能处理一个请求)

总结: 幂等性应该是合格程序员的一个基因,在设计系统时,是首要考虑的问题,尤其是在像支付宝,银行,互联网金融公司等涉及的都是钱的系统,既要高效,数据也要准确,所以不能出现多扣款,多打款等问题,这样会很难处理,用户体验也不好 。

Previous简单高速队列的实现与应用Next数据计数/订单号生成

Last updated 5 years ago

Was this helpful?