zyxpython的博客

1. 死循环2. juc并发编程 cas锁(乐观锁)3. 阿里云服务器上安装Redis可能会被别人注入挖矿程序4. 服务器被ddos （流量，默认请求攻击），导致cpu飙高解决：1.死循环突出死循环2. 加上sleep，且控制一下循环的次数不再飙高：3. 最好端口号不要通过外部访问，别人可以扫描到，可能会钻redis漏洞;4. 给接口做限流，限流、ip 黑名单、图形验证码防止机器模拟攻击;我们的线程是运行在 cpu 上面。

延迟过期，比如延长过期时间=50s+，倒计时5s过期的时候，提前去检查线程，里面的业务逻辑代码是否执行完毕，没执行完毕就会将过期key时间延长。一直不断实现续命的情况下，也会发生死锁的问题.设定续命的次数，续命多次如果还是没有执行完业务逻辑的情况下，就应该回滚业务、主动释放锁。获取锁成功之后，应该提前开启一个续命的线程，检测如果当前业务逻辑还没有执行完毕的情况下，应该不断的延迟过期 key 的时间。续命:开启一个定时任务实现续命，当我们业务逻辑没有执行完毕的时候，就应该延长过期 key 的时间。

Setnx key valueA.猥老A -u 6435Redis Setnx (SETif Not eXists) 命令在指定的 key 不存在时，为 key 设置指定的值。Redis Setnx (SETif Not eXists) 命令在指定的 key 不存在时，为 key 设置指定的值设置成功，返回 1。该锁被释放(key 被删除)，没有获取到锁的 vm 从新进入到获取锁的状态。多个不同的 jvm，同时在 Redis 中写入一条 setnx 相同的 key 谁能够写入成功，谁就可以获取到锁。

当 jvm 释放锁的时候，会唤醒正在等待的 jvm 从新进入到获取锁的状态。如果正在阻塞的等待获取锁的 jvm，如果有几十个或者几百个、上千个的情况下ZkServer 端唤醒所有正在等待的 jvm，从新进入到获取锁的状态，唤醒的成本是非常高有可能会造成我们 ZkServer 端阻塞。2. 基于临时顺序编号节点实现 多个 jvm 同时创建一个临时顺序编号节点,如果当前 jvm 创建的临时顺序编号节点是最小的情况下，则表示获取说成功643如果不是最小的情况下，则表示获取锁失败，就会进入到阻塞状态;

定时任务，秒杀，流量控制1.定时任务：一般不会使用分布式锁2.秒杀抢购：防止库存超卖的问题3.双写一致性：更新db，更新reddis。