一致性hash和普通hash区别
这个当时没答出来,也是醉了,重点是,当时问的是redis啊…redis明明是哈希槽,我就跑偏到一致性哈希…
再谈谈哈希分区规则
规则有三种, 节点取余,一致性哈希,虚拟槽三种;
- 节点取余: 特定数据,公式hash(key)%N 计算,得值映射节点 这种的缺点就是,如果需要扩容或者收缩的话,可能会导致数据全量迁移.
- 一致性hash: 每个节点分配token,构成哈希环,操作时,先根据key计算hash值,然后顺时针得到第一个>=token节点 这种缺点是: 加减节点时,会造成部分数据无法命中;所以每次都需要增加或减少一倍节点才能保证数据负载均衡.
- 虚拟槽: 把所有数据映射到一个固定范围集合中,每个节点复制一部分的槽以及槽所映射的键值数据.
再来讲:一致性hash和普通hash区别吧
一致性hash 关键是虚拟节点,宕机的话,也只是部分丢失,部分无法命中;
如果是普通hash的话,一台宕机,就全部失效了.
springboot中 有一个start jar. 这个和你普通pom引的jar有什么区别?
网上搜的, 说这个starter主要是用来简化依赖用的, 比如我们需要引入日志组件,需要去找log4j的版本,然后引入. 那么现在有了starter后,直接用这个,log4j 就自动引入了,不需要关心版本这些问题了.
spring 循环依赖问题
代码maybe是这样的
<bean id="beanA" class="xyz.coolblog.BeanA">
<property name="beanB" ref="beanB"/>
</bean>
<bean id="beanB" class="xyz.coolblog.BeanB">
<property name="beanA" ref="beanA"/>
</bean>
只是在单例作用域下解决循环依赖的.通过实例化Bean的时候, 先把Bean通过一个工厂ObejctFactory暴露这个bean,然后再次获取bean时,可以通过这个工厂类获取循环依赖的这个bean(这里需要再跟一下源码, 等我跟了,看看是不是可以单独写一篇博客)
zk脑裂
之前就是看过一篇文章,没咋注意过, 突然问到,就回忆了一下, 这个时候,就深刻体会到, 你学过的东西,都在大脑里, 只不过有些东西,需要引出来而已. 我答了两点,一个是设置时间, 一个是自我释放. 就又回去查了查,
slaver切换时候,不再是检查到老的master出现问题后就马上切换,而是先休眠一段足够时间,确保老的master已经获知变更并且做了相关的shutdown清理工作,然后再主从成为master就能避免这类问题了.
预防措施: 1.增加冗余心跳线,启用磁盘锁,正在服务一方锁住共享磁盘,“脑裂"发生时,让对方完全"抢不走"磁盘资源,但使用磁盘锁也会有一个问题,就是如果占用磁盘锁的一方不主动"解锁”,另一方就永远得不到共享磁盘.于是有人在HA设计中,设计了"智能"锁,即正在服务的一方只在发现心跳线全部断开时才启用磁盘锁,平时不上锁.
2.仲裁机制, 我理解的是: 各自去ping参考的ip. ping不通,就自我重启;
多线程死锁
这个倒是答了,但是都在问,就整理出来吧.
发生死锁原因: 一般就是两个对象的锁互相等待造成的.
那么什么情况会发生死锁?
1.系统资源不足;
2.多线程访问共享资源,访问顺序不当
3.资源分配不当
形成场景
eg:A线程有锁1, B线程有锁2,现在A想要锁2. B想要锁1. 都在等对方释放,那么就是死锁了
如何避免:
1.加锁顺序(线程按一定顺序加锁)
2.加锁时限(线程尝试获取锁的时候加上一定的时限, 超过时限则放弃对该锁的请求,并释放自己占有的锁)
3.死锁检测
解释一下3 吧. 每当一个线程获得锁,就把线程还有这个锁的相关数据结构, 记录下来. 然后每当有线程请求锁,就记录到这个数据结构中
当一个线程请求锁失败,它可以直接遍历锁的关系图,看看是不是有死锁发生.比如: 线程A等待线程B,线程B等待线程C,线程C又在等线程A. 线程A检测死锁,就得递进地检测所有被B请求的锁. 它先找到B,再找C,在C里面,发现请求锁被自己持有者呢, 就能知道是发生死锁了.
未完待续
谁虐的我,我都记着呢,回头有机会请你们这些帮助我快速成长的人吃大餐~~~谢谢你们!
也总有一天, 变成平等的交流, 思维的碰撞!等我成长