高并发、高可用、高性能实现方案

高并发：

　　高并发是现在互联网分布式框架设计必须要考虑的因素之一，它是可以保证系统能同时并发处理很多请求，对于高并发来说，它的指标有：

　　　　1、响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间

　　　　2、吞吐量：吞吐量指每秒能处理多少请求数量

　　　　3、秒查询率：每秒响应请求数，和吞吐量差不多

　　　　4、并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数

　　Redis

　　MQ

　　多线程

高可用：　　

　　可用性：指一个系统处在可用工作状态的时间的比例

　　高可用：让系统趋近于100%的高度可用

　　高可用设计理论：

　　　　CAP：Consistency、Availability、Partition tolerance，此理论人尽皆知，最终会在CP和AP中权衡，找到满足BASE（Basically Available、Soft state、Eventually consistent）的平衡结果

　　高可用设计要素：

　　　　冗余：确保对系统操作至关重要的任何元素都有一个额外的冗余组件，这些组件可以在发生故障时接管。

　　　　监控：从正在运行的系统中收集数据，并检测组件何时发生故障或停止响应。

　　　　故障转移：一种手动或自动机制。如果监控显示活动组件发生故障，该机制可以从当前活动的组件切换到冗余组件。

　　上述三要素逻辑也很清晰：要实现高可用，不管是否存在状态，要先有冗余或备份；当真正出现故障的时候，要有监控手段监控到故障发生；故障发生后，可以通过故障转移组件快速转移到之前的冗余组件中，保证服务不中断。

　　高可用方案设计需要从哪些角度讨论和思考？

　　　　首先，应用侧、支撑侧、运维侧的设计方式方法不同。

　　　　应用侧高可用除了可以通过上述提到的冗余、集群、负载均衡等做到快速的故障转移，还包括熔断、限流、容错、降级、应急等保障手段，框架组件的超时及重试策略、异步调用、幂等性设计来补充。

　　　　支撑侧（或称基础设施平台）需要一整套高可用相关的监控指标，满足故障的提前预警、快速报警、可视化监控和分析。常见指标包括请求量、请求错误率、平均延时、HTTP状态，以及系统资源消耗相关指标等。

　　　　运维侧中关键一点是DevOps，自动化发布、灰度发布、优雅发布、版本控制、健康检查等能力，可以在业务发生故障前和发生故障时，帮助应用最大程度减小服务不可用时长。

高性能：

　　高性能指程序处理速度非常快，所占内存少，且CPU占用率低。高性能的指标经常和高并发的指标紧密相关，想要提升性能，那么就要提高系统并发能力，两者互相捆绑在一起。 

　　怎么样提高性能呢？

　　　　1、避免因为IO阻塞让CPU闲置，导致CPU的浪费

　　　　2、避免多线程间增加锁来保证同步，导致并行系统串行化

　　　　3、避免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上

END.