高并发葵花宝典
前言
冰冻三尺非一日之寒，系统设计也如此，好的架构是不断演进的。
一般来说能够用单块架构解决的问题，尽量不要采用分布式。分布式虽然可以提高系统的响应能力，也带来了更高的复杂性，如果团队技术人员水平hold不住的话，反而会产生更多问题，例如问题难以定位，系统性能下降，某种业务实现困难或无法实现等问题。
以下内容由伟大的诗人chenqionghe整理，light weight baby~
常用指标
响应时间
直观反应系统快慢，一般控制在200ms以内，超过1s用户已经感觉到慢了
并发数
同时处理请求的数目
QPS
每秒查询请求数
TPS
每秒执行事务数，着重反应写
夺命三高
高并发
通过设计让系统能接收更多的用户并发请求，承担更大的流量。
一般考查并发数、QPS和TPS。
高性能
一般指服务响应时间快
- 用户视角。APP、浏览器上直接感受快
- 开发视角。响应延迟低，系统吞吐量大，并发处理能力强
- 运维视角。基础设施配置高，CPU多核心，内存大
高可用
系统通过设计，减少停工时间，保持服务的高度可用性。
一般会用SLA协议衡量服务可用性，一般用几个九来衡量
以一年为例，1年 = 365天 = 8760小时
- 99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
- 99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
- 99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
SLA提供的可用性越高，那么一年内停机的时间越小。高可用的一种量化指标
常见招式
分流
例如nginx、hproxy、traefik，本质就是将流量分摊到不同的节点，负载均衡
举例：星巴克开分店，增加营业员、扩大面积
缓存
例如：Redis缓存、Memcached
举例：提供超市热卖摊位，提高顾客购买效率；早餐店先提前把早餐做好，顾客来直接取
队列
- 提高响应速度。
未处理完成前提前返回，提高响应速度，处理完后再发通知。 - 缓冲流量，削峰填谷
为了避免大量的请求冲击后端服务，可以使用消息队列暂存请求，后端服务按照自己的处理能力，从队列中消费，例如秒杀、埋点场景。
简单地说，就是业务上游队列缓冲，限速发送；业务下游队列缓冲，限速执行
针对 秒条场景，一般两种方式，- 加锁。比如golang包中的mutex，也可以利用redis本身操作原子性的特点
- 写入消息队列。在消息队列中做减库存的操作
- 系统解耦
例如一个下单的信息需要同步多个子系统，每个子系统都需要保存订单的数据的一部分，如果靠订单服务的团队维护所有子系统同步，耦合太大，这时候可以通过发布订阅模型，订单服务在订单变化时发送一条消息到一个主题中，所有的下游子系统都订阅主题，这样可以每个子系统都可以获得订单数据。
举例：去海盗虾饭吃饭，先结账，做好了给你端过来
CDN
CDN（Content Delivery Network）官方定义叫内容分发网络。
简单的说就是一种缓存，原理是将静态的资源分发到位于多个地埋位置机房的服务器上。
，最终可以达到就近获取数据达到提速的效果，例如北京地区访问北京的数据，海南访问海南的。
当然，这也不用我们自己开发，例如阿里云、七牛云等知名云厂商都提供了CDN服务。
一般使用就是设置CDN回源更新数据的地址，将服务域名解析到云厂商返回的CNAME上。
举例：京东购买东西，发货都直接从最近的仓库发货，只有仓库没货了才会到源头取货（回源）
池化
一般连接的创建是比较耗资源和时间，一般我们可以使用连接池来提升效率，这就是传说中的池化技术，常见的有数据连接池、线程池。
设定空闲连接数和最大连接数，步骤一般如下：
- 当前连接数小于空闲连接数，创建
- 连接池中有空闲连接直接使用
- 没有空闲连接，当前连接数小于最大连接数，创建
- 达到或超过最大连接数，按设定超时时间等待旧连接释放，超时抛出错误
本质都是空间换时间，一般创建的连接对象会放到一个队列中。
扩容
- 垂直扩容
升配置，例如加CPU核心、加内存、改为IO优化型存储
- 横向扩容
直接加机器，多多益善
熔断
当某服务调用的时候，如果返回错误或者超时次数超过一定阈值后，后续请求不再发送直接返回错误
举例：就像电路的熔断器一样，电流过载，自动断开电路。
开源方案有：hystrix、traefik、istio，
限流
通过限制到达系统的并发请求数量，保证系统能正常响应部分用户的请求。超过限制的流量，通过拒绝服务的方式保证整体系统的可用性。
举例：十一假期去莫高窟旅游，景点只放出有限的门票，门票卖完，新来的客户不再接待。
可以在系统中埋下限流的代码，例如可以使用golang的缓冲channel实现。
降级
就像被沙加剥夺了五感一样
例如双十一的时候，打开淘宝，会发现界面上的信息少了很多，其实这就是一种降级，关闭或者拒绝很多不重要的功能，节省服务器资源抵御高并发大流量。
分层
好处：分工明确，方便复用、容易针对层做扩展。
这个分层，可以指代码架构，也可以指服务架构，一般不跨层调用
-
MVC
控制器（C）调用模型（M）取数据，再通过（V）渲染视图。
业务逻辑一般写到模型中进行复用，但是可能会带来的是模型之间的职责划分不明确。
所以一般还会在其中加入Service层，使Model模型不再存放业务逻辑。 -
Web、Service、Dao
- Web：表现层。可以简单理解成Controller和View
- Service：业务逻辑层。业务逻辑都封装到这一层，这一层直接调用Dao取数据
- Dao：数据访问层。负责访问数据库，最常见的是AR模型或者ORM
可以简单理解成MVC加了一层Service，Controller直接调用Service，Service再调用Model
-
Web、Service、Manager、Dao
在Service和Dao之间加了一层Manager，抽取service层之间的共同逻辑。
部署分级
根据优先级的高级将服务部署到不同的物理机上，可以通过K8S的label选择最终部署的节点
日志监控
- 日志追踪。
使用ELK或者阿里云日志服务。请求和打日志传递requestId，查询根据requestId检索请求相关的所有日志 - 调用链追踪.
开源方案Zipkin，Jaeger 。核心是通过TranceId和SpanId追踪每次调用 - Prometheus监控
把需要监控的指标存储到prometheus中，通过grafanan展示 - Sentry监控
统一搜集采集异常日志，针对500这种错误到sentry后台查询，比较方便定位问题
读写分离
将读请求和写请求分推到不同的实例，例如MySQL读写分离、Redis读写分离
MySQL主从分离核心是binlog，主库将binlog写入relay log文件，从库过来拉取。
主从同步容易遇到延迟问题，例如主库已经写入了，从库查询的还是老数据，一般会通过以下方式解决：
- 直接读主库
- 更新主库前写缓存，读缓存
- 直接将更新的数据传递，不查库
分库分表
一般会配合服务一起拆分
- 垂直拆分。
专门的服务使用专门的库。例如一个购买流程，可以拆分为商品库、订单库。 - 水平拆分。
例如将users拆成10个库，users0、users1…users9，根据某个字段的取模存放到不同的库。
缺点：
- 无法做join
- 统计数量也是个问题
- 不能再使用事务
查询优化
- 优化sql索引。分析sql执行效率，通过加索引优化
- 引入Elasticsearch。提高搜索效率，降低模糊搜索给数据库带来的压力。