yuanmomoya的博客

但随着业务规模扩大，系统逐步转向分布式架构，传统的单机锁（如JUC锁）就显得不足，因为数据往往分布在多个节点上。但这种方案存在风险：如果在加锁后节点突然宕机，锁无法释放，导致后续其它节点无法加锁，形成死锁。如果在主节点成功加锁后，由于故障或宕机导致数据尚未同步到从节点，那么其他节点可能无法正确感知锁的状态，从而引发锁失效和并发安全问题。另外，如果业务处理时间超过锁的过期时间，锁会被提前释放，从而产生并发问题。因此，除了加锁和解锁的原子性，还需要在业务执行过程中对锁进行续期，确保业务完成前锁不会失效。

可以帮助我们同时锁定多个关键资源，只有所有子锁都成功后才执行后续操作，保证数据一致性。建议调用加锁方法前，根据实际情况设置合适的等待时间和租约时间，充分利用看门狗机制防止锁误释放；释放锁时最好判断当前线程是否持有该锁，以避免误解锁导致异常；应用场景：适用于分布式订单处理、跨服务协同操作和复杂事务控制等需要同时操作多个资源的场景。

/ 窗口大小（默认：60秒） long threshold() default 3;// 阈值（默认：3次） }// 窗口大小（默认：60秒） long threshold() default 3;// 阈值（默认：3次） }// 窗口大小（默认：60秒）// 阈值（默认：3次）通过Redis有序集合和Lua脚本，我们实现了一个高效且灵活的滑动窗口限流算法。结合AOP，我们可以轻松地将限流策略应用到具体的业务方法中。对于更复杂的流量控制需求，可以参考阿里巴巴的Sentinel框架。

如果是大字符串，可以考虑将其拆分成多个小字符串存储。比如将一个很长的 JSON 字符串拆分成多个小的 JSON 片段分别存储。对于大哈希，可以将其属性拆分成多个小哈希存储。比如一个包含大量字段的哈希表，可以根据字段的某种特征进行拆分。对于大列表，可以将其拆分成多个小列表存储。比如一个有大量元素的列表，可以根据一定规则拆分成多个子列表。通过以上拆分方案，可以有效地避免 Redis 中的大 key 问题，提高系统的性能和稳定性。

缓存穿透是指查询一个一定不存在的数据，由于缓存中没有命中，会去数据库中查询，而数据库中也没有该数据，并且每次查询都不会命中缓存，从而每次请求都直接打到了数据库上，这会给数据库带来巨大压力。布隆过滤器（Bloom Filter）是一种空间效率很高的随机数据结构，它利用多个不同的哈希函数将一个元素映射到一个位数组中的多个位置，并将这些位置的值置为 1。如果有任何一个位置上的值为 0，那么这个元素一定不存在。布隆过滤器存在一定的误判概率，即可能会把不存在的元素判断为存在，但不会把存在的元素判断为不存在。

名词解释大Key通常以Key的大小和Key中成员的数量来综合判定，例如：Key本身的数据量过大：一个String类型的Key，它的值为5 MB。Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个。Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有2,000个但这些成员的Value（值）总大小为100 MB。

打开redis的配置文件################################## SECURITY #################################### Require clients to issue AUTH <PASSWORD> before processing any other# commands.  This might be ...