单线程

四季春风,不厌冬

  1. 数据结构
  2. 前端传参
  3. 后端缓存次重要信息
  4. 优点
  5. 缺点

  在开发http接口时,需要定义接口参数,这是再正常不过流程,但是大家是否想过,有些参数可能不需要调用方传入,而是接口提供者可以从后台缓存获取。

  首先申明一个定律:

数据越多,出错的概率就越大。

  我们知道代码量太大,容易出bug。同理,在系统交互的过程中,网络传输的数据越多,出错的概率也就越大。我从saas营销活动(以下简称“活动”)模块来谈谈。

数据结构

  首先介绍下活动的数据结构,一个活动的数据结构包括创建主体、活动编号、活动名称等,活动编号全库唯一。活动和创建主体的关系为N:1,即一个活动只有一个唯一的主体,且活动主体不支持变更。

前端传参

  前端发起查询活动详情的http请求,一般后端需要接收创建主体和活动编号,根据创建主体做一些权限的判断。那么问题来了,前端可能丢失创建主体参数,后端也只需要做判空校验,返回提示信息即可,这样的交互大家都见过。但是如果某些特殊情况前端未获取到创建主体呢?那么再多的提示也无济于事。

  无论是前后端交互,还是soa服务交互,一个道理。

后端缓存次重要信息

  对于创建主体类型的次重要信息,后端可以做缓存,以避免前端未获取参数的情况出现,缓存的时机可以选在上一次请求,比如获取详情前是查询活动列表,那么可以在返回活动列表的同时将次重要的信息缓存起来,并在下一次分页查询时更新缓存。

优点

  • 提高系统安全性

缺点

  • 引入Redis中间件,增大系统复杂度

本文作者 : pengqin.zhou
本文使用 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
本文链接 : https://www.zhoupq.com/blog/%E5%89%8D%E7%AB%AF%E4%BC%A0%E5%80%BC%E8%BF%98%E6%98%AF%E5%90%8E%E7%AB%AF%E7%BC%93%E5%AD%98%EF%BC%9F/

本文最后更新于 天前,文中所描述的信息可能已发生改变