docs: fix typo in hystrix-thread-pool-current-limiting

docs/high-availability/hystrix-thread-pool-current-limiting.md

@@ -42,16 +42,16 @@ Hystrix 对每个外部依赖用一个单独的线程池，这样的话，如果
 
 ### 线程池机制的缺点
 - 线程池机制最大的缺点就是增加了 CPU 的开销。<br>
-除了 tomcat 本身的调用线程之外，还有 hystrix 自己管理的线程池。
+除了 tomcat 本身的调用线程之外，还有 Hystrix 自己管理的线程池。
 
 - 每个 command 的执行都依托一个独立的线程，会进行排队，调度，还有上下文切换。
-- Hystrix 官方自己做了一个多线程异步带来的额外开销，通过对比多线程异步调用+同步调用得出，Netflix API 每天通过 Hystrix 执行 10 亿次调用，每个服务实例有 40 个以上的线程池，每个线程池有 10 个左右的线程。）最后发现说，用 Hystrix 的额外开销，就是给请求带来了 3ms 左右的延时，最多延时在 10ms 以内，相比于可用性和稳定性的提升，这是可以接受的。
+- Hystrix 官方自己做了一个多线程异步带来的额外开销统计，通过对比多线程异步调用+同步调用得出，Netflix API 每天通过 Hystrix 执行 10 亿次调用，每个服务实例有 40 个以上的线程池，每个线程池有 10 个左右的线程。）最后发现说，用 Hystrix 的额外开销，就是给请求带来了 3ms 左右的延时，最多延时在 10ms 以内，相比于可用性和稳定性的提升，这是可以接受的。
 
 我们可以用 Hystrix semaphore 技术来实现对某个依赖服务的并发访问量的限制，而不是通过线程池/队列的大小来限制流量。
 
-sempahore 技术可以用来限流和削峰，但是不能用来对调研延迟的服务进行 timeout 和隔离。
+semaphore 技术可以用来限流和削峰，但是不能用来对调研延迟的服务进行 timeout 和隔离。
 
-`execution.isolation.strategy` 设置为 `SEMAPHORE`，那么 Hystrix 就会用 semaphore 机制来替代线程池机制，来对依赖服务的访问进行限流。如果通过 semaphore 调用的时候，底层的网络调用延迟很严重，那么是无法 timeout 的，只能一直 block 住。一旦请求数量超过了 semephore 限定的数量之后，就会立即开启限流。
+`execution.isolation.strategy` 设置为 `SEMAPHORE`，那么 Hystrix 就会用 semaphore 机制来替代线程池机制，来对依赖服务的访问进行限流。如果通过 semaphore 调用的时候，底层的网络调用延迟很严重，那么是无法 timeout 的，只能一直 block 住。一旦请求数量超过了 semaphore 限定的数量之后，就会立即开启限流。
 
 ### 接口限流 Demo
 假设一个线程池大小为 8，等待队列的大小为 10。timeout 时长我们设置长一些，20s。