一、登录模块

1.Session存在共享问题

2. redis

因此选择用redis，数据结构：
手机号:验证码code
随机码为token:用户信息(保存为一个Map<String,Object>对象,具体为key与value)

3.整体流程

(1) 发送验证码
(2) 短信验证码登录、注册
(3) 校验登录状态 token
(4) 拦截器优化

二、实现商品信息缓存

1. 查询流程

2. 缓存与数据库一致性问题

• redis缓存更新策略有几种？选择哪种？
  内存淘汰和过期淘汰 主动更新
• 操作缓存和数据库
  (1) 删除缓存还是更新缓存 删除
  (2)如何保证缓存与数据库的操作同时成功或失败 事务
  (3)先操作缓存还是数据库 写数据库比较慢

3. 三大问题及解决方案

• 缓存穿透
  定义、有哪两种方式解决
  
  
• 缓存雪崩
  定义(2种情况)、解决方案
• 缓存击穿
  定义
  两种解决方案: 一致性、可用性

1. 互斥锁 setnx
   利用redis的setnx命令,通过获取锁和释放锁的方式来完成。锁的过期时间设置10s,能够保证一致性，但是无法保证可用性(线程会一直查询)
   

• 设置逻辑过期时间
  给缓存设置一个逻辑过期时间
  还是需要互斥锁，不同的就是:不是每一个线程都需要取重写数据库,如果发现获取不到锁会直接返回旧的数据，获取不到锁不会说一直重试,而且拿到锁也是开启一个新线程取写数据库。保证了可用性，但失去了一致性(此时拿到的数据不是新的数据)
  
  
• 结果对比

三、优惠券秒杀

1. Redis自增实现全局唯一id

• 常见的生成全局唯一id生成策略
  (各自特点,自己搜资料补充)
• 具体实现方式及原因
  符号位+时间戳+序列号 保证了递增性、安全性、唯一性

2. 秒杀下单，并利用乐观锁解决超卖问题

• 超卖是什么
  库存小于0
• 下单必须满足的条件
  秒杀是否开始或结束，如果尚未开始或已经结束则无法下单
  库存是否充足，不足则无法下单
• 能不能直接采用版本号？存在什么问题
  只要我扣减库存时的库存和之前我查询到的库存是一样的，就意味着没有人在中间修改过库存，那么此时就是安全的，但是以上这种方式通过测试发现会有很多失败的情况，失败的原因在于：在使用乐观锁过程中假设100个线程同时都拿到了100的库存，然后大家一起去进行扣减，但是100个人中只有1个人能扣减成功，其他的人在处理时，他们在扣减时，库存已经被修改过了，所以此时其他线程都会失败
• 项目中的乐观锁如何实现
  在扣减库存之前 判断库存大于0就好

3. 优惠券秒杀：一人一单

• 一人一单
• 解决方案
  
  根据用户id加一个synchronized锁
  控制锁的粒度
  代理模式解决事务失效,并且保证提交事务后再释放锁(不建议自己说出来,坑太多，不好讲)
• 存在的问题：集群模式下锁失效

4.分布锁解决集群下锁失效的问题（基于Setnx）

4.1 基于setnex（setIfAbsent) 实现分布式锁

防止死锁？添加过期时间

4.2 分布式锁的误删问题

什么是误删？ 线程1发生了业务阻塞，锁超时释放了自己的锁，后面正常执行业务后，线程1又执行锁释放把线程2的锁给释放了
如何解决？：在释放锁的时候判断锁是否属于自己

4.3 分布式锁的原子性问题

判断锁和释放锁是两个不同的动作！需要让判断和释放锁变成一个原子操作
利用lua脚本

4.4 存在的问题

不可重入
不可重试
超时释放
主从一致性

5. 基于Redission的分布式锁（对setnex的优化）

5.1 不可重入

5.2 锁重试和watchdog机制

5.3 MultiLock解决主从不一致问题

redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主丛节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性

6. 异步秒杀优化

• 基于阻塞队列的思路
• 先利用Redis完成库存余量、一人一单判断，完成抢单业务
• 再将下单业务放入阻塞队列，利用独立线程异步下单
• 基于阻塞队列的异步秒杀存在哪些问题？
  内存限制问题
  数据安全问题
• 基于Redis的Stream结构作为消息队列,实现异步秒杀下单
• 创建一个Stream类型的消息队列，名为stream.orders
• 修改之前的秒杀下单Lua脚本，在认定有抢购资格后，直接向stream.orders中添加消息，内容包含voucherId、userId、orderId
• 项目启动时，开启一个线程任务，尝试获取stream.orders中的消息，完成下单 (用Java代码消息队列中的信息)，出现异常需要读取Pending List的
• Stream类型消息队列的消费者组的特点

四. 点赞排行榜

SortedSet数据结构 根据时间进行排行的

• 问题一：代码细节

    List<UserDTO> userDTOS = userService.query()
            .in("id", ids).last("ORDER BY FIELD(id," + idStr + ")").list()
            .stream()
            .map(user -> BeanUtil.copyProperties(user, UserDTO.class))
            .collect(Collectors.toList());

• 问题二：SortedSet底层
  hash结构：关联元素和权重
  跳跃表：空间换时间，提高查找效率

五. 附近商户

• 设计思路
  
• 选择geo数据结构
• 分组
  根据type来对数据进行筛选，所以我们可以按照商户类型做分组，类型相同的商户作为同一组，以typeId为key存入同一个GEO集合中即可
• 导入数据
  数据库表中的数据导入到redis中去，redis中的GEO，GEO在redis中就一个menber和一个经纬度，我们把x和y轴传入到redis做的经纬度位置去，但我们不能把所有的数据都放入到menber中去，毕竟作为redis是一个内存级数据库，如果存海量数据，redis还是力不从心，所以我们在这个地方存储他的id即可。

六. 用户签到

0. 数据结构

Bitmap
bitMap返回的数据是10进制

1. 签到功能

@Override
public Result sign() {
    
    // 1.获取当前登录用户
    Long userId = UserHolder.getUser().getId();
    // 2.获取日期
    LocalDateTime now = LocalDateTime.now();
    // 3.拼接key
    String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
    String key = USER_SIGN_KEY + userId + keySuffix; //user:sign:5:202302
    // 4.获取今天是本月的第几天
    int dayOfMonth = now.getDayOfMonth();
    // 5.写入Redis SETBIT key offset 1
    stringRedisTemplate.opsForValue().setBit(key, dayOfMonth - 1, true);
    return Result.ok();
}

2. 统计签到天数

思路：
bitMap返回的数据是10进制，哪假如说返回一个数字8，那么我哪儿知道到底哪些是0，哪些是1呢？我们只需要让得到的10进制数字和1做与运算就可以了，因为1只有遇见1 才是1，其他数字都是0 ，我们把签到结果和1进行与操作，每与一次，就把签到结果向右移动一位，依次内推，我们就能完成逐个遍历的效果了。

七. UV统计

数据结构的选择HyperLogLog

八. 共同关注

选择的数据结构是set，比如用户1关注了A B C，那么就是 1：A B C
同理对用户2有同样的操作，求共同关注就是求两个set的交集

//设置key：当前登录用户，关注的对象
   stringRedisTemplate.opsForSet().add(key, followUserId.toString());
 //求交集
   Set<String> intersect = stringRedisTemplate.opsForSet().intersect(key, key2);

九. 推模式Feed流

1. Feed流理论

1. feed流：内容推送给用户
2. feed流两种模式：Timeline和智能排序
3. Timeline三种实现方式：推、拉、推拉结合
   拉模式:
   当张三和李四和王五发了消息后，都会保存在自己的邮箱中，假设赵六要读取信息，那么他会从读取他自己的收件箱，此时系统会从他关注的人群中，把他关注人的信息全部都进行拉取，然后在进行排序
   
   推模式：
   推模式是没有写邮箱的，当张三写了一个内容，此时会主动的把张三写的内容发送到他的粉丝收件箱中去，假设此时李四再来读取，就不用再去临时拉取了
   优点：时效快，不用临时拉取
   缺点：内存压力大，假设一个大V写信息，很多人关注他， 就会写很多分数据到粉丝那边去
   
   推拉结合模式：也叫做读写混合，兼具推和拉两种模式的优点。
   推拉模式是一个折中的方案，站在发件人这一段，如果是个普通的人，那么我们采用写扩散的方式，直接把数据写入到他的粉丝中去，因为普通的人他的粉丝关注量比较小，所以这样做没有压力，如果是大V，那么他是直接将数据先写入到一份到发件箱里边去，然后再直接写一份到活跃粉丝收件箱里边去，现在站在收件人这端来看，如果是活跃粉丝，那么大V和普通的人发的都会直接写入到自己收件箱里边来，而如果是普通的粉丝，由于他们上线不是很频繁，所以等他们上线时，再从发件箱里边去拉信息。

2. 实现方案

在保存完探店笔记后，获得到当前笔记的粉丝，然后把数据推送到粉丝的redis中去。按照时间顺序feed,数据结构

@Override
public Result saveBlog(Blog blog) {
    
    // 1.获取登录用户
    UserDTO user = UserHolder.getUser();
    blog.setUserId(user.getId());
    // 2.保存探店笔记
    boolean isSuccess = save(blog);
    if(!isSuccess){
    
        return Result.fail("新增笔记失败!");
    }
    // 3.查询笔记作者的所有粉丝 select * from tb_follow where follow_user_id = ?
    List<Follow> follows = followService.query().eq("follow_user_id", user.getId()).list();
    // 4.推送笔记id给所有粉丝
    for (Follow follow : follows) {
    
        // 4.1.获取粉丝id
        Long userId = follow.getUserId();
        // 4.2.推送
        String key = FEED_KEY + userId;
        stringRedisTemplate.opsForZSet().add(key, blog.getId().toString(), System.currentTimeMillis());
    }
    // 5.返回id
    return Result.ok(blog.getId());
}

功能二：实现分页查询
思路分析
1、每次查询完成后，我们要分析出查询出数据的最小时间戳，这个值会作为下一次查询的条件
2、我们需要找到与上一次查询相同的查询个数作为偏移量，下次查询时，跳过这些查询过的数据，拿到我们需要的数据
综上：我们的请求参数中就需要携带 lastId：上一次查询的最小时间戳 和偏移量这两个参数。
这两个参数第一次会由前端来指定，以后的查询就根据后台结果作为条件，再次传递到后台。