高并发系统下的性能优化
主要思路有两种：
- 提高系统的处理核心数
例如：
采用Scale-up(纵向扩展，之前是四核8G，现在改成八核16G)，
采用Scale-out(横向扩展)，最直观的描述，加机器多应用。
- 减少单次任务的相应时间
1、利用缓存（redis、es）
2、异步回调（一次请求不等待结果马上返回，然后回调通知）
3、针对CPU密集型的可以采用更高效的算法，减少运算次数。
4、针对IO密集型的，比如：数据库系统、缓存系统、Web系统。如果数据库访问
慢，看看是否又锁表、全表扫描、索引是否合适、是否有Join、需不需要加缓存。
怎么做到系统的高可用
高可用指的是：系统具备较高的无故障运行的能力。
高可用的度量指标：MTBF和MTTR
MTBF（Mean Time Between Failure）是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。
MTTR（Mean Time To Repair）表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。
通常也是使用几个9来描述系统的可用性。
image
一般来说，我们的核心业务系统的可用性，需要达到四个九，非核心系统的可用性最多容忍到三个九。在实际工作中，你可能听到过类似的说法，只是不同级别，不同业务场景的系统对于可用性要求是不一样的。
高可用系统设计的思路
- failover（故障转移）、超时控制以及降级和限流。
- 系统运维
在业务平稳运行过程中，系统是很少发生故障的，90% 的故障是发生在上线变更阶段的。
比方说，你上了一个新的功能，由于设计方案的问题，数据库的慢请求数翻了一倍，导致系统请求被拖慢而产生故障。
1、灰度发布
概念：灰度发布指的是系统的变更不是一次性地推到线上的，而是按照一定比例逐步推进的。
一般情况下，灰度发布是以机器维度进行的。比方说，我们先在 10% 的机器上进行变更，同时观察 Dashboard 上的系统性能指标以及错误日志。
如果运行了一段时间之后系统指标比较平稳并且没有出现大量的错误日志，那么再推动全量变更。
2、故障演练
其实就是人为的设置一些故障来检测系统是否出现了这些故障仍能继续运行。
如何让系统易于扩展
- 存储层扩展
分库分表，可以理解Wie微服务，用户户、订单库、仓储库等等。
- 业务层扩展
用户池、订单池、仓储池。（池的概念可以理解为一个集群）
