分布式锁相关

1.redis中的红锁

写这个主要原因，redis实现分布式锁有个问题，那么就是重复枷锁的问题，也就是如果主节点宕机，但是锁没有更新到从节点，就会造成重复枷锁的情况。而红锁就可以解决这个情况。当然上面还有个问题，就是锁丢失，因为锁丢失造成的可能出现重复枷锁。
红锁执行过程:
一个客户端需要做如下操作来获取锁：

• 1、获取当前时间（单位是毫秒）。
• 2、轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。
• 3、客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。
• 4、如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。
• 5、如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。
  有几个细节：
• 首先为什么要有个随机值？
  1.解决锁重入。因为可能多个client枷锁，那么可能打到不同的reids节点，每个节点只能响应同一个key和随机值的。对于另一个key和随机值的不响应，我感觉随机值就是来标识一下，相当于client的唯一标识。用于锁重入。
  2.为了防止锁被其他客户端删除。有这么一种情况：
  客户端 A 获得了锁，还没有执行结束，但是锁超时自动释放了；
  客户端 B 此时过来，是可以获得锁的，加锁成功；
  此时，客户端 A 执行结束了，要去释放锁，如果不对比随机值，就会把客户端 B 的锁给释放了。
• 为什么请求锁的时间要小于锁超时时间？
  这个主要是提高可用性，防止某个节点宕机，阻塞时间比较长。

感觉红锁并不需要一致性，只不过用到了相关的内容，因为她不需要去所有节点同步锁，因为，只要保证一半以上有就行了。当然我估计她有也去同步了，因为只要保证一半都有，就可以保证锁成功。但是问题又来了，脑裂问题。。。这个好像还是需要一致性，害 算了 感觉有点 懵。

https://www.cnblogs.com/kevingrace/p/12433503.html

• 补充：zookeeper解决脑裂问题是通过的过半选举，不过半的不会选出leader，所以不存在脑裂问题。
• 过半机制作用：可以快速选举，不用等所有的都反馈，而且提高可用性。那么为什么不能大于等于？可以防止脑裂，因为3,3的时候不会出现脑裂，而等于的时候会出现脑裂。还有就是如果不超过半数，那么岂不是会选出俩领导人，也算脑裂。。

redis的一致性算法

首先要知道一致性hash算法，以及hash偏斜的概念https://zhuanlan.zhihu.com/p/179266232

redis没有采用一致性hash，而是采用的hash曹
一个 redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽。

reids的保证缓存和数据库一致性的算法

https://blog.csdn.net/huizhi2533/article/details/107021249/
延时双删
如果只有 先删除，那么1线程删除，修改数据库，二线程在修改数据库之前读取旧数据更新缓存，缓存就一直是旧数据了。
如果只后删除，那么1更新数据库，然后到删除缓存之前，2线程一直度的旧数据，还有就是后面如果不严实，那么可能在删除缓存之后，2又去用老数据更新缓存。
**为什么延时？**依然是反证法。下图这情况是双删依然存在旧缓存的情况，延时是确保 修改数据库-》清空缓存前，其他事务的更改缓存操作已经执行完。

String为什么加了final

final加final，表示final不能被继承，也就是String对象指的一定是