设计性能认知

延时

操作名称	时间
1级缓存引用	0.5ns
2级缓存引用	7ns
互斥锁/解锁	100ns
主存引用	100ns
用zippy压缩1k字节	10,000ns=10μs
通过1GB网络传输2KB字节	20,000ns = 20μs
内存按照顺序读取1MB	250,000ns=250μs
同一个数据中心内的往返	500,000ns = 500μs
磁盘寻找	10,000.000ns=10ms
从网络中读取1MB	10,000.000ns=10ms
从硬盘中读取1MB	30,000.000ns=30ms
发送数据包CA(加利福尼亚)->荷兰->CA	150,000.000ns=150ms

可用性

可用性	每天停机时间	每年停机时间
99%	14.40分钟	3.65日
99.9%	1.44分钟	8.77小时
99.99%	8.64秒	52.60分钟
99.999%	864毫秒	5.62分钟
99.9999%	86.4毫秒	31.56秒

系统设计步骤框架

步骤1 -理解问题并确定设计范围
步骤2 -提出高层次的设计并获得支持
步骤3 -重点难点的深度思考
步骤4 -价值和发展包装

常见设计场景

限速器设计

设计范围考虑

服务端or客户端
限速指标，ip？id？
系统规模
分布式or单机

高层次设计

位置

在这里插入图片描述
API网关是完全托管的支持速率限制、SSL终止、身份验证、IP白名单、服务的服务静态内容等。在API网关做统一的入口限速。服务之间的rpc，在rpc调用和接收层做控制。

使用缓存支持分布式和高效读写，常用INCR和EXPIRE

算法

算法名称	算法原理	优点	缺点
令牌桶算法	令牌被放入桶中定期以预设的速率。一旦桶填满，就不会再添加令牌。请求拿到令牌才能经过，否则丢弃。核心参数桶大小、填充率，根据限流维度设计桶	易于实现，内存效率高	可能有爆发流量，调参难
漏桶算法	请求到达时，队列未满，则请求添加到队列中，否则丢弃，队列中请求定期取出处理。核心参数桶大小、流出率	稳定的用例流出率	调参难
滑动窗口计数算法	将一段时间分割成多个段来表示最近的请求分布，新的一毫秒可能淘汰最老的一毫秒桶	平滑了高峰流量，因为速率是基于平均速率以前的窗口。	时间存在误差，但是影响小

深度思考

规则如何制定

配置文件，文件可以通过从限流服务处拉取，方便配置

如何返回限流信息

http头中定义，如当前窗口剩余请求次数，预期什么时间可以重试等等

被限制的如何处理

丢弃规则，直接错误返回，排队，降级

分布式问题

多个限流服务器数据需要同步，所以使用同一redis

分布式竞争问题

redis Lua脚本

价值发展

除了http多协议支持
其他层面（ip层等）限速考虑
处理跟踪

分布式唯一id设计

设计范围

已知分布式，流量多大

高层次设计

UUID
简单唯一速度快，但是写入索引效率降低，一般不采用
数据库自增id
会有高并发瓶颈
雪花算法
符号位+时间戳+机器id+序号
符号位为0，0表示正数，ID为正数,所以固定为0。
时间戳位不用多说，用来存放时间戳，单位是ms,时间戳部分占41bit，这个是毫秒级的时间，一般实现上不会存储当前的时间戳，而是时间戳的差值（当前时间-固定的开始时间）,这样可以使产生的ID从更小值开始。
工作机器id位用来存放机器的id，通常分为5个区域位+5个服务器标识位。这里比较灵活，比如，可以使用前5位作为数据中心机房标识，后5位作为单机房机器标识，可以部署1024个节点。
序号位是自增。

深度思考

数据库自增 id优化为双号段

单库生成自增 id，要是高并发的话，就会有瓶颈。专门开一个服务出来，这个服务每次就拿到当前 id 最大值，然后自己递增几个 id，一次性返回一批 id。然后服务端快使用一批时提前异步加载下一批。

雪花算法优化

机器id不便于维护改进

百度UidGenerator用在启动时会往数据库表(uid-generator需要新增一个WORKER_NODE表)中去插入一条数据，数据插入成功后返回的该数据对应的自增唯一id就是该机器的workId，而数据由host，port组成。
美团Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，在启动时都会都在Zookeeper中生成一个顺序Id
系统时间