1. 必备条件
高并发，高性能分布式ID
高并发过滤组件 Bloom FIlter
2. 数据库
（1）不要让mysql干不擅长的工作，例如全文搜索，而是采用对应的nosql来处理；对于擅长的存取数据则能很好胜任；
（2）master/slave 主从架构（1主三从）来分散读压力；
（3）双中心提高可用性（专线可以让两个机房的数据同步延迟在1毫秒内），并且通过路由进一步分散读压力；
（4）分库分表解决数据量压力：十几亿的数据分成1000多张表（每张表的数据在几十万的级别）。
3. 数据平滑迁移
全量同步、增量同步、实时流量灰度切换。
（1）首先，在一个夜黑风高的深夜，流量最小的时候，完成SQL Server到MySQL数据库的全量数据同步。
（2）然受，为了保证数据的无缝切换，采用实时双写的方案。如果写失败，重试三次，如果依然失败，则记日志，然后人工排查原因，解决后，继续双写。
（3）通过A/B平台逐步灰度流量，刚开始100%的流量读取SQL Server数据库，然后逐步切流量读取MySQL数据库，先1%，如果没有问题，再逐步放流量，最终100%的流量都走MySQL数据库。
1）在一次查询请求里，通过异步线程，比较SQL Server和MySQL的查询结果是否一致，如果不一致，记日志，再人工检查不一致的原因，直到彻底解决不一致的问题后，再逐步灰度流量。
2）日志监控，看双写是否有问题，看数据比对是否一致等等。
4. ES的双机房方案
5. Redis双中心多集群
更新缓存数据时，双写，只有两个机房的Redis集群都写成功了，才返回成功。查询缓存数据时，机房内就近查询，降低延时。
6. 高并发架构图
6.1 注册中心高可用
单个Nacos实例故障：利用Load Balancer集群提供的健康检查能力自动从VIP中摘除；
某个VIP集群故障：利用客户端重试机制解决；
单个AZ故障：利用客户端重试机制解决；
MySQL集群故障：MySQL与注册发现过程无关，不受影响；
整个Nacos服务故障：客户端兜底机制，如服务实例缓存等。
6.2 注册中心监控
服务监控是所有业务团队都极为关注的主题。完整的微服务监控体系一般需要有以下3个方面组成：
（1）指标监控：涵盖QPS/响应延时/错误率等黄金指标、业务的自定义指标、JAVA应用的JVM指标，以及基础环境相关指标，如CPU、内存利用率等；
（2）日志监控：例如错误日志数量；可以利用AI技术对日志模式进行统计分析等；
（3）链路监控：由于微服务调用关系的复杂性，调用链追踪显得尤为重要，它可以帮助业务人员更好地分析应用间的依赖关系，并能够监控各个调用关系上的关键指标。
6.3 IM 架构图
6.4 号段模式提高分布式 ID 的并发性
以人为单位，设置一段可用的id range
6.5 Disruptor实现高并发生产消费
美团一面：如何实现一个100W ops 生产者消费者程序？
7. 高并发恶意狂刷
7.1 防护措施
- 交互式验证
- 安全参数校验
- 使用 HTTPS
- 用户访问认证
- 资源访问授权
- 访问限流
- IP封禁
- 日志监控和异步分析
- 升级硬件设备
- 基于时序的统计预警：Prometheus +Grafana +Alertmanager
8. 秒杀高并发下单
在秒杀抢购等极端情况下，如何处理每秒上万次的下单请求。1 秒钟之内，有 1 万个数据库连接同时达到，系统的数据库濒临崩溃。
9. 高并发分布式ID
滴滴太狠：分布式ID，如何达到1000Wqps？
10. 高并发处理请求
（1）全链路拆分
- 接受下游请求环节
- 上游请求分裂后入列环节
- 执行上游调用环节
- 上游结果聚合和响应环节
（2）多层次异步化
- 应用层：编程模型的异步化
- 框架层：IO线程的异步化
- OS层： IO模型的异步化
（3）多维度优化
1）业务线程，IO线程优化
合理的设置线程池的大小、拒绝策略。 并且结合不同的框架和组件，结合自己的业务场景实现异步。
2）网络传输
- 连接复用：短链接变成长连接
- 多路复用
11. 高并发概念
（1）QPS： Queries Per Second 是每秒查询率 ,
（2）TPS： Transactions Per Second 也就是事务数/秒。
- 用户通过client工具完成一个页面的一次访问，形成一个Tps；
- 如果一次页面请求，产生多次对服务器的api请求，这个Tps 包含多个 qps。
- 如果一次页面请求，产生1次对服务器的api请求，这个Tps 包含1个 qps。 也就是 tps=qps
（3）RT：响应时间，执行一个请求从开始到最后收到响应数据所花费的总体时间。
单节点QPS公式：QPS=1000ms/RT
对同一个分布式系统而言，支持的节点数越多，QPS越高。可见QPS随着节点横向扩展、节点的增加而线性增长。
（4）并发数：指系统同时能处理的请求数量，同样反应了系统的负载能力。
并发数 = QPS*平均响应时间
（5）吞吐量：
系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，IO速度越慢，那么，系统吞吐能力越低。
（6）PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。
（7）UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。
可以统计服务一天的访问日志并根据用户的唯一标识去重得到。
（8）DAU（Daily Active User）：日活跃用户数量。
DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似
（9）MAU（Month Active User）：月活跃用户数量，指网站、app等去重后的月活跃用户数量
12. 高并发架构图
高并发访问时，如何抵抗？
1. 接入层
（1）扩容：ngnix单节点qps为2.5W，SpringCloud gateway单节点5K qps
（2）限流，nginx 限流，SpringCloud gateway 限流
2. 缓存
redis集群架构横向扩展，单节点一般在3w qps左右.还可以使用本地缓存
HotKey探测方案：
HotKey探测方案1： 流计算集群
HotKey探测方案2： 流计算集群
HotKey探测方案3： 结合开源hotkey，做热点探测
13. 红包业务
（1）微信红包在信息流上可以分为订单纬度与用户纬度。其中订单是贯穿红包发、抢、拆、详情列表等业务的关键信息，属于交易类信息；而用户纬度指的是红包用户的收红包列表、发红包列表，属于展示类信息。
（2）南北分布
1、订单层南北独立体系，数据不同步
用户就近接入，请求发红包时分配订单南北，并在单号打上南北标识。抢红包、拆红包、查红包详情列表时，接入层根据红包单号上的南北标识将流量分别引到南北系统闭环。根据发红包用户和抢红包用户的所属地不同，有以下四种情况：
1）深圳用户发红包，深圳用户抢
订单落在深圳，深圳用户抢红包时不需要跨城，在深圳完成闭环。
2）深圳用户发红包，上海用户抢
订单落在深圳，上海用户抢红包，在上海接入后通过专线跨城到深圳，最后在深圳闭环完成抢红包。
3）上海用户发红包，上海用户抢
订单落在上海，上海用户抢红包时不需要跨城，在上海完成闭环。
4）上海用户发红包，深圳用户抢
订单落在上海，深圳用户抢红包，从深圳接入后通过专线跨城到上海，最后在上海闭环完成抢红包。
系统这样设计，好处是南北系统分摊流量，降低系统风险。
