1. ⾼并发原则
⽆状态:
- ⽆状态应⽤，便于⽔平扩展
- 有状态配置可通过配置中⼼实现⽆状态
- 实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分:
- 系统维度：按照系统功能、业务拆分，如购物⻋，结算，订单等
- 功能维度：对系统功能在做细粒度拆分
- 读写维度：根据读写⽐例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
- AOP维度： 根据访问特征，按照AOP进⾏拆分，⽐如商品⻚可分为CDN、⻚⾯渲染系统，CDN就是⼀个AOP系统
- 模块维度：对整体代码结构划分Web、Service、DAO
服务化:
- 服务化演进: 进程内服务-单机远程服务-集群⼿动注册服务-⾃动注册和发现服务-服务的分组、隔离、路由-服务治理
- 考虑服务分组、隔离、限流、⿊⽩名单、超时、重试机制、路由、故障补偿等
- 实践：利⽤Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现⾃动注册和发现服务。
消息队列：
- ⽬的: 服务解耦(⼀对多消费)、异步处理、流量削峰缓冲等
- ⼤流量缓冲： 牺牲强⼀致性，保证最终⼀致性(案例：库存扣减，现在Redis中做扣减，记录扣减⽇志，通过后台进程将扣减⽇志应⽤到DB)
- 数据校对: 解决异步消息机制下消息丢失问题
数据异构：
- 数据异构: 通过消息队列机制接收数据变更，原⼦化存储
- 数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环
缓存银弹：
- ⽤户层：DNS缓存、浏览器DNS缓存、操作系统DNS缓存、本地DNS服务商缓存、DNS服务器缓存、客户端缓存、浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)* App
客户缓存(js/css/image…) - 代理层：CDN缓存(⼀般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-
⼆级节点-中⼼节点-源站) - 接⼊层（Nginx为例）：Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD
FastCGI Cache、Nginx+Lua+Redis: 业务数据缓存 - 应⽤层：⻚⾯静态化、业务数据缓存(Redis/Memcached/本地⽂件等)、消息队列
- 数据层：NoSQL： Redis、Memcache、SSDB等、MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb、Buffer Size等
- 系统层：CPU : L1/L2/L3 Cache/NUMA、内存、磁盘：磁盘本身缓存dirty_ratio/dirty_background_ratio、阵列卡本身缓存
2. ⾼可⽤原则
降级：
- 降级开关集中化管理：将开关配置信息推送到各个应⽤
- 可降级的多级读服务：如服务调⽤降级为只读本地缓存
- 开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略
- 业务降级：⾼并发下，保证核⼼功能，次要功能可由同步改为异步策略或屏蔽功能
限流：
- ⽬的: 防⽌恶意请求攻击或超出系统峰值
- 实践：恶意请求流量只访问到Cache、穿透后端应⽤的流量使⽤Nginx的limit处理、恶意IP使⽤Nginx Deny策略或者iptables拒绝
切流量
- ⽬的：屏蔽故障机器
- 实践:DNS: 更改域名解析⼊⼝，如DNSPOD可以添加备⽤IP，正常IP故障时，会⾃主切换到备⽤地址;⽣效实践较慢、HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度LVS/HaProxy/Nginx: 摘除故障节点
可回滚：
- 发布版本失败时可随时快速回退到上⼀个稳定版本
3. 业务设计原则
- 防重设计
- 幂等设计
- 流程定义
- 状态与状态机
- 后台系统操作可反馈
- 后台系统审批化
- ⽂档注释
- 备份
4. 分布式与集群的区别
分布式是指将不同的业务分布在不同的地⽅。 ⽽集群指的是将⼏台服务器集中在⼀起，实现同⼀业务。
5.分布式事务
⼆阶段提交：
- 概念：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中⽌操作。
- 作⽤：主要保证了分布式事务的原⼦性；第⼀阶段为准备阶段，第⼆阶段为提交阶段；
- 缺点：不仅要锁住参与者的所有资源，⽽且要锁住协调者资源，开销⼤。⼀句话总结就是：2PC效率很低，对⾼并发很不友好。
三阶段提交：
- 概念：三阶段提交协议在协调者和参与者中都引⼊超时机制，并且把两阶段提交协议的第⼀个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
- 缺点：如果进⼊PreCommit后，Coordinator发出的是abort请求，假设只有⼀个Cohort收到并进⾏了abort操作，⽽其他对于系统状态未知的Cohort会根据3PC选择继续Commit，此时系统状态发⽣不⼀致性。
柔性事务：
- 概念：所谓柔性事务是相对强制锁表的刚性事务⽽⾔。流程⼊下：服务器A的事务如果执⾏顺利，那么事务A就先⾏提交，如果事务B也执⾏顺利，则事务B也提交，整个事务就算完成。但是如果事务B执⾏失败，事务B本身回滚，这时事务A已经被提交，所以需要执⾏⼀个补偿操作，将已经提交的事务A执⾏的操作作反操作，恢复到未执⾏前事务A的状态。
- 缺点：业务侵⼊性太强，还要补偿操作，缺乏普遍性，没法⼤规模推⼴。
消息最终⼀致性解决⽅案之RabbitMQ实现：
实现：发送⽅确认+消息持久化+消费者确认。
7. 什么时候⽤到分布式开发
优点：
- i. 模块解耦：把模块拆分,使⽤接⼝通信,降低模块之间的耦合度.
- ii. 项⽬拆分，不同团队负责不同的⼦项⽬：把项⽬拆分成若⼲个⼦项⽬,不同的团队负责不同的⼦项⽬.
- iii. 提⾼项⽬扩展性：增加功能时只需要再增加⼀个⼦项⽬,调⽤其他系统的接⼝就可以。
- iv. 分布式部署：可以灵活的进⾏分布式部署.
- v. 提⾼代码的复⽤性：⽐如service层,如果不采⽤分布式rest服务⽅式架构就会在⼿机wap商城,微信商城,pc,android，ios每个端都要写⼀个service层逻辑,开发量⼤,难以维护⼀起升级,这时候就可以采⽤分布式rest服务⽅式,公⽤⼀个service层。
缺点：
- i. 系统之间的交互要使⽤远程通信,接⼝开发增⼤⼯作量；
- ii. ⽹络请求有延时；
- iii. 事务处理⽐较麻烦，需要使⽤分布式事务。
8. cdn（异地多活）
异地多活：异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是⾼可⽤架构设计的⼀种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。
两地容灾切换⽅案：容灾是异地多活中最核⼼的⼀环， 以两个城市异地多活部署架构图为例。
在两个城市（城市1位于华南1地域、城市2位于华东1地域）均部署⼀套完整的业务系统。
下单业务按照“user_id”％ 100 进⾏分⽚，在正常情况下：
- [00~49]分⽚所有的读写都在城市1的数据库实例主库。
- [50～99]分⽚所有的读写都在城市2的数据库实例主库。
“城市1的数据库实例主库”和 “城市2的数据库实例主库”建⽴DTS双向复制。
当出现异常时，需要进⾏容灾切换。可能出现的场景有以下4种：
将第2种、第3种异常情况，全部采⽤第2种⽅案进⾏处理，那么不管是所有的APP Server异常、所有的数据库异常、整个城市异常，就直接按照城市级容灾⽅案处理，直接将APP Server、数据库切换到到另⼀个城市。
多城异地多活：
- 多城市异地多活模式指的是3个或者3个以上城市间部署异地多活。该模式下存在中⼼节点和单元节点：
- 中⼼节点：指单元节点的增量数据都需要实时的同步到中⼼节点，同时中⼼节点将所有分⽚的增量数据同步到其他单元节点。
- 单元节点：即对应分⽚读写的节点，该节点需要将该分⽚的增量同步到中⼼节点，并且接收来⾃于中⼼节点的其他分⽚的增量数据。
下图是3城市异地多活架构图，其中华东1就是中⼼节点，华南1和华北1是单元节点。
9. 分布式环境下宕机的处理⽅案？
- dubbo：服务器宕机，zk临时被删除；
- springcloud：每30s发送⼼跳检测重新进⾏租约，如果客户端不能多次更新租约，它将在90s内从服务器注册中⼼移除。
- apm监控
