diff --git a/README.md b/README.md index 7b52615..451cd90 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ 本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。 -## 分布式系统 +## [分布式系统](/docs/distributed-system/distributed-system-interview.md) ### 系统拆分 - 为什么要进行系统拆分？ diff --git a/docs/distributed-system/distributed-system-interview.md b/docs/distributed-system/distributed-system-interview.md new file mode 100644 index 0000000..6a63bb1 --- /dev/null +++ b/docs/distributed-system/distributed-system-interview.md @@ -0,0 +1,30 @@ +## 分布式系统面试连环炮 +有一些同学，之前呢主要是做传统行业，或者外包项目，一直是在那种小的公司，技术一直都搞的比较简单。他们有共同的一个问题，就是都没怎么搞过分布式系统，现在互联网公司，一般都是做分布式的系统，大家都不是做底层的分布式系统、分布式存储系统 hadoop hdfs、分布式计算系统 hadoop mapreduce / spark、分布式流式计算系统 storm。 + +分布式业务系统，就是把原来用 Java 开发的一个大块系统，给拆分成**多个子系统**，多个子系统之间互相调用，形成一个大系统的整体。假设原来你做了一个 OA 系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1 台机器部署。现在如果你把这个系统给拆开，权限系统、员工系统、请假系统、财务系统 4 个系统，4 个工程，分别在 4 台机器上部署。一个请求过来，完成这个请求，这个员工系统，调用权限系统，调用请假系统，调用财务系统，4 个系统分别完成了一部分的事情，最后 4 个系统都干完了以后，才认为是这个请求已经完成了。 + +![simple-distributed-system-oa](/img/simple-distributed-system-oa.png) + +> 这两年开始兴起和流行 Spring Cloud，刚流行，还没开始普及，目前普及的是 dubbo，因此这里也主要讲 dubbo。 + +面试官可能会问你以下问题。 +### 为什么要进行系统拆分？ +- 为什么要进行系统拆分？如何进行系统拆分？拆分后不用dubbo可以吗？dubbo和thrift有什么区别呢？ +### 分布式服务框架 +- 说一下的 dubbo 的工作原理？注册中心挂了可以继续通信吗？ +- dubbo 支持哪些序列化协议？说一下 hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？ +- dubbo 负载均衡策略和高可用策略都有哪些？动态代理策略呢？ +- dubbo 的 spi 思想是什么？ +- 如何基于 dubbo 进行服务治理、服务降级、失败重试以及超时重试？ +- 分布式服务接口的幂等性如何设计（比如不能重复扣款）？ +- 分布式服务接口请求的顺序性如何保证？ +- 如何自己设计一个类似 dubbo 的 rpc 框架？ + +### 分布式锁 +- 使用 redis 如何设计分布式锁？使用 zk 来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？ + +### 分布式事务 +- 分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？ + +### 分布式会话 +- 集群部署时的分布式 session 如何实现？ diff --git a/docs/high-concurrency/redis-production-environment.md b/docs/high-concurrency/redis-production-environment.md index 1cc2ba4..3048fd2 100644 --- a/docs/high-concurrency/redis-production-environment.md +++ b/docs/high-concurrency/redis-production-environment.md @@ -13,7 +13,7 @@ redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 5 台机器对外提供读写，一共有 50g 内存。 -因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务 +因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。 你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。 diff --git a/img/simple-distributed-system-oa.png b/img/simple-distributed-system-oa.png new file mode 100644 index 0000000..1b9f35b Binary files /dev/null and b/img/simple-distributed-system-oa.png differ