高并发系统设计（一）
文章目录
简介
- 这个系列主要总结一下高并发系统的设计，主要是拓展一下思维眼界
设计思想
- 有三种常用的设计方法
- 高并发系统的演进应该是循序渐进的，以解决实际问题为驱动力，而不是一开始就追求复杂架构
架构分层
- 随着业务复杂，大量代码纠缠，各模块相互依赖，牵一发而动全身，就需要分层
- 另外一种常见的分层方式是：表现层、逻辑层、数据访问层（dao）
- 类似TPC/IP协议，将网络分为五四层；Linux文件系统等等
- 分层设计的优势
- 简化设计，让不同的人专注某一层的设计
- 很高的复用
- 容易横向扩展
- 层与层之间的界限有时不明确
- 为了避免类似表现层承担业务逻辑的耦合，可以采用下面的分层设计：
- 每层的大概作用：
- Manager层提供原子性的服务接口，Service层负责根据业务逻辑编排接口
- 分层的不足
三个目标
- 高性能、高可用、可扩展
- 高性能、高可用：是高并发系统必须要考虑的因素，更快速响应（速度就是性能）、提升用户体验，并且很少发生故障，容易维护
- 可扩展：应对峰值流量可能要做很多准备，如果不易扩展也是灾难
高性能
- 性能优化原则
- 性能度量指标
- 性能优化方式
- 提升系统的处理核心数
- 这是优化性能最简单的途径，有如下公式
- 1/(1-p+p/s)
- 那是不是无限增加核心数就可以呢？并不是
- 当并发进程数到达了拐点区，对系统资源的争抢太过严重，反而造成系统性能的下降
- 所以一般会进行压力测试，找到拐点（系统承载能力），避免损耗
- 减少单次任务响应时间
- 类似排除MySQL慢查询
- 首先看任务是CPU密集型还是IO密集型
- 另一个手段就是通过监控发现性能瓶颈，对任务的每一步做分时统计！
- 新系统上线前做好性能监控系统也是必须的
高可用
- High Availability （HA）高可用
- 指系统具备较高的无故障运行的能力
- 度量指标
- HA设计思路：系统设计和系统运维两方面保障
系统设计
- 做系统时，要把发生故障作为重要考虑点
- 具体的优化方法
- 故障转移
- 顾名思义，换机器来解决故障
- 有两种情况
- 检测机器是否故障
- 选主的结果需要在多个备份节点上达成一致（通知到位），有一些分布式一致的算法
- 超时控制
- 超时控制其实就是让请求不要一直保持，而是经过一段时间后自动失败
- 牺牲少量请求保证系统整体可用性
- 如何设置超时时间呢？
- 降级
- 反垃圾检测是比较重的操作，并发较高时可能成为瓶颈，应该暂时关闭！
- 限流
系统运维
- 我们可以从两个方面提高可用性：灰度发布、故障演练
- 灰度发布
- 故障演练
- 小结：可用性和性能有时是需要取舍的，也有追求极致可用性而不追求性能的系统（例如配置下发）
易于扩展
- 因为峰值流量不可控，我们无法预先考虑好使用多少台机器
- 面对突发流量，改造架构来不及，只能堆机器，但扩容了3倍机器，系统不一定能承受3倍流量
- 数据库、缓存、依赖的第三方、负载均衡、交换机带宽等都是扩展时需要考虑的因素
- 扩展的设计思路
- 举例：设计一个社区，模块大致如下：
- 使用简单的三层架构：负载均衡 + 应用服务器 + 数据库
- 当然，随着业务数据增长，还会有问题
- 这次拆分是按照数据特征做水平拆分，例如我们给用户库增加两个节点，按照算法将数据均分到这三个库（分库分表…）
- 上面是存储的扩展，业务层的扩展如何拆呢？
- 我们一般从三个维度：业务、重要性、请求来源
- 演进入下：
- 我们还可以做进一步的拆分，根据重要程度，拆分为核心池和非核心池，例如：
- 总而言之，系统拆分是提升扩展性的主要手段，根据业务范围进行解耦分块（搭积木）
小结
- 这里从宏观的角度了解了高并发的基本知识
- 基本设计思想：横向扩展、缓存、异步
- 架构分层
- 三个目标：高性能、高可用、易扩展
- 接下来会从局部出发，详细了解完成这些目标会使用到的一些方法
