谈谈高并发系统的一些解决方案
本文结合项目经验，整理一份大纲，供参考。常用指标[*]RT（Response Time）：响应时间。可能会衍生出 TP999、TP99、TP95、TP90等指标。一般在几毫秒到几百毫秒之间。
[*]QPS（Query Per Second）：每秒查询量。这是我们最常说的一个指标了。视业务复杂度不同而不同，轻量级的可能单机上万，重量级的可能就几百，这是主要依靠水平扩容来解决。
[*]TPS（Transaction per second）：每秒事务量。主要衡量数据库性能，一般比 QPS 低 1~3 个数量级。
[*]吞吐量（Throughput）：单位时间内处理的请求数量。该指标概念比较宽泛：
[*]从业务角度看，吞吐量可以用QPS、TPS等单位来衡量。
[*]从网络角度看，吞吐量可以用bps来衡量。一般用于排查网络抖动等问题，尤其是弱网环境下的RPC请求会更加关注。
[*]PV（Page View）：页面浏览量。一般用于统计页面访问频次，每次刷新页面即被计算一次。高并发系统的单日 PV 基本上会超过千万。
[*]UV（Unique Visitor）：独立访客量。用于统计单位时间内页面访问的用户数，同一个用户多次刷新页面只会被算做一次。高并发系统的单日 UV 基本上会过万。
提升系统性能的两个维度
[*]垂直扩展：提升单机性能。包括硬件配置和软件编写方式两种维度。
[*]水平扩展：集群整体性能。无状态服务加机器可解决；有状态服务还要额外考虑状态存储及迁移。实践中尽量做成无状态服务。
灾备管理多区域部署机房，通常存在冷备、热备、双活等几种形式。主要用于流量分摊和故障转移。
故障处理
[*]Failover 失败自动切换：当出现失败，重试其它服务器，通常用于读操作。一般核心服务会使用该策略。
[*]Failfast 快速失败：只发起一次调用，失败立即报错，通常用于非幂等性的读写操作。多数场景均有重试机制。
[*]Failsafe 失败安全：出现异常时，直接忽略。通常用于写入日志等操作。
[*]Failback 失败自动恢复：后台记录失败请求，定时重发。通常用于消息通知等操作。
[*]Forking 并行调用多个服务方：其中一个成功即可返回，通常用于实时性要求较高的读操作。
[*]Broadcast广播调用：所有提供方逐个调用，任意一台报错则报错。主要用于RPC框架注册节点使用（更新提供方本地状态），应用型服务基本不会使用。
负载均衡
[*]监控机器性能，并配置机器的权重（静态或动态）。
[*]处理能力越强，分到的流量越多。
[*]某台机器故障时自动摘除流量。
[*]服务刚启动时的小流量预热，防止瞬间高流量把机器打崩。主要是各类中间件资源初始化可能会很耗时，导致请求响应慢，此时如果大量流量涌入会导致 Cpu Load急剧升高，甚至可能打崩。
[*]自动扩缩容。业务高峰时段自动扩容，低峰时段自动缩容，节约成本。
区分服务等级
[*]核心服务：一般都存在Backup，出错时自动切换，同时触发中高级别告警。
[*]非核心服务：出错时可执行（手动或自动）降级甚至熔断，同时触发中低级别告警。
使用缓存主要针对不易变化的数据，可能是多级缓存，可能横跨客户端和多个服务端。
[*]本地缓存。如 ConcurrentMap、Guava Cache、Caffeine。
[*]分布式缓存。如 Redis、GemFire/Geode。
异步操作
[*]架构层面：
[*]如使用MQ消息队列进行削峰、解耦处理，日志处理也用得比较多。
[*]若追求 Cpu 的稳定性，可使用 Spring WebFlux 等全链路异步化技术，需要上下游服务都改造，才能有显著效果。
[*]代码层面：如 Java 中的 Future 机制（常用 CompletableFuture），同时发起多个微服务的调用，隔一段时间后统一 get 结果。
批量执行
[*]框架层面：可参考 Hystrix 的请求合并机制 HystrixCollapser。
[*]代码层面：服务接口批量调用数据，拿到批量结果后再分派结果。
池化技术
[*]线程池：常用如 ThreadPoolExecutor。
[*]连接池：常用如 HikariCP、Druid、c3p0、DBCP。
[*]对象池：常用如 Apache Commons Pool2。另外，如 Integer 等包装类针对（-127~128）的对象缓存，其实也是一种对象池的体现。
限流处理
[*]服务入口：监控近实时统计QPS，达到阈值时拒绝请求。
[*]常见的几种限流框架：
[*]单机版（JDK自带的锁、信号量、Guava Limiter）
[*]分布式（基于 Redis 的 redis-cell 模块和 Redisson、重量级的 Sentinel，以及老牌框架Hystrix）
[*]常见的几种限流算法：
[*]计数器法。存在临界流量问题，基本不会使用。
[*]滑动窗口。时间片划分精度不好控制，基本不会使用。
[*]漏桶算法。难以应对突发流量，使用较少。
[*]令牌桶算法。常用。
[*]常见的线程池拒绝策略：
[*]CallerRunsPolicy 由调用者运行。
[*]AbortPolicy 抛弃并抛异常。这是默认策略，也是最常用的策略，可以让应用层快速发现失败，进而介入处理。
[*]DiscardPolicy 静静地抛弃，应用层无法感知到。
[*]DiscardOldestPolicy 抛弃最老的请求。
防刷分流搭建两套服务集群，将存在爬虫标记（依赖于专业的爬虫识别算法）的流量分流到另一套集群，甚至可以返回假数据，做蜜罐处理。
静态资源分发主要依赖 CDN 技术进行资源的就近部署，可提前预热。常见如html、js、css、image等资源。
数据库并发
[*]单机：MVCC、事务隔离、做好索引优化。
[*]集群：分库分表、读写分离。
[*]结合其他中间件：如简单的查询、统计，或者文本搜索等场景，可使用 ElasticSearch，必要时进行二级检索（ ElasticSearch 检索出 id，再到 SQL 中查询）。
压力测试 /性能测试
[*]Apache JMeter。
[*]搭建压测集群，平时抓取服务真实流量，节日或大促前进行必要的压测，以暴露性能瓶颈。
日常巡检/故障演练用于提前发现问题，如接口扫描、混沌工程就是做这些事情的。
页:
[1]