牛客社区项目总结

第一章、主页功能
分页实现，按页码搜索10条帖子信息以及对应的用户信息返回给模板。
第二章、
1.任务：注册用户（这个功能较复杂，可以通过记忆数据库表以及功能效果理解记忆），给注册邮箱发送激活邮件，点击邮件的激活链接进行激活。
核心实现：mysql用户表存放用户激活情况，用户激活码，盐，md5加密的密码。注册时生成随机盐（随机数都是用的uuid）并且对密码用md5加密，这时发送激活邮件，随机字符串激活码也是uuid生成，并且激活链接必须包含用户以及激活码信息（这里用pathvariable，所以个人总结就是后端和浏览器交互可以设置path或者cookie携带数据），判断这个路径和mysql里面数据是否对应。（激活链接只需要激活码其实就够了，或者就根本不需要激活码直接用用户名）

2.任务：登录功能。
核心实现：登录验证用户名，密码，生成登录凭证表记录（这些可以不考虑了，直接uuid到用户信息的映射就行了），发送cookie给客户端，默认一天过期。这个记录是用数据库实现的分布式session。加一个拦截器（其实应该就是个代码复用），首先就通过cookie查询用户，查到了就设置在ThreadLocal里面，http响应返回时需要clear。ThreadLocal里保存的用户信息只在单次请求里面有效，让人怀疑这个东西是否有必要。http每次请求通过cookie查询用户信息保持登录状态。
只有购物车、看个人主页等操作需要有登录状态必须登录，很多页面不需要登录。
存验证码，用redis就自然需要保存是哪个（用户+商品，或者IP地址这种做key）的验证码。
头像上传功能就需要设置新的随机文件名保存本地，然后将访问路径存在数据库，并且实现这个路径的访问controller。

@LoginRequired配合拦截器实现重定向到登录页面。
第三章、（个人认为的项目难点在这里，理解需求，设计数据库表）
发布帖子，查看详情，多了帖子表和评论表。
评论表的评论有个字段需要特别注意。评论分三种，一种是帖子的评论，一种是评论的评论，剩下的就是第二种评论指向特定人的评论。
三个字段含义是评论种类，指向的id，指向的人，只有第三种评论指向人才有含义。（这个地方涉及数据结构设计，评论应该需要什么属性即数据库需要什么字段来统一描述三种类型评论，第一个表示评论类型属于三种的哪一种，第二个表示属于谁的子评论，第三个表示第三种评论回复哪个用户，这样设计会比上面好一点点）
查询评论，添加评论同时帖子评论数更新用到事务。

私信列表，发送私信功能。

第四章、
关键点在设计redis的key value来实现一些关注点赞的功能。
这里视频里面的部分key设计并不好，比如关注列表和粉丝列表，这里的key就用关注列表前缀加上用户id就足够唯一标识一个用户的关注列表了，value用zset，得分就是当前的时间戳。
查询关注列表就根据时间得分倒叙再分页查询就ok。

点赞帖子的key是点赞帖子前缀+帖子id，value是点赞的用户集合。
点赞评论的key是点赞评论前缀+帖子id，value是点赞的用户集合。（这里跟视频有不同，这样感觉会更清晰，功能是一样的）
点赞和取消点赞可以判断是否已经赞过。

我收到的赞key是用户收到赞前缀+用户id，value是整数。

点赞取消点赞、关注取关要用事务操作两个redis键值对。

然后优化登录，登录凭证这里略微复杂，猜测是因为涉及前端，这里不用怎么看。这里将凭证通过cookie传到了客户端，并且将数据库的数据存在redis里，redis的对象（key，value都是泛型形式）都是序列化成字符串存储的。这里key是唯一标识uuid也就是凭证。这里是通过uuid存储登录信息，字段包含登录时间，登录凭证，登录凭证过期时间，用户id，登录凭证是否失效的字段。实现的功能有登录时存数据到redis，凭证uuid->登录信息对象（对应了原先数据库的一条记录），一天内退出后再访问就可以不用重新登录（登录时会收到cookie，通过cookie 的凭证查询redis），自己退出登录后就需要再登录。

redis缓存验证码(key是验证码英文名加uuid，uuid通过cookie传给前端)，缓存用户信息，存储登录凭证（这里叫做存储因为设置不过期,这里的key也是uuid，那这些数据就无法快速查询到哪些用户的登录记录）
一方面可能是这里没有前后端分离，一方面感觉这里滥用cookie，cookie应该就是保存一个登录状态就行了，往前端传数据不用cookie。保持一个会话用cookie。

之前在考虑缓存验证码的key value是什么，这里key是uuid，通过cookie传给客户端，然后保存一个uuid-》验证码的值。然后也有考虑之前用用户id加秒杀商品id作为key，只要key能够标识到具体的客户端都行。

缓存用户对象的key是用户id，这里就涉及到数据库缓存一致性了。

uuid总结（个人理解，其实就是用唯一随机串传到前端来做唯一标识，如果有其它的唯一标识也是可以的）
每个用户注册的激活码（这个uuid存在数据库），每个登录验证码的key（这个key不像其他的绑定用户和商品之类的，这个键值对是只要查询map是否包含就ok了，而其他的则需要对key长久保存相当于数据库），头像文件的随机名字，登录凭证（这个uuid会传到cookie）

验证码的key是kaptcha:00d6db8a717a46038dea148616175a2e
value验证码值
登录凭证的key是
“ticket:de48e7de179e4d77a41bb8496dcdb679”
value是一个loginticket对象
关注被关注
“follower:3:111”
“followee:150:3”
3的含义是用户，顺序无所谓，一致就行，value是zset，用户加得分是时间戳。
帖子的赞和用户获得的赞和评论的赞
“like:entity:1:282”
“like:entity:2:236”
“like:user:111”

第五章
kafka异步发送系统通知，
显示系统通知。
就是用message表记录系统发送给谁什么主题的消息，消息内容是map的json字符串。这个地方需要设计吧，包含主题，行为主体等，信息够全就行，然后这里可以是map对象也可以是其他对象转的json串，如果是map应该会比较统一，其他对象会涉及到不同应用之间对象不同。
这个是消息队列异步写入数据库的。

第六章
elasticsearch搜索帖子，发布帖子时异步发送消息，消费者将帖子存入elasticsearch，调用api搜索帖子。

总结：不是前后端分离的项目，很多地方难理解就是因为涉及前端。多看几遍又好像能理解了。（通过cookie和http请求path向前端传信息）