chore: build site with vitepress

docs/high-availability/hystrix-fallback.md

@@ -1,4 +1,4 @@
-## 基于本地缓存的 fallback 降级机制
+# 基于本地缓存的 fallback 降级机制
 
 Hystrix 出现以下四种情况，都会去调用 fallback 降级机制：
 
@@ -7,7 +7,7 @@ Hystrix 出现以下四种情况，都会去调用 fallback 降级机制：
 -   Hystrix 调用各种接口，或者访问外部依赖，比如 MySQL、Redis、Zookeeper、Kafka 等等，出现了任何异常的情况。
 -   访问外部依赖的时候，访问时间过长，报了 TimeoutException 异常。
 
-### 两种最经典的降级机制
+## 两种最经典的降级机制
 
 -   纯内存数据<br>
     在降级逻辑中，你可以在内存中维护一个 ehcache，作为一个纯内存的基于 LRU 自动清理的缓存，让数据放在缓存内。如果说外部依赖有异常，fallback 这里直接尝试从 ehcache 中获取数据。
@@ -23,7 +23,7 @@ Hystrix 出现以下四种情况，都会去调用 fallback 降级机制：
 
 假如说，品牌服务接口挂掉了，那么我们可以尝试从本地内存中，获取一份稍过期的数据，先凑合着用。
 
-### 步骤一：本地缓存获取数据
+## 步骤一：本地缓存获取数据
 
 本地获取品牌名称的代码大致如下。
 
@@ -51,7 +51,7 @@ public class BrandCache {
     }
 ```
 
-### 步骤二：实现 GetBrandNameCommand
+## 步骤二：实现 GetBrandNameCommand
 
 在 GetBrandNameCommand 中，run() 方法的正常逻辑是去调用品牌服务的接口获取到品牌名称，如果调用失败，报错了，那么就会去调用 fallback 降级机制。
 
@@ -95,7 +95,7 @@ public class GetBrandNameCommand extends HystrixCommand<String> {
 
 `FallbackIsolationSemaphoreMaxConcurrentRequests` 用于设置 fallback 最大允许的并发请求量，默认值是 10，是通过 semaphore 信号量的机制去限流的。如果超出了这个最大值，那么直接 reject。
 
-### 步骤三：CacheController 调用接口
+## 步骤三：CacheController 调用接口
 
 在 CacheController 中，我们通过 productInfo 获取 brandId，然后创建 GetBrandNameCommand 并执行，去尝试获取 brandName。这里执行会报错，因为我们在 run() 方法中直接抛出异常，Hystrix 就会去调用 getFallback() 方法走降级逻辑。