上海到北京机票/上海网站营销seo方案

注册用户如何防止缓存穿透？

先说明用户注册为什么会发送缓存穿透：用户注册时，需要验证用户名是否已存在，先查缓存，没有再查数据库，还没有才验证通过。高并发的情况下就可能有大量用户同时注册，或有恶意请求（因为注册是不设限的），造成缓存穿透。

常见的解决方案有哪些？

所以，在用户注册场景下，需要注意防止缓存穿透，常见的处理方式有下述这些：

1. 对不存在的 Key 进行缓存，值设为 Null，并设置短暂过期时间，如 60 秒。(用户注册时验证了用户名a和b,最后用的b，那60内a也不允许别的用户使用，造成用户体验不好，而且内存有限，高并发会让内存压力大)
2. 使用布隆过滤器，将所有已注册的用户名存入布隆过滤器，判断时先判断该用户名是否在布隆过滤器中，不在的一定不存在，避免直接查询数据库。（布隆的特性，只能添加，无法删除，注销的用户名也不能用）
3. 使用确定的数据结构如 Redis 的 Set 集合来存储已注册用户名，判断时检查是否在集合内。（占用内存较多且复杂度较高）
4. 针对高并发注册场景，可以先查询缓存，如果不命中则使用分布式锁来保证只有一个线程访问数据库，避免重复查询。（用户注册高峰期，只有一个线程访问数据库，这可能会导致大量用户的注册请求缓慢或超时。）

所以，从真实业务场景来看，上面这些解决方案都存在弊端，不能适用于真实场景。

最终方案：

在布隆过滤器后加一层缓存（Set)，用于缓存已经注销的用户名，当布隆过滤器查询有时，再查Set里有没有，有说明这是一个被注销的用户名，可以继续使用。（也有缺点，增加了查询性能消耗和内存消耗）

而且这种方案还有一种情况也让人头疼：

用户频繁申请账号再注销(每次用新用户名），可能导致用户注销可复用的 Username Redis Set 结构变得庞大，增加了存储和查询的负担。

遇到问题解决问题：

1. 异常行为限制：每次用户注销时，记录用户的证件号，并限制证件号仅可用于注销五次。超过这个限制的次数，将禁止该证件号再次用于注册账号。

2. 缓存分片处理：对 Username Redis Set 结构进行分片。即使我们对异常行为进行了限制，如果有大量用户注销账户，存储这些数据在一个 Redis Set 结构中可能成为一个灾难，可能出现 Redis 大 Key 问题。因此，我将 Set 结构进行分片，根据用户名的 HashCode 进行取模操作，将数据分散存储在 1024 个 Set 结构中，从而有效地解决了这个问题。