From 0233b5868a0b318758a22b42080ca06607da65ca Mon Sep 17 00:00:00 2001 From: yanglbme Date: Mon, 1 Apr 2019 21:57:16 +0800 Subject: [PATCH] docs: format docs in dubbo --- docs/distributed-system/distributed-system-idempotency.md | 2 +- docs/distributed-system/dubbo-operating-principle.md | 2 +- docs/distributed-system/dubbo-service-management.md | 7 +------ docs/distributed-system/dubbo-spi.md | 2 +- docs/high-concurrency/redis-single-thread-model.md | 1 + docs/high-concurrency/why-cache.md | 2 +- 6 files changed, 6 insertions(+), 10 deletions(-) diff --git a/docs/distributed-system/distributed-system-idempotency.md b/docs/distributed-system/distributed-system-idempotency.md index 0696d45..ca576e4 100644 --- a/docs/distributed-system/distributed-system-idempotency.md +++ b/docs/distributed-system/distributed-system-idempotency.md @@ -6,7 +6,7 @@ 一个分布式系统中的某个接口，该如何保证幂等性？这个事儿其实是你做分布式系统的时候必须要考虑的一个生产环境的技术问题。啥意思呢？ -你看，假如你有个服务提供一个接口，结果这服务部署在了 5 台机器上，接着有个接口就是**付款接口**。然后人家用户在前端上操作的时候，不知道为啥，总之就是一个订单**不小心发起了两次支付请求**，然后这俩请求分散在了这个服务部署的不同的机器上，好了，结果一个订单扣款扣两次。 +你看，假如你有个服务提供一些接口供外部调用，这个服务部署在了 5 台机器上，接着有个接口就是**付款接口**。然后人家用户在前端上操作的时候，不知道为啥，总之就是一个订单**不小心发起了两次支付请求**，然后这俩请求分散在了这个服务部署的不同的机器上，好了，结果一个订单扣款扣两次。 或者是订单系统调用支付系统进行支付，结果不小心因为**网络超时**了，然后订单系统走了前面我们看到的那个重试机制，咔嚓给你重试了一把，好，支付系统收到一个支付请求两次，而且因为负载均衡算法落在了不同的机器上，尴尬了。。。 diff --git a/docs/distributed-system/dubbo-operating-principle.md b/docs/distributed-system/dubbo-operating-principle.md index ad152df..2a06d73 100644 --- a/docs/distributed-system/dubbo-operating-principle.md +++ b/docs/distributed-system/dubbo-operating-principle.md @@ -2,7 +2,7 @@ 说一下的 dubbo 的工作原理？注册中心挂了可以继续通信吗？说说一次 rpc 请求的流程？ ## 面试官心理分析 -MQ、ES、Redis、Dubbo，上来先问你一些思考的问题，原理（kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理），生产环境里可能会碰到的一些问题（每种技术引入之后生产环境都可能会碰到一些问题），系统设计（设计 MQ，设计搜索引擎，设计一个缓存，设计 rpc 框架） +MQ、ES、Redis、Dubbo，上来先问你一些**思考性的问题**、**原理**，比如 kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理；之后就是生产环境里可能会碰到的一些问题，因为每种技术引入之后生产环境都可能会碰到一些问题；再来点综合的，就是系统设计，比如让你设计一个 MQ、设计一个搜索引擎、设计一个缓存、设计一个 rpc 框架等等。 那既然开始聊分布式系统了，自然重点先聊聊 dubbo 了，毕竟 dubbo 是目前事实上大部分公司的分布式系统的 rpc 框架标准，基于 dubbo 也可以构建一整套的微服务架构。但是需要自己大量开发。 diff --git a/docs/distributed-system/dubbo-service-management.md b/docs/distributed-system/dubbo-service-management.md index 68e5dd7..b1561d5 100644 --- a/docs/distributed-system/dubbo-service-management.md +++ b/docs/distributed-system/dubbo-service-management.md @@ -8,7 +8,7 @@ **失败重试**，分布式系统中网络请求如此频繁，要是因为网络问题不小心失败了一次，是不是要重试？ -**超时重试**，同上，如果不小心网络慢一点，超时了，如何重试？ +**超时重试**，跟上面一样，如果不小心网络慢一点，超时了，如何重试？ ## 面试题剖析 ### 服务治理 @@ -40,17 +40,13 @@ ```java public interface HelloService { - void sayHello(); - } public class HelloServiceImpl implements HelloService { - public void sayHello() { System.out.println("hello world......"); } - } ``` @@ -91,7 +87,6 @@ public class HelloServiceImpl implements HelloService { mock 的值也可以修改为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口名称+`Mock`” 后缀。然后在 Mock 类里实现自己的降级逻辑。 ```java public class HelloServiceMock implements HelloService { - public void sayHello() { // 降级逻辑 } diff --git a/docs/distributed-system/dubbo-spi.md b/docs/distributed-system/dubbo-spi.md index a072a30..bce20b0 100644 --- a/docs/distributed-system/dubbo-spi.md +++ b/docs/distributed-system/dubbo-spi.md @@ -12,7 +12,7 @@ spi，简单来说，就是 `service provider interface`，说白了是什么意 举个栗子。 -你有一个接口A。A1/A2/A3 分别是接口A的不同实现。你通过配置 `接口A=实现A2`，那么在系统实际运行的时候，会加载你的配置，用实现A2实例化一个对象来提供服务。 +你有一个接口 A。A1/A2/A3 分别是接口A的不同实现。你通过配置 `接口 A = 实现 A2`，那么在系统实际运行的时候，会加载你的配置，用实现 A2 实例化一个对象来提供服务。 spi 机制一般用在哪儿？**插件扩展的场景**，比如说你开发了一个给别人使用的开源框架，如果你想让别人自己写个插件，插到你的开源框架里面，从而扩展某个功能，这个时候 spi 思想就用上了。 diff --git a/docs/high-concurrency/redis-single-thread-model.md b/docs/high-concurrency/redis-single-thread-model.md index 71e8edb..c272c61 100644 --- a/docs/high-concurrency/redis-single-thread-model.md +++ b/docs/high-concurrency/redis-single-thread-model.md @@ -23,6 +23,7 @@ redis 相比 memcached 来说，拥有[更多的数据结构](/docs/high-concurr redis 内部使用文件事件处理器 `file event handler`，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。 文件事件处理器的结构包含 4 个部分： + - 多个 socket - IO 多路复用程序 - 文件事件分派器 diff --git a/docs/high-concurrency/why-cache.md b/docs/high-concurrency/why-cache.md index c31356a..dccd71f 100644 --- a/docs/high-concurrency/why-cache.md +++ b/docs/high-concurrency/why-cache.md @@ -36,4 +36,4 @@ mysql 这么重的数据库，压根儿设计不是让你玩儿高并发的， - [缓存雪崩、缓存穿透](/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md) - [缓存并发竞争](/docs/high-concurrency/redis-cas.md) -后面再详细说明。 +后面再详细说明。 \ No newline at end of file