使用消息队列时，需要注意消息丢失、重复接收的场景。这对于不能容忍生产失败的业务场景来说，一定要做好后续的数据处理工作，比如持久化数据同时要增加日志、报警等，或者在生产失败后发送http请求来保证成功。还有消息重复问题，特别是一些分布式消息队列，出于对性能和开销的考虑，在一些场景下会发送消息重复接收，需要在代码层面进行防重处理。

1.1.5.缓存

缓存对读服务来说，是扛流量的必选技术。不同的场景缓存不同的信息，以解决不同的问题：

浏览器端缓存
客户端缓存
CDN缓存
接入层缓存: 使用Nginx做一层缓存
应用层缓存
分布式缓存
异步与并发:某些资源实时性没那么高，可以考虑使用异步加载，如用户评价、商品打分这种。获取多个资源时，采用并发的方式获取，可以大大的加快访问速度。

1.1.6.数据异构

所谓数据异构，是把数据按需（数据结构、存取方式、存取形式）异地构建存储。比如将mysql里面的数据缓存到redis里面去，就是一种数据异构的方式。

分库分表中有一个最为常见的场景，为了提升数据库的查询能力，我们都会对数据库做分库分表操作。比如订单库，开始的时候是按照订单ID维度去分库分表，那么后来的业务需求按照商家维度去查询。相同的数据需要做多种异构可以使用MQ机制接收数据的变更，然后存储到合适的存储引擎，如订单id纬度的分库分表、商家纬度的分库分表、用户纬度的分库分表、redis、Elasticsearch等。

另外，还需要考虑对历史订单数据进行归档处理，以提升服务的性能和稳定性。而有些数据异构的意义不大，如库存架构，可以考虑异步加载，或者合并并发请求。

总结起来大概有以下几种场景：

数据库镜像
数据库实时备份
多级索引
search build（比如分库分表后的多维度数据查询）
业务cache刷新
价格、库存变化等重要业务消息
常见的异构方式：
完全克隆。做数据备份。将数据库A，全部拷贝一份到数据库B，这样的使用场景是离线统计跑任务脚本的时候可以。缺点也很突出，不适用于持续增长的数据。
binlog方式。比如使用比较广泛的canal是基于mysql数据库binlog的增量订阅和消费组件。订阅mysql的binlog日志，消费这些日志做主从同步、缓存更新。
MQ方式。业务数据写入DB的同时，也发送MQ一份，也就是业务里面实现双写，消费MQ的数据做各种异构处理。这种方式比较简单，但也很难保证数据一致性，对简单的业务场景可以采用这种方式。

1.2.高可用原则

1.2.1.降级

对于一个高可用服务，很重要的一个设计就是降级开关，提前写好降级逻辑。

可以手动降级，也可以自动降级。自动降级触发的条件可以使用：超时的请求数超过阈值、异常的请求数超过阈值时。阈值具体设置为多少，通过压测初步确认，上线观察后，再次调整。

降级的手段：停止读数据库、准确结果转为近似结果、使用静态结果、同步转异步、功能裁剪、禁止写（高峰期减少不必要的写）、分用户降级、工作量证明POW(
验证码、数学题、拼图、滑块)。

主要依据如下思路：

开关集中化管理：通过推送机制把开关推送到各个应用。
可降级的多级读服务：可以指定服务调用降级为只读本地缓存、只读分布式缓存、只读默认数据。
开关前置化: 如架构是Nginx—>Apache，可以将开关前置到Nginx接入层，在Nginx层做开关，请求流量汇源后端应用或者只是一小部分流量回源
业务降级：当高并发流量来袭，保证核心业务是正常的，并保障数据最终一致性即可。这样就把一些同步调用改成异步调用，优先处理高优先级数据或特殊特征的数据，合理分配进入系统的流量，以保障系统可用。

1.2.2.限流

当监控发现外部流量超过阈值或内部资源使用达到阈值（通过压测、上线观察、调整）时，告知各系统限流打开。

限流的目的是防止恶意请求流量，或者防止流量超出系统峰值。思路如下：

基于请求的限流：
- 限制请求总量。如腾讯会议最多500人。
- 限制时间量。如一个时间窗口内最多接受100个请求。
基于关键资源的限流：
- 统计连接数、线程数、cup等硬件参数。难点是如何确定哪些是关键资源、阈值是多少。
- 使用池化技术：线程池、连接池；使用队列排队；

1.2.3.熔断

熔断发生的三个必要条件，缺一不可，必须全部满足才能开启 hystrix 的熔断功能：

有一个统计的时间周期，滚动窗口；如1000毫秒
请求次数必须达到一定数量；如20次
失败率达到阈值；如50%
熔断器的三个状态：
关闭状态。关闭状态时用户请求是可以到达服务提供方的。
开启状态。开启状态时用户请求是不能到达服务提供方的，直接会走降级方法。

半开状态。当熔断器开启时，过一段时间后，熔断器就会由开启状态变成半开状态。半开状态的熔断器是可以接受用户请求并把请求传递给服务提供方的，这时候如果远程调用返回成功，那么熔断器就会有半开状态变成关闭状态，反之，如果调用失败，熔断器就会有半开状态变成开启状态。
Hystrix功能建议在并发比较高的方法上使用，并不是所有方法都得使用的。

Sentinel的熔断策略是根据响应时间，响应时间超过阈值，熔断开关打开。

1.2.4.恢复

撤出限流、消除降级、关闭熔断

熔断使用半开状态，完成吞吐量爬升、缓存预热。

灰度发布，限流阈值逐步提升。

1.2.5.隔离

数据隔离：数据按照重要性排序、分库
机器隔离：给重要的用户单独配置服务器，用用户标识去路由
线程池隔离：线程池分配。hystrix
信号量隔离：计数器。hystrix
集群隔离：服务分组（注册中心）、秒杀
机房隔离：3个服务。局域网IP、路由。
读写隔离：主从
动静隔离：识别静态资源。nginx CDN
爬虫隔离：对IP的访问频率
冷热隔离：秒杀、抢购。读：缓存；写：缓存+队列

1.2.6.异地多活

异地机房部署相同的服务，同时对外提供服务（不是备份）。防止因为停电、火灾、水灾、地震、战争等问题导致服务不可用。

异地多活通常考虑RTT(round trip time):网络请求一个来回消耗的传输时间。光纤光速计算 300000 KM/s，两个机房如果一个在上海，一个在新疆，隔5000KM，
rtt = 300000 / 5000 * 2 = 120毫秒的往返时延。

多活要求：

请求任何一个节点，都能正常响应
某些系统故障，用户访问其他系统也能访问
分类：
同城异区：距离较近，可以防止停电、机房起火
跨域异地：距离较近，可以防止停电、机房起火、火灾、水灾、地震。
跨国异地（隔离）：延迟，已经无法让系统提供服务了。通常在异国开展业务，数据和服务就放在异国，和国内数据是隔离的。
异地多活容易出现数据不一致问题，要保证核心业务的多活。如用户系统有注册、登陆、修改用户信息等功能，保证正常注册、登陆多活，修改用户信息可以根据时间合并数据。

1.2.7.可回滚

灰度发布。版本化机制，当程序出错时，回滚到上一个版本。

二、业务设计原则

2.1.防重、幂等

重复提交业务，消息中间件重复消费消息。使用分布式锁、数据库唯一键等保证。

2.2.模块复用

相同的功能只开发一次，模块化。不要到处拷贝相同的代码。

2.3.可追溯

可以快速追踪到问题涉及的这个数据链路，快速定位问题。traceId

2.4.反馈原则

给出精确友好的结果反馈。如http接口调用异常时尽量给出精确的异常原因，降低内外部沟通成本。

2.5.流程可定义

2.6.系统审批化

系统变更需要审批

2.7.文档和注释

完善文档和注释

2.8.备份

代码备份：git、分支
数据备份：运维备份，操作记录备份。
人员备份：不因个人离职导致项目停滞。

2.9.规范

制定规范，定期review。

三、系统性能常见指标

3.1.响应时间（Response time）

响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。

根据“管辖区域”不同，响应时间可以细分为：

服务器端响应时间这个时间指的是服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间可以度量服务器的处理能力。
网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。
客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web应用来说，比如Java
applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。
那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上。

系统设计原则

简介

一、系统的技术设计原则

1.1.高并发原则

1.1.1.无状态

1.1.2.拆分

1.1.3.服务化

1.1.4.消息队列