面试题各个击破---系统设计

发布于 / 随记 / 0条评论 / Tags: 面试 / 30 次浏览

1.什么是Consistent Hashing

  • 一致性hash,使用hash(job)生成2的32次方的int，然后落到最近的hash环，计算机会虚拟出来几个vnode，均匀分布到hash环。

2.分布式architeture---空间---时间解偶（如邮件，两个人发送邮件不需要同时在发送接收，如qq的发送文件就需要点接收），三层OSI7层
3.p2p ，dns---非结构够点对点。cdn--cs+p2p
3.中间件----所有application的general通用部分，可以用于解决遗留系统问题---如拦截器interceptor

  1. client ----switch 然后直接和server交流，---称之为tcp hand off
    5.上下文切换，包括---cpu上下文，线程上下文，进程上下文
  2. out of bind communication ，超界呼叫，有点类似cpu的中断，提供专门的端口来紧急处理紧急的事情。
  3. 代码管理code migration
  4. cs模式，client server，代码状态和代码文件都在服务端
  5. REV
  6. CoD
  7. MA
    8.系统资源管理的3中方式---by identifier,by value ,by type
    9.osi七层--概括
  8. 硬件层----》物理层（bit级别的交换）---数据链路层（建立帧frame级别的传输，错误和flow控制）
  9. 软件层----》网络层（包packet的路由，注意好多分布式系统把这个作为最低层）----传输层（分布式系统的交流基础设施，TCP，UDP，IP广播）

  10. 事务层----》Session会话，如：两阶段提交----（和表示层合成---中间件middleware层）
    ++ midleware layer---提供了common的协议protocol和服务services ，给many应用applications使用
    +++ 提供---

    ++++a set ofcommunication protocols,
++++(un)marshaling of datafor integerated systems
++++security protocols
++++naming protocols----easy sharing resources如zookeeper 使用文件路径来命令services
++++scaling mechanisms,like replication and cashing.
  11. 表示层----》表示层-----RPC调用，使用相同的格式，client server 用同一种语言说话，如json xml
  12. 应用层
    ---------------------------------------系统交流communication---------------------
    10.系统交流类型 communication types，使用中间件，如kafka
  13. 同步，发送请求，等待返回
  14. 异步，发送请求，等待回调(利用transmision interrupt传输中断）
    -----以上是双向交流，下面是单向交流
  15. 只管发送，不等返回和回调。如UDP
    11.RPC远程过程调用，
  16. 需要解决调用远程交流透明性,PC是一种机制，可以隐藏caller和callee的communication
  17. 需要解决消息传递marshaling,machine independent，client server agree on same encoding
  18. 需要关注传参问题，a.传递指针(指向一个global data）还是value，b.还有一种方式copy in /out 没有副作用
    12.socket
  19. socket 创建一个端点endpoint
  20. bind 附加一个本地地址给socket
  21. listen 告诉系统需要足够的buffer来接收客户端请求
  22. accept 等待一个连接
  23. connect 客户端发起三次握手，和accept对应
  24. send/receive ---当作文件操作
  25. close
    13.中间件---queue （对比socket，时间解偶异步化）
  26. 异步持久化交流
  27. PUT append 一个message到指定队列
  28. GET 线程阻塞，一直等到队列非空，获取并删除地一个message
  29. POLL 检查队列，删除第一个msg，但是不阻塞
  30. NOTIFY 加装一个处理器handler，当消息被PUT时调用。
    14.消息代理 message broker ----对比queue，空间的解偶，不再是点到点，而是全部发送给broker，相当与中间商
  • 消息队列假定一个通用协议protocal，message broker是一个中心化组件，允许异构系统在同一个消息系统中。
  • 转化消息到固定的目标格式 target format
  • 经常充当application gateway的角色
  • 用topic进行路由
  • 一般用来拯救遗留系统application的交流
  1. 面向流Stream的交流
  2. 之前讨论的交流是一种非连续的，即时间无关的time-independent信息交流（exchange)，而流是一种时间有关的time dependent，如连续媒体continous media---audio video animations ,那么Stream就是一个面向连接的设施---支持等时数据传输isochronous data transmission，如视频，音乐audio
  3. 流一般是不定向的undirectional
  4. 一般是一个源source 流向多个槽 sinks
  5. 广播
    ------------------------------------------Naming命名--------------------------
  6. 分布式需要命名一个计算机或者其他端点进行访问，如dns，如一些注册中心，feign访问服务也是通过application name访问
  7. naming
  8. identifier ---无意义的符号，随机字符,一对一，如身份证号
  9. flat naming ,如arp使用的名字,DHT---一致性hash，fingers tables，hirecal location service 层次化
  10. 上面都是非结构化的，那么不适合人类阅读，结构化的，如name space（java程序员应该很熟悉）
  11. 基于attribute的命名---如ldap
    ------------------------同步 sychronisation-------------------
    物理时钟----网络时钟
    逻辑时钟---happens before ---并行
    ------------------------consistency & replication
  12. 复制的原因----可靠性和性能
  13. 操作冲突----读和写
  14. 操作冲突----写和写
  15. 全局顺序保证的操作冲突，成本会很高，我们采取稍微弱点的一致性要求

--------------------- 宽松的一致性模型------数据中心--------------------

  1. 数据中心一致性模型
  2. 基本模型约定----读操作读的值一定是最后一次写操作的值，但是在没有全局时钟的情况下，怎么确定哪一次写是最后一次写是个难题，所以催生了多种一致性模型。
  3. 持续一致性continous consistency
  4. Yu and Vahdat (2002) 提出的度量不一致性的三个坐标轴：
  5. 副本之间值偏差--numeric value differ between replicas,如：同一支股票的值差不能超过0.02美元
  6. 副本之间的新旧程度偏差----relative staleness differ,如天气预报允许时间上的偏差
  7. 副本之间更新顺序的偏差，ordering of update operations,可以用向量时钟保证vector clock
  8. 顺序一致性sequential consistency
  9. 所有process的计算结果都是一致的，如果他们的操作顺序都是按一个顺序（Program指定）来的
    6.因果一致性 causal consistency
  10. lamport提出的，如果一个操作B是由另一个操作A引起的，那么我们应当保证他们的顺序性。如通过logic clock
  11. 分组操作---如java的sychronized 把一组操作分组加锁,又如innodb的按行锁，其他操作可以不一致（顺序），但是这个同一行必须一致，还有redis对同一个key的写。

--------------------- 宽松的一致性模型------client中心一致性模型--------------------

我们讨论这个基于这种系统-----很少发生同时更新同一个数据，或者发生了也很好解决。
  • 最终一致性eventualy consitency,现代好多数据库系统中，大部分进程是读操作，很少部分有写的操作。如DNS，只有供应商可以更改，所以不会有写写冲突，只会有读写冲突，这种允许懒惰传播，即更改一段时间后，用户才看到变化。即在一段时间内，允许副本有不一致性。
  • 单调读 ----
  • 单调写 monotoic
  • read your writes
  • write follow read
    --------------------- 宽松的一致性模型------replica(集群） 管理--------------------
  • 副本放置
    ----------------------------------异地多活-------------------------
    http://afghl.github.io/2018/02/11/distributed-system-multi-datacenter-1.html

、

    评论区(暂无评论)