From d8a522590ccf98f773c089212a613a8ce4ba5758 Mon Sep 17 00:00:00 2001 From: wangjunwei87 <1625837+wangjunwei87@users.noreply.github.com> Date: Wed, 16 Jan 2019 18:39:52 +0800 Subject: [PATCH] doc: fix typo in README of Sentinel Dubbo Demo (#425) --- sentinel-demo/sentinel-demo-dubbo/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sentinel-demo/sentinel-demo-dubbo/README.md b/sentinel-demo/sentinel-demo-dubbo/README.md index 2a9fc3ea..84b3414f 100644 --- a/sentinel-demo/sentinel-demo-dubbo/README.md +++ b/sentinel-demo/sentinel-demo-dubbo/README.md @@ -58,11 +58,11 @@ Demo 1 演示了此限流场景，我们看一下这种模式的限流产生的 ## Service Consumer -> 对服务提供方的流量控制可分为**控制并发线程数**和**服务降级**两个维度。 +> 对服务消费方的流量控制可分为**控制并发线程数**和**服务降级**两个维度。 ### 并发线程数限流 -Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求 服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置**线程数模式**的限流，来保证自身不被不稳定服务所影响。限流粒度同样可以是服务接口和服务方法两种粒度。 +Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置**线程数模式**的限流，来保证自身不被不稳定服务所影响。限流粒度同样可以是服务接口和服务方法两种粒度。 采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel 会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成。