m0_75138009的博客

通过 Redis 的 GEO 功能完成地理位置的相关操作以下是北京几个地区的经纬度：北京站：116.42803 39.903738北京南站：116.378248 39.865275北京西站：116.322287 39.893729在 redis 中添加一个位置的命令查询两个点之间的距离查看某个地点附近的商铺。

好友关注主要有三个功能：1.关注和取关2.共同关注3.关注推送。

达人探店需要实现的功能：1.发布探店笔记。

基于异步判断库存和一人一单，改进秒杀业务，提高并发性能需求：1.新增秒杀优惠卷的同时，将优惠卷信息保存到 Redis 中2.基于 Lua 脚本，判断秒杀库存，一人一单，决定用户是否抢购成功3.如果抢购成功，将优惠卷 id 和用户 id 封装后存入阻塞队列4.开启线程任务，不断从阻塞队列中获取信息，实现异步下单功能。

悲观锁：在加锁时，我们将锁加在含有事物提交的方法上，对于方法的调用，会出现没有被 spirng 管理导致事物无法提交的情况，我们需要拿到其 sping 代理对象来调用含有事物提交的方法（需要添加 aspectjweaver 依赖，并在启动类添加 @EnableAspectJAutoProxy(exposeProxy = true) 注解）在释放锁时，我们需要判断要释放的锁和当前线程的锁是否一致，一致才释放，若不一致则直接让本该释放的锁通过 ttl 延迟释放。在存入锁时，我们使用 UUID 生成 Key。

2.新增秒杀优惠卷，将其对应的普通卷拿到后，封装成秒杀卷，再将其存入数据库，并且将其库存存入 redis 缓存，请求路径：/voucher/seckill。"rules": "全场通用\\n无需预约\\n可无限叠加\\不兑现、不找零\\n仅限堂食","rules": "全场通用\\n无需预约\\n可无限叠加\\不兑现、不找零\\n仅限堂食","rules": "全场通用\\n无需预约\\n可无限叠加\\不兑现、不找零\\n仅限堂食",1.新增普通优惠卷，直接将其存入数据库即可，请求路径：/voucher。

在高并发访问的访问中，对于复杂业务 key 的缓存，可能会在缓存生效前打入大量的请求，导致大量的请求打到数据库解决方案：1.互斥锁，给缓存的构建过程加上一个锁，当拿到锁时才进行下一步，锁被占用则睡眠一段时间后再拿锁2.逻辑过期，给缓存加上一个逻辑过期时间，但是在 redis 中过期的数据不会被真正删除，在查询时，如果 key 在逻辑上过期了，则开启一个锁，并把更新 key 的任务交给另一个线程，然后先直接返回旧数据；若某个遇到锁被占用无需等待，直接返回旧数据。

使用 redis 缓存记录的信息，有可能在数据库被信息被修改导致信息不一致，使用缓存更新来解决这个问题缓存更新策略主要有三种：1.内存淘汰(redis默认开启)2.超时剔除(给key添加TTL时间)3.主动更新(编写业务逻辑)主动更新策略：在数据库更新时删除缓存，通过事物保证数据库的更新和缓存的删除同时成功或失败。对于数据库的更新和缓存的删除的执行顺序：先删后更，在多线程下在数据库完成更新前可能会被另一个线程查询，导致数据不一致；

业务需求：当前端发送 shop/id 的请求时，我们需要向前端响应对应 id 的详细数据给前端直接查询 mysql 效率比较低，我们可以使用 redis 作为中间件进行数据的缓存，先查询 redis ，若redis 中未查询到，则在 mysql 中查询，并在查询后写入 redis 中。

对于登录信息，我们可以使用哈希结构存储不同的信息，使用随机 token 生成随机且唯一的 key,在响应时，将 token 返回给浏览器，在之后需要用到 token 的请求，需要在请求中发送 token。之前我们对 /user/me 路径，直接返回了登录的所有用户信息，其中的 passward 等敏感信息也会被返回到前端，这是很危险的，故我们需要选择性的返回用户信息，隐藏敏感用户信息。再使用第二级拦截器判断用户是否登录，登录的用户一定会存在于线程池，我们可以通过此来判断用户是否登录。

业务：在登录成功后，前端会发送/api/user/me 的 get 请求，我们需要将 session 中的 user 返回给页面，由于后续会有多个业务需要用到登录状态的校验，故这里使用拦截器完成登录状态校验功能。

需要处理的业务：在网页发送 /user/code 路径下的 post 请求后，我们需要检验手机号后，向合法的手机号发送一个随机生成的电话号。

先创建持久层的 UserMapper 继承 mybatis-plus 的方法。控制台输出了查询到的数据，则表示连接没有问题。tb_user 表的封装类 pojo。