前言
高并发是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
高可用就是抵御不确定性，保证系统 7*24 小时健康服务。
系统的主要原则即如何在高并发的条件下，保证系统的高可用。
高并发指标：
响应时间：系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms，这个 200ms 就是系统的响应时间。
吞吐量：单位时间内处理的请求数量。
QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。
并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
高并发原则
- 无状态设计：因为有状态可能涉及锁操作，锁又可能导致并发的串行化。
- 保持合理的粒度：无论拆分还是服务化，其实就是服务粒度控制，控制粒度为了分散请求提高并发，或为了从管理等角度提高可操性。
- 缓存、队列、并发等技巧在高并发设计上可供参考，但需依场景使用。
高可用原则
- 系统的任何发布必须具有可回滚能力。
- 系统任何外部依赖必须准确衡量是否可降级，是否可无损降级，并提供降级开关。
- 系统对外暴露的接口必须配置好限流，限流值必须尽量准确可靠。
业务设计原则
- 安全性：防抓取，防刷单、防表单重复提交，等等等等。
- at least 消费，应考虑是否采用幂等设计
- 业务流程动态化，业务规则动态化
- 系统 owner 负责制、人员备份制、值班制
- 系统文档化
- 后台操作可追溯
高并发处理手段
- 提高处理速度：缓存、异步
- 增加处理人手：多线程（多进程）、扩容
- 减少访问人数：预处理（本文不涉及）
高可用处理手段
高并发下的高可用很难完全避免，我们处理高可用的手段，其实就是容灾，其不同的‘灾难’，对应不同的容灾级别。
为了对抗这些不同级别的不确定性，就要付出不同级别的成本，因此可用性也应是有标准的。这标准就是大家常说的 N 个 9。随着 N 的增加，成本也相应增加。
当然高可用不止包含了容灾级别，也应考虑到故障处理时间。
我这里则尝试使用‘事情’来分个类。这里的‘事’就是故障，分为：事前（故障发生以前）、事发（故障发生到系统或人感知到故障）、事中（故障发生到故障处理这段时间）、事后（故障结束之后）。
按照上述分类，不同的阶段应有着不同的技巧：
- 事前：副本、隔离、配额、提前预案、探知
- 事发：监控、报警
- 事中：降级、回滚、应急预案，failXXX 系列
- 事后：复盘、思考、技改
总结
上文简单介绍了高并发系统的设计原则，以及高并发高可用的设计手段，具体的思路请见下文。