当前位置:   article > 正文

分布式八股文

分布式八股文

什么是分布式系统

  • 集中式系统,可以理解为将一整个系统的所有功能,包括数据库各种都部署在一起,统一向外提供服务。
  • 分布式就是将集中式系统拆分成多个系统,每一个系统单独对外提供服务,整一个提供一整套服务。
  • 意味着能够采用更多的服务器,CPU、内存、存储资源增加,能够应对更大的并发量。
  • 这里举例商城系统。各个模块部署在不同机器上,通过RPC(远程调用)等方式进行通信。
  • 与集群的区别:集群是相同应用或者相同模块。

CAP原则?

  • 一致性
    • 最终一致性:为了可用性,更加放大了一致性要求
    • 弱一致性:为了可用性,允许不同节点之间数据存在一定程度的不一致
    • 强一致性:任何时间点的读操作都返回上一次写操作的结果
    • 每次读取都能收到最新的写入数据或者错误信息
  • 可用性
    • 每个请求都能收到非错误的响应
  • 分区容错性
    • 尽管节点之间会丢弃或者延迟任意数量的消息,但系统仍然能够正常运行,AB集群中A宕机了也不影响B的运行
  • CAP之父的CAP理论就说了P是基本要求,CA权衡,因为比如写入一个数据的时候,为了保证一致性,写入过程是不可用的。

对应的有哪些模型?

  • 无P:基本没有
  • 无A:容许系统停机或者长时间无响应,Zookeeper,分布式数据库
  • 无C:要高可用,就需要放弃一致性。缓存,退而求其次保证最终一致性。12306买票的时候提示有票,下单就没有了。

BASE理论?

  • 对CAP理论的延申,核心思想即使无法做到强一致性,就采用合适的方式实现最终一致性。
  • Basically Available(基本可用):在分布式系统出现故障的时候,允许损失部分可用性(降级:默认返回、异步执行、延迟处理等方式),保证核心可用。
  • Soft State(软状态):允许不同节点间副本同步的延时,应状态就是要求很多数据副本都是一致的。
  • Eventually Consistent(最终一致性):所有数据副本经过一定事件后,最终能够达到一致的状态。

分布式锁?

  • 预想一下这把锁应该是怎样的?要是一把互斥锁、可重入的锁,最好是阻塞锁(看业务需求),能够获取和释放锁,同时效率要高。
  • MySQL:比如创建一张锁表,作唯一性约束,加锁添加数据,释放锁删除。
    • 缺点:
      • 锁没有失效时间,没有释放,就没办法访问了--启定时任务
      • 只能是非阻塞的--while死循环
      • 不可重入--判断线程信息
      • 数据库挂了,就进不去了--两个库,数据双向同步
      • 开销大
  • Zookeeper:用的少
  • Redis:
    • set resourceName value ex 5 nx 新命令
    • 怎么避免被其他客户端释放了:有finally,没拿到锁,但是finally执行这种,加上一些业务单号,线程ID这种判断。
    • 实现可重入锁:和Reentrantlock差不多,实现Lock,加上个守护线程(主要就是为MAP里的续期,不依赖于具体的线程,负责这台机器上的所有锁),然后定时任务TimeTask过期时间/3去续期,主要是从一个MAP里面获取KV对,有才续期,不够了就Lua续期。<0的时间不续期。unlock就remove了MAP里的KV对。
    • 会不会宕机死锁:Redisson是基于Netty的时间轮,都是在JVM上的,所以重启后续期任务也没有了。
    • 单点故障:RedLock--引入多个节点解决问题,半数选举,但是也有问题网络延迟时钟漂移࿰
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/538029
推荐阅读
相关标签
  

闽ICP备14008679号