背景
根据用户反馈，查询条件多个时，想要重新看一下上次的查询结果，操作比较繁琐，希望可以有历史查询的功能，将最近查询的n次记录可以找到，方便回溯问题
方案
前端
在用户点击查询按钮的时候，将当前页面链接调接口保存起来，查询时链接会携带查询条件
后端
存储
历史记录需要跟用户身份做绑定，当前天级uv可达75人，不适宜用tcc或者wcc平台进行数据存储
所以需要申请资源进行数据存储
容量
一个连接大小按照500Byte算，如果只保存最近10条记录，那么一个用户需要5000b ==> 5kb
目前平台用户数以1000为底计算,一开始平台会需要 5kb * 1000 ==>5000kb ==> 5mb
(目前纯个人用户有530，加上以部门为单位申请的权限，各部门人数不确定)
假设半年后用户量翻倍那么存储空间需要增加一倍也就是10MB
负载
目前平台日pv 350,日uv 50, 大致计算一个用户一天会访问页面7次，四舍五入假设1天会进行10次查询
1个用户1天会进行10次数据库读写
那整个平台1天平均会进行500次读写，高峰假设1000次读写(75四舍五入)
平均 500 * 500 /(3600*24) ~~ 0.003kb/s 高峰1000*500/(3600*24) ~~~0.006kb/s
很低
数据结构
本来想如果数据库有数组的话，表结构就是用户id + 记录数组；
没有的话，我现在想了两种方案，
一个就是用字符串存这个数组，用户id + 记录数组字符串形式，相当于更新时要先获得这个字符串，转成数组后，看有没有10条，没有的话直接push,有的话，把时间最早的那条删除，push进数组，再转成字符串更新数据库，这样缺点就是展示的时候也得字符串转数组一下；
另一种就是用户id只和一条记录存在一起，不用一个字符串存整个10条记录，更新的时候我去拿数据的时候拿整个用户id所有的，超过10条的话就用数据库删除方法把时间早的删除了，再存进去最新的
看起来都挺麻烦
而且在实际接入数据库的过程中，还要手动执行命令行产生model相关文件
通过调研公司存储系统的各种方式，觉得redis可以更好的解决存储问题，redis支持List类型存储，
而且LPUSH, LPOP,EXPIRE方法可以很好的帮助实现数据存取更新缓存等问题,省了数据库建表等过程
缓存
redis可以很好的支持数据删除，在更新数据的时候重新设置过期时间即可保证删除不活跃用户的记录
实现
申请redis服务，用户工号做redis的key值，key值的value即用户的查询历史记录list,
写接口: 查记录，更新记录
前端在点击查询的时候调接口更新记录
参考文档
存储系统对比 （草稿）Storage System Comparision（Draft） #