标签：项目 数据库 Redis 主键 亮点 Token 序列号 ID

幂等性

一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

场景

• 购买某些视频网站的会员后，给会员送成长值和送电影券
• 清理或者迁移数据，数据库表仅需要需要一次操作。
• 前端重复提交表单，在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
• 接口超时重复提交，很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。

解决方案

数据库唯一主键

数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性，一般来说唯一主键比较适用于 “插入” 时的幂等性，其能保证一张表中只能存在一条带该唯一主键的记录。

使用数据库唯一主键完成幂等性时需要注意的是，该主键一般来说并不是使用数据库中自增主键，而是使用分布式 ID 充当主键（可以参考 Java 中分布式 ID 的设计方案 这篇文章），这样才能能保证在分布式环境下 ID 的全局唯一性。

• 适用操作

  • 插入操作
  • 删除操作

• 流程

  

  • 客户端执行创建请求，调用服务端接口。
  • 服务端执行业务逻辑，生成一个分布式 ID，将该 ID 充当待插入数据的主键，然后执数据插入操作，运行对应的 SQL 语句。
  • 服务端将该条数据插入数据库中，如果插入成功则表示没有重复调用接口。如果抛出主键重复异常，则表示数据库中已经存在该条记录，返回错误信息到客户端。

数据库乐观锁

数据库乐观锁方案一般只能适用于执行 “更新操作” 的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。

• 需要数据库对应业务表中添加额外字段；

• 适用操作

  • 更新操作

• 流程

  

防重 Token 令牌

针对客户端连续点击或者调用方的超时重试等情况，例如提交订单，此种操作就可以用 Token 的机制实现防止重复提交。简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，这样来保证幂等操作。

• 需要生成全局唯一 Token 串；
• 需要使用第三方组件 Redis 进行数据效验；

• 适用操作

  • 插入操作
  • 更新操作
  • 删除操作

• 流程

  

  • 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。
  • 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
  • 然后将该串存入 Redis 数据库中（判断token是否存在），以该 Token 作为 Redis 的键（注意设置过期时间）。
  • 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
  • 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。
  • 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。
  • 服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。

下游传递唯一序列号

所谓请求序列号，其实就是每次向服务端请求时候附带一个短时间内唯一不重复的序列号，该序列号可以是一个有序 ID，也可以是一个订单号，一般由下游生成，在调用上游服务端接口时附加该序列号和用于认证的 ID。

当上游服务器收到请求信息后拿取该 序列号 和下游 认证 ID 进行组合，形成用于操作 Redis 的 Key，然后到 Redis 中查询是否存在对应的 Key 的键值对，根据其结果：

• 如果存在，就说明已经对该下游的该序列号的请求进行了业务处理，这时可以直接响应重复请求的错误信息。

• 如果不存在，就以该 Key 作为 Redis 的键，以下游关键信息作为存储的值（例如下游商传递的一些业务逻辑信息），将该键值对存储到 Redis 中 ，然后再正常执行对应的业务逻辑即可。

• 要求第三方传递唯一序列号；

• 需要使用第三方组件 Redis 进行数据效验；

• 适用操作

  • 插入操作
  • 更新操作
  • 删除操作

• 流程

  

  • 下游服务生成分布式 ID 作为序列号，然后执行请求调用上游接口，并附带 “唯一序列号” 与请求的“认证凭据 ID”。
  • 上游服务进行安全效验，检测下游传递的参数中是否存在 “序列号” 和“凭据 ID”。
  • 上游服务到 Redis 中检测是否存在对应的 “序列号” 与“认证 ID”组成的 Key，如果存在就抛出重复执行的异常信息，然后响应下游对应的错误信息。如果不存在就以该 “序列号” 和“认证 ID”组合作为 Key，以下游关键信息作为 Value，进而存储到 Redis 中，然后正常执行接来来的业务逻辑。

标签：项目,数据库,Redis,主键,亮点,Token,序列号,ID
来源： https://www.cnblogs.com/faetbwac/p/16508255.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。