隔离
本质上是对系统和资源进行分割，从而实现当系统故障时能限定传播范围和影响范围，即发生故障后只有出问题的服务不可用，保证其他服务仍然可用。
服务隔离
动静隔离
mysql 表中的bufferpool 频繁过期，隔离动静表。如 稿件的基本信息，作者、封面等和稿件的播放、点赞 频繁变化的数据进行的隔离。
cdn 的静态资源和动态资源的隔离。动态api的时候还讲了一个case 如边缘计算，qps高的时候可以在边缘节点加一个小程序进行压缩汇总，pipeline 打包发送到真正的处理地址，这个可以降低qps 节省服务器。
读写分离
cqrs command 和 query 进行分离，也就是写请求和读请求进行分离。比如 审核服务，审核是一个比较重的业务逻辑，也有多道程序，审核的逻辑和稿件的展示底层存储可以分离。审核的程序完成之后，对应稿件的存储层才可以进行展示，将关注点进行分离。
轻重隔离
业务按照 Level 进行资源池的划分(L0、L1、L2)
这里想起来之前做广告服务的时候，收集广告、点击的服务之前是一个接口通过不同参数进行区分，而且是写入同一张表，qps比较大的时候，处理不过来会丢失部分点击数据，点击数据需要回掉给广告主，所以是比较重要的请求，后续将 底层表 点击、曝光进行拆分，将接口也进行拆分，因为点击qps比较少，处理明显提高，隔离开之后，不会受曝光qps的增加影响核心点击数据的写入。
快慢隔离
将不同业务维度进行隔离，防止某些业务出现问题，影响整体不可用。
热点隔离
小表广播：从remote cache 提升为 local cache,定时更新local cache.
主动预热：统计热点数据中的top k 数据进行主动预热。
物理隔离
线程隔离
java 中线程池的隔离
进程隔离
容器化 docker
集群隔离
多集群部署
机房隔离
多活
超时控制
本质上：fail fast。良好的超时控制策略，可以尽可能地让服务不堆积请求，尽快清空高延迟的请求，释放Go routine.
具体做法：
默认值：一定要设置默认超时时间，而且要防御一下，比如超过60s，我们内部rpc 默认超时时间是250ms,当然有些job 扫表的超时时间不够，可以调整client的超时时间到800ms去解决。
超时传递：进程间传递+跨进程传递(grpc 默认支持）
看了一下 请求db的时候是有 Shrink 方法的，收敛context 的超时时间
如果上游 ctx 有 Deadline(),则从 上游的deadline 中获取超时时间，和自己设置的超时时间进行比较，两者比较获取较小的，这样就可以进程间传递超时时间了
gRPC 框架底层通过 HTTP2 协议发送 RPC 请求时，将 timeout 值写入到 grpc-timeout HEADERS Frame 中
参考：
《Go 进阶训练营》
gRPC 系列——grpc超时传递原理