早季ios客户端服务接口

摘要
早季社区的ios客户端java接口日志

新功能

• 这几天很怠惰,定一个两周小目标: 要完成早季2.2的更新.每天22点到24点,周日非特殊情况全天.如果做不到请让我以后没有键盘可用.
  • 服务端
    • 更新-发布相集接口添加标签
    • 更新-发布相集预览接口返回标签字段
    • 更新-相集分页接口返回标签字段
    • 更新-相集详情接口返回标签字段
    • 更新-添加相集时更新用户标签集
    • 更新-添加相集时更新相集标签集
    • 更新-用户中心返回标签字段
    • 更新-相集发布预览接口,获取本场漫展内的标签
    • 新增-根据漫展id查询所有标签
    • 新增-根据标签检索相集
    • 新增-根据标签与用户id检索相集
    • 新增-妆娘类型
  • 客户端(android ios)
    • 更新-发布页面添加标签功能
    • 更新-相集分页item添加标签展示
    • 更新-相集详情页面添加标签展示
    • 新增-用户详情页面添加标签展示
    • 新增-根据标签检索相集页面
    • 新增-点击任意标签可以跳转到检索相集页面
    • 新增-相集添加妆娘tag
  • ps
    • 通过canal使mysql与es进行同步
    • 列表查询走mysql
    • 标签检索走es

预计开发周期

• 写java就要快乐很多了,因为原型基本定下来了,只需要完形填空就好了.这一版不考虑性能优化,主要用作测试
• 预计1到两周完成最晚时间节点8.16

预计效果

• 10w用户
• 单表500w
• 单机服务
• 百人同传图片,千人观看

策略

1. xxx数量策略

例如喜欢,redis缓存like与cancel_like.每天持久化到mysql

查询mysql -> 查询redis -> mysql_num + redis_num

2. 通知、我的点赞、我的评论

用户查询首页时清零提醒

3. 未查看点赞通知情况下,用户取消点赞展示策略

client:

• 点赞时前端记录主键id与类型.
• 展示时检索是否存在,存在展示已点赞,不存在展示未点赞.
• 前端缓存用户点赞记录,只有第一次赞消息才有点赞通知,减少服务端压力

  server

参考微信朋友圈

1. 用户A点赞用户B -> 用户B收到点赞通知
2. 用户B未查看点赞通知,用户A取消点赞 -> 用户B依旧有新消息提醒,通知列表依旧存在用户A的点赞记录,但此条动态详情并没有用户A点赞记录
3. 用户A点赞用户B -> 并未收到新消息提示

4. 未查看点赞通知情况下,用户删除评论与回复展示策略

区别于点赞,评论属于互动消息,需要同时删除新消息、通知、评论

5. 删除评论策略

只删除本条评论,删除本条通知

评论删除后回复,点开回复通知时,展示此条评论不存在

6. 删除回复

删除本条回复,删除本条通知

7. 接口固定返回值

1). 301 接口异常
2). 401 权限不足
3). 403 未登录

8. 分页策略

• 数据全部保存在mysql并且不存在分表分库的单一情况
• 涉及到用户信息但是又无法查询到用户时,将此条信息完全移除
• 如果当前页查询到list为空时,查询下一页,并且当前页+1
• 返回时只返回当前页,不返回总页数

9. 图片上传策略(暂未确定)

图片策略应该是本app的核心功能,所以必须仔细推敲

中间件

• 由fastdfs实现图片存储

• 由fastdht实现文件查重

  业务

• (废弃,采用COS)文件上传有两个接口实现

  • 文件上传接口(负责将文件上传到文件服务器,缓存到redis)
  • 保存文件接口(确认保存,删除缓存redis)
  • 定时清理(redis的超时文件)

• (废弃,采用COS)fastdfs会储存源文件,并建立文件索引,如果图片的hash值重复(fastdht检索),则只创建文件索引,删除时也是先删除索引,当最后一个索引被

• (废弃,采用COS)删除时,源文件将被删除.以解决,单用户或多用户上传相同文件问题.此接口返回文件路径

• 注册与登录

  1. 判断类型
     1. 手机号登录
        1. 根据手机号查询用户
        2. 存在登录成功
        3. 不存在 调用注册接口
     2. 其他授权登录
        1. 根据授权id查询用户
        2. 存在登录成功
        3. 不存在 throw 绑定手机号

• 手机验证码

  1. 每天只能请求10次
  2. 校验验证码是否符合规则
  3. 判断最后一次发送验证码时间 每分钟只能请求一次
  4. 根据类型发送不同模版验证码
     1. 注册或登录验证码: 判断手机号是否为注册用户 如果是发送登录模版 否则发送注册模版

• 关注动态采用队列推送

  • 暂时搁置 可选替换方案
  • 基于用户关注
  • 动态页面展示一级用户列表，如果想查看动态需要手动点开用户信息

• 通知策略1.0 (废弃)

  • 使用redis集合消息队列实现
  • 除点赞通知,其他通知实现策略
    • redis未读消息字段+1
    • 具体信息丢进消息队列
    • 前端保存通知消息,后端不存储
  • 点赞通知策略,与评论等通知需求有点出入,点赞需要的是一个相对宏观数据,无需每个人的信息,所以
    • key1存储: 总未读数量 例如: likeNum_{userInfoId} 代表此用户存在x条未读消息数量
    • key2: 存储具体信息 例如: likeNotice_{userInfoId} 代表此用户的某个点赞信息的数量 hash_key = {type}_{fk_id}
    • 触发点赞:
      • redis总未读数+1
      • 判断点赞hash_key是否存在
        • 存在:
          1. hash_key increase 1
        • 不存在:
          1. hash_key increase 1
          2. 添加消息队列

• 通知策略2.0 (废弃)

  • 劣势
    • 假设用户30天未登录, 第31天登陆, 无法看到第29天的点赞通知提醒(未读数量不精准)
    • 未读消息服务端不会长时间保存
  • 保存:
    1. 信息存储到mysql 过期时间30天
    2. 未读数增加到redis 过期时间30天
  • 查询
    1. 后端参数为 noticeIdList
    2. 如果noticeIdList存在,则先删除.后根据userInfoId typeKey 查询 limit 20
    3. 前端保存服务端数据
    4. 前端查询时需要传递参数 上一次查询到的id

• 一级评论附加二级评论缓存策略

  • 优势:
    1. 逻辑简洁,不占用内存空间
  • 劣势:
    1. 增加mysql 记录长度 会影响评论查询效率(具体影响如何有待测试,但比较适合当前系统环境)
    2. 如果只有删除没有新增,会导致预览为空
    3. 昵称如果用户修改 无法得到对应刷新
  • 漏洞: 并发时有概率出现超出规范长度范围的更多数据 4 5条.可以通过消息队列解决,但是优先级暂不考虑
  • 分页
    • 将previewCommentTwoListJson字段反序列化即可
  • 添加
    • 判断一级评论长度<3更新预览字段
  • 删除
    • 如果删除的是预览二级评论则重新更新一级评论预览字段
  • 已废弃,就目前系统架构来说,有点画蛇添足,采用更简洁的方式实现
    • 劣势: 比较浪费内存空间 初次加载比较慢
    • 优势: 查询速度较快 虽然浪费内存空间,但因为缓存时间为24小时,长时间未看的消息并不会被缓存
    • 分页
      1. 获取分页列表
      2. 通过redis获取一级评论下二级评论数量
      3. 通过redis获取一级评论下的二级评论预览list json
         • 获取到
           • 判断list json长度
             • list json 长度 >= 3
               • 使用此json
             • list json 长度 < 3
               • 判断二级评论数量
                 • 二级评论数量 > list json长度
                   • 获取子评论 limit 3
                   • 将子评论 limit 3 缓存进redis
                   • expiretime 24hours
         • 未获取到
           • 判断二级评论数量
             • 二级评论数量 > list json长度
               • 获取子评论 limit 3
               • 将子评论 limit 3 缓存进redis
               • expiretime 24hours
    • 添加
      • 重新获取子评论并添加缓存
    • 删除
      • 重新获取子评论并添加缓存

• 删除一级评论逻辑

  1. 一级评论发布账号id是否与登陆账号id相同
  2. 不相同则验证是否为相集类型评论 不是则跳出
  3. 相同则验证登陆账号是否为相集发布者 不是则跳出
  4. 删除一级评论
  5. 删除二级评论
     1. 删除二级评论
     2. 删除点赞对象
     3. 删除点赞数量
     4. 删除二级评论数
  6. 减少一级评论数量
  7. 删除点赞记录
  8. 删除点赞数量

• 删除二级

  1. 二级评论发布账号id是否与登陆账号id相同
  2. 不相同则验证是否为相集类型评论 不是则跳出
  3. 相同则验证登陆账号是否为相集发布者 不是则跳出
  4. 删除二级评论
  5. 删除二级评论数
  6. 减少二级评论数量
  7. 重置一级评论预览
  8. 删除点赞记录
  9. 删除点赞数量

• 删除相集

  1. 删除帖子
  2. 删除目录
  3. 相集参加人数 -1
  4. 用户参展数 -1
  5. 点赞数删除
  6. 点赞对象删除
  7. 删除集邮(参考删除集邮逻辑)
  8. 一级评论删除(逻辑参考一级评论删除)
  9. 二级评论删除(逻辑参考二级评论删除)

• 删除集邮

  1. 删除源数据
  2. 删除目录
  3. 相集内用户被集邮次数 - 1
  4. 我与此用户集邮次数 - 1
  5. 我的总集邮次数 - 1
  6. 我在此漫展内的集邮次数 - 1
  7. 一级评论删除(逻辑参考一级评论删除)
  8. 二级评论删除(逻辑参考二级评论删除)

• 发布日推

  1. 保存
  2. 增加日推数量

• 添加一级评论

  1. 保存
  2. 增加评论数量
  3. 通知

• 添加二级评论

  1. 保存
  2. 更新一级评论预览字段
  3. 增加一级评论下的二级评论数量
  4. 插入通知

• 非点赞的其他通知

  1. 查重
  2. 增加未读点赞数量
  3. websocket获取未读消息数量

• 点赞通知

  1. 查重
  2. 增加未读点赞数量
  3. websocket获取未读消息数量
  4. 更新本通知的最新用户是谁

后置功能模块

1. 点赞、评论、回复的通知app模块与即时通知策略
2. 打赏的回调
3. 有一个开源想法
4. 所有getbypk 进入redis
5. 注意所有保留回传url接口,需要验证文件是否存在,以防止有人恶意上传url
6. 我与ta的集邮数量,计划进redis缓存
7. coser删除集邮删除,并选择通知类型
8. 点赞取消点赞进队列,因为在异步点赞与取消但赞时,点赞可能还没执行,取消点赞已经开始
9. 数量相关的字段,全部放置于redis,不再考虑mysql
10. 相集删除时,将stamp删除,相关的num归位
11. 相集删除时通知集邮用户,相集已被删除

开发日志

2021/12/22

• 添加接口-获取版本号

2021/12/21

• 添加接口-绑定手机号
• 修改接口-获取验证码只有数字

2021/12/20

• 添加接口-获取短信验证码
• 修改接口-微信、苹果、qq第三方授权登录,手机号登录与手机号注册整合为同一接口

2021/12/19

• 思考注册整合流程,与防刷策略
• 想做滑块验证的但是受限于个人技术和服务器性能决定妥协为图形验证码,体验肯定是没有滑块要好
• 添加接口-获取图形验证码

2021/12/11

• 评论接口 只有特定类型需要通知

2021/12/9

• 添加接口
  • 关注/取消关注
  • 关注列表
  • 粉丝列表
  • 留言
  • 回复留言
  • 删除留言

2021/12/4

• 修改通知接口 针对点赞通知需要特殊优化部分字段
• 修改通知接口 清空未读通知数

2021/12/3

• 一级评论通知详情 接口开发
• 二级评论通知详情 接口开发

2021/12/2

• 优化通知接口 更具不同通知类型返回更多信息 用于页面跳转使用
• 删除集邮时多余的上传字段 漫展封面 漫展标题 用户相集封面
• 通知相集集邮详情接口

2021/11/30

• 将点赞记录完全存于redis,不再考虑持久化
• 一级评论通知
• 二级评论通知
• 点赞通知
• 集邮通知

  2021/11/29

• 根据sa-token修改验证websocket风格,传入token,根据token获取userInfoId
• 通知未读消息
• 改造所有模块分页模式, 不再采用order by id (ase/desc) limit 1,20 方式.
  改为where id > ? order by id (ase/desc) limit 20
• 将主键id 由varchar改bigint 因为需要主键排序 其中comment_two parentid与 as_photo_participated photo_coser_id photo_pho_id
  需要特别注意一下 涉及到逻辑修改

2021/11/25

• 一级评论-删除
• 二级评论-删除
• timestamp改dateTime
• shiro+jwt改sa-token
• 如果获取不到信息,将throw not_found 前端要做相对应的提示
• 完善删除联动的逻辑

2021/11/24

• 使用shiro+jwt代替shiro框架转变为无状态权限验证。对jwt与shiro有了进一步的理解,shiro会将用户会话保存在服务端,
  这也就是为什么,可以直接通过shiroutils获取到用户信息,即使将redis超时时间设置为-1,也会超时. 结合jwt以后,变为无状态,服务将不会再保存session,生成的token将保存用户信息.

2021/11/23

• 修正接口-一级评论附加部分二级评论预览
• 一级评论下二级评论数量修成
• 添加接口-展示楼中楼对话
• 修正接口-评论为正序展示,回复为正序展示,楼中接对话为正序展示
• 修改模块策略 - 获取用户失败时 原策略为删除此item, 现改为获取用户时return一个是否存在的字段
  • 前端配合相应的修改
    • 展示时根据是否存在判断展示用户头像或者default图片
    • 评论时需要先判断一个用户是否存在,在进行下一步操作
  • 后端在点赞评论时需要进一步验证用户是否存在,不存在throw一个用户不存在异常
    • 前端需要配合添加相应异常提示
• 修改二级评论数量的展现方式,将comment icon 的数字删除,改为b站方式 共x条回复 >
• likeButton添加padding 增加点击面积

2021/11/20

• 评论模块接口改写

2021/11/19

• websocket 服务端搭建 兼容shiro

2021/11/18

• 改写接口-发布相集
  • 保存时,我的参展次数+1
  • 保存时,我的参展目录信息记录
• 改写接口-删除相集
  • 删除时,我的参展次数-1
  • pho coser都为删除时,我的参展目录信息删除
• 改写接口-发布集邮
  • 保存时,我的集邮总数+1
  • 保存时,我在此漫展内的数量+1
  • 保存时,记录到目录
• 改写接口-发布集邮
  • 保存时,我的集邮总数-1
  • 保存时,我在此漫展内的数量-1
  • 保存时,删除到目录
• 添加接口-我的参展-集邮
• 添加后置功能 10. 11.

2021/11/17

• 实现接口-我参加的漫展列表

2021/11/12

• 集邮数相关的接口改造

2021/11/08

• 集邮的发布接口,删除接口编写
• 改造photoContentHomePage 返回img 以cosImageDTO形式

2021/11/07

• 集邮页面的预览

2021/11/06

• 发现bug,点赞可能出现负数
  • 判断不允许出现负数
• 发现bug,连续点赞,num会增加
  • 好像是因为高强度点赞、取消点赞.单纯的连续点赞通过调用接口测试是不会出现问题,暂时不考虑这些问题
• 与我集邮删除权限,被集邮者可以删除集邮,同时发布通知给集邮者

2021/10/30

• 获取预览图片接口返回是是否为第一次发布,通过此字段判断前端是否展示删除按钮
• 添加pagesend删除结构
• 修改pagesend发布接口

2021/10/19

• 测试cos与sts部分功能(生成下载链接)辅助理解swift版本

2021/10/18

• 参考 shiro整合jwt修改自己的框架

2021/10/15

• 获取临时密钥timing
• 获取临时密钥controller

2021/10/14

• 决定将图片存储由fastdfs搬运到七牛云文件系统.原因是比较省心,如果是自己维护一个文件系统初期的费用较高

2021/10/05

• 测试将分页接口改为 没有下页数据抛出异常,前端页面根据异常拦截

2021/09/26

• coser/pho上传照片预览视图接口

2021/09/24

• 测试了fastdht的去重效果,符合要求

2021/09/23

• 最后使用docker-compose搭建完成

2021/09/22

• 通用文件上传接口
• 用docker方式搭建 fdfs 遇到点问题,挺恶心的
  1. mac与win无法使用–net=host参数
  2. 因为i.导致后续fdht的配置问题

2021/09/13

• 修复点赞bug
• 发送id与接收id相同时不添加notice
• 经过最后的考虑,还是决定点赞进入redis缓存

2021/08/17

• 调整捕捉异常返回格式
• 调整分页返回格式
• 调整相集主页接口
• 调整redisService参数

2021/08/12

• 添加留言
• 添加打赏
• 打赏分页查询记录
• 用户基本信息
• 补充添加喜欢时userinfo like+1
• 添加关注

2021/08/11

• 用户中心ta喜欢
• 用户中心动态
• 用户中心参展
• 用户中心集邮

2021/08/10

• 删除评论
• 调整service模块
• 动态主页分页查询

2021/08/09

• 通知查询
• 新通知数量查询
• 取消点赞
• 思考 评论 点赞 通知之间的关联关系,参考微信朋友圈与b站策略

2021/08/08

• 初始化一级评论、二级评论、喜欢、通知表
• 一级评论分页
• 一级评论添加
• 二级评论分页
• 二级评论添加
• 喜欢添加
• 通知添加

2021/08/07

• 思考评论表、喜欢表、通知表之间的关系
• 填充300w测试数据结合索引查询,考虑得失

2021/08/06

• coser上传照片
• 集邮上传照片

2021/08/05

• coser pho详情
• 新番分页查询
• 新番详情分页查询

2021/08/04

• 相集详情页coser pho照片分页查询
• coser pho详情照片查询
• coser pho集邮照片查询

2021/08/03

• 相集首页分页查询