系统设计-基础篇

如何提升系统性能？

高并发系统设计的三大目标：高性能、高可用、可扩展

高并发：高性能（响应时间）、高可用（down机、故障、维护）、可扩展（应急扩容）

响应时间（平均值、最大值、分位值），响应为1s，吞吐量为每秒1次，响应缩短到10ms，吞吐量上升到每秒100次，从用户体验来说：200ms分界点，1s为另一个分界点，健康系统的99分位值的响应时间控制在200ms以内，不超过1s的请求占比要超过99.99%

高并发下的性能优化手段：

1.提高系统的处理核心数（吞吐量=核心数(并发进程数)/响应时间(s)）但并非无限增加核心数就可以增加吞吐量，随着进程数增加，并行的任务对于资源的争夺也增加，在某个临界点，进程增加导致系统的性能下降，这就是性能测试中的拐点模型，所以在评估系统性能时，需要做压力测试，找到拐点

2.减少单次任务响应时间

cpu密集型：优化算法

io密集型：

1.采用工具，linux的工具集

2.通过监控，对任务的每一个步骤做分时统计，从而找到任务中哪一步小号消耗了更多的时间

tips:

1.业务价值->承载高并发->性能优化。一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，性能在需要的地方是no.1，但不需要的地方可能就是倒数第一稞。当下技术框架出来的软件差不到哪去，没有这种及时响应诉求的地方，削峰下慢慢跑就是了。（工作需要，常在缺少价值的地方着手性能优化，让我对这种就为个数字的操作很反感。要知道，异步，并发编程，逻辑缓存，算法真的会加剧系统的复杂度，得不偿失。如果没那个价值，简单才是王道）

2.提高并发度。要么加硬件，要么降低服务响应时间。做为开发，我们的目光更聚焦在降低响应时间这块。

1.采用非阻塞的rpc调用（高效的远端请求模式，采用容器的覆盖网络我认为也算）

2.将计算密集和io密集的的逻辑分割开，单独线程池，调整线程比例压榨单机性能（或者说找拐点）。

3.做缓存，io耗时的缓存和计算耗时的缓存（多级缓存，数据压缩降低带宽）。

4.采用享元模式，用好对象池和本地线程空间，尽量减少对象创建与销毁的开销，提高复用。

5.业务拆分，像状态变化后的外部系统通知，业务监控，es或solr等副本数据同步等操作，无需在主流程中做的事都拆掉。走canal监听表数据变化，推mq保最终一致的方式从业务项目完全解偶出来。

6.fork_join，分而治之的处理大任务。并发编程，采用多线程并行的方式处理业务。（规避伪共享，减小锁力度，采用合适的锁）。

7.数据库配置优化，查询优化。（存储优化比较头疼，毕竟不按业务拆单点跑不掉，单点性能就要命。基本只能内存库先行，后台同步数据做持久。然后内存库多副本，自修复，保留一系列自修复失败的修复手段）

系统怎样做到高可用？

1.开发设计层面

冗余---主备，负载均衡，failover（故障转移）

取舍----降级，限流，熔断，超时控制

降级是为了保证核心服务的稳定而牺牲非核心服务的做法。比方说我们发一条微博会先经过反垃圾服务检测，检测内容是否是广告，通过后才会完成诸如写数据库等逻辑。

限流完全是另外一种思路，它通过对并发的请求进行限速来保护系统。

2.运维层面

灰度发布，故障演练，监控报警

如何让系统易于扩展？

1.业务拆分

照业务拆分，在一定程度上提升了系统的扩展性，但系统运行时间长了之后，单一的业务数据库在容量和并发请求量上仍然会超过单机的限制。这时，我们就需要针对数据库做第二次拆分。

我们还可以根据业务接口的重要程度，把业务分为核心池和非核心池。打个比方，就关系池而言，关注、取消关注接口相对重要一些，可以放在核心池里面；拉黑和取消拉黑的操作就相对不那么重要，可以放在非核心池里面。这样，我们可以优先保证核心池的性能，当整体流量上升时优先扩容核心池，降级部分非核心池的接口，从而保证整体系统的稳定性。