微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

微服务保护

34 规则持久化

34.1 规则管理模式

之前我们已经大致熟络了sentinel 的常用玩儿法，但是在使用过程中，其实有一个问题，每当服务重启，之前所配置的各种各样的规则就丢失了

【原因】sentinel 会默认将这些规则保存在内存里，服务一重启，自然就丢失了

34.1.1 规则管理模式

Sentinel的控制台规则管理有三种模式：

推送模式	说明	优点	缺点
原始模式	API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource），默认就是这种 【sentinel 的默认模式，将规则保存在内存，重启服务会丢失】	简单，无任何依赖	不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境
Pull 模式	扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等	简单，无任何依赖；规则持久化	不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式	扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。	规则持久化；一致性；	引入第三方依赖

34.1.2 规则管理模式 - 原始模式

原始模式：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。

然后保存在内存中，服务重启则丢失

34.1.3 规则管理模式 - pull 模式

pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。

以后会定时去本地文件或数据库中查询，更新本地规则。

当监听到数据库的文件、内容发生变化时，就去更新规则缓存【规则时效性问题 → 数据不一致问题】【所以这种方案也不是很推荐】

34.1.4 规则管理模式 - push 模式

push模式：控制台将配置规则推送到远程配置中心，例如Nacos。

Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

34.1.5 总结

Sentinel的三种配置管理模式是什么？

• 原始模式：保存在内存
• pull模式：保存在本地文件或数据库，定时去读取
• push模式：保存在nacos，监听变更实时更新