# smartdevice **Repository Path**: gp10/smartdevice ## Basic Information - **Project Name**: smartdevice - **Description**: No description available - **Primary Language**: Java - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2022-03-14 - **Last Updated**: 2022-03-27 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## 智能设备平台 ### 一 项目的架构 > 我们是一个基于SSM的单体应用,是一个web类型的项目,基于maven构建 ### 二 用户功能 > 用户主要是记录用户数据的,包括帐号(唯一)和密码(必须是非明文,并且相同的密码得到的结果不能一样),注册时间,登录时间,上次登录时间, 登录的ip,上次登录ip,用户的状态(默认值) > 用户的手机号, 邮箱,更新时间, 其他的数据,性别等 > 用户表理论上会有一个默认的主键,看起来的是自增的,还有有些数据是唯一的数据比如用户名,有些数据是非空数据,比如密码,手机号,邮箱等等 > 密码是一样的,但是你的盐不一样,我们生成的md5是密码+盐的值,盐需要保存到数据库,允许部分冗余数据 ### 登录 > 什么是登录,就是判断用户输入的账号密码对不对,但是现在我们的密码是散列值,不能直接用用户传递的密码进行查询 > 我们需要先计算散列值,但是我们的散列值需要一个盐,这个盐也在数据库,所以也要先查询 > 所以我们只能先根据用户名查询数据. 查询到了,拿到盐,重新计算传递的密码的散列值,然后和刚刚查询到的密码进行比较 ### 登录日志 > 用户发起任何的登录,不管是成功还是失败,我们都需要记录下来,需要将一些和登录相关的数据保存 > 我们应该在什么地方记录这些数据, 应该是在登录成功或者失败的下一行代码 > 请求的ip 和对应的地址,以及设备信息如何获取 ## 分类操作 > 我们的每个设备都有对应的分类, 分类的主要目的是方便查询,或者按照某个分组展示数据,还有一个目的,我们的设备有些有远程控制功能 > 远程控制需要数据,相同分类的设备数据应该是一致的,所以设备的控制命令可以保存到分类上面 ### 添加分类 > 添加分类的时候 分类的名字是必须填写的,用户是必须处于登录状态 ### 查询分类 > 查询分类的话,分类这种数据变化的频率相对较小,所以我们的频繁查询得到的结果基本都是一样的,所以没有必要每次都查询数据库 > 我们可以使用缓存将数据临时保存一份,然后每次查询走缓存即可,什么时候会有查询不知道,但是在访问之前必须有缓存 > 所以我们决定在程序启动的时候就加载缓存,这样请求来的时候一定有缓存 > 方案一 是使用Listener监听器 监听服务器启动,但是我们现在的监听器主要是tomcat创建,不是spring管理,所以很多东西无法注入 > 方案二 我们的spring本身也有一个listener,也是在服务器启动的时候加载,在内部会创建对象,我们知道对象有init-method(postconstruct注解),在这个方法内部初始化缓存 > 方案三 spring程序启动完成后会发布一个事件,我们可以监听事件,这样程序驱动后方法就执行了 ### 缓存的有效期 > 缓存不可能永久有效,比如我们做了增删改之后缓存就失效了,数据不一致了,需要让缓存重新加载一次,其实只要知道发生了增删改这个事件就可以,再事件的监听中重新初始化缓存 ### 分类删除 > 根据id删除就可以, 关键问题是, 删除的数据实际上只更新为删除,标记为删除.真正的数据还在,所以导致我们查询的时候其实还可以查询到 > 如果我们要求正常的查询是不能查询到删除数据的数据的话,我们需要把缓存中的数据进行更新,比如数据库中查询所有的时候加上过滤条件status=1 > 或者是我们将所有的数据包括无效的数据查询到缓存中,在缓存中分开保存,一个集合保存有效的数据,一个集合保存被删除的无效数据,默认查询有效的集合 ## 场景 > xxx场景,场景这个词在不同的项目需求中解释会不一样,有的解释就是不同的场景下放不同的设备 > 我们主要是不同的场景放不同的设备,场景可以没有,没有就是默认的.可以选中在某个场景下添加设备 ### 场景查询 > 查询的话理论上是只能看自己的场景,不能看其他人的,所以查询的时候接口中是不需要传递用户信息的,我们可以通过登录的用户来获取数据 > 场景是否可以做缓存?场景的数据是关联用户的,数据量可能会比较多,如果全部查询到缓存中占用的内存资源比较多,所以看起来没有必要 > 但是如果这一会操作的用户比较多,查看场景的比较多,然后用户可能在短时间内连续多次打开软件或者刷新页面 > 我们应该适当考虑安全性的问题,我们可以在网关或者防火墙增加一层过滤,屏蔽掉非法请求(恶意请求),用户在短时间内连续刷新了几次场景 > 上面的分类的缓存是针对所有用户的缓存,并且变化比较少,数据量也少,所以可以长期保存,生命周期比较长 > 我们可不可以有生命周期比较短的缓存,比如十秒钟,几十秒,几分钟,十几分钟这类的缓存,短期缓存主要针对的是访问量比较大的数据 > 在短时间内访问量远远高于修改的次数,这种数据可以用短期的缓存 > 短期缓存怎么设置时间? 如何到期就删除? > 定时任务肯定可以实现,每一分钟执行一次,遍历数据? 查看添加到缓存的时间,然后计算是不是要过期,如果要过期就删除? > 第一个如果短期缓存也稍微多一点,遍历会导致消耗的时间比较长?至少是通过折半进行判断 > 如果这个数据在短时间内用户频繁访问,到期还删除吗?我们要求用户在不查看之后一分钟删除,以用户最后访问时间为准,使用LRU,LFU >