大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 47 天，也是我第 58 次进行这种操作。
今天我温习了该专栏里叫《性能设计篇之“缓存”》、《性能设计篇之“异步处理”》、《性能设计篇之“数据库扩展”》、《性能设计篇之“秒杀”》、《性能设计篇之“边缘计算”》的文章。
关键词总结：Cache Aside 更新模式（失效、命中、更新、问题、解决方案）、Read/Write Through 更新模式（Read Through、Write Through）、Write Behind Caching 更新模式（Write Back、套路、问题、复杂度）、缓存设计的重点（外部缓存集群、数据分片、命中率、一致性问题、缓存生命周期、LRU 策略、锁竞争、爬虫保护机制）、异步处理设计（异步任务处理、前台系统、任务处理系统、Push 推模型、Pull 拉模型、Pull 的好处、推拉结合）、事件溯源（解决的问题、事件回放、事件重播、事件可变性、事件记录、结合异步处理）、异步处理分布式事务（一致性、交易凭证、注意点）、异步处理设计要点（故障导致的问题、幂等性支持、整体业务事务问题、是否适合异步处理、任务积压情况、异步处理本质）、读写分离 CQRS（优点、缺点、CQRS / 命令与查询职责分离（语义区分、语义区分好处））、分库分表 Sharding（影响数据库性能的两个大问题（数据库操作、数据库数据量）、两个关注点（分库策略、数据访问层）、分片策略、分片模式注意点）、数据库扩展设计重点（水平分片注意事项）、秒杀流程（用户角度、技术角度）、秒杀技术挑战（百万 TPS、热点数据）、秒杀解决方案（引入 CDN、CDN 边缘节点、统计数据、概率值、放行的数据量）、更多思考（适合使用边缘节点的场景、适合使用边缘节点的场景）、边缘计算的意义（趋势方面（数字化革命、硬件发展、信息量以及数据量、MB 时代、GB 时代、TB 时代、PB 时代）、成本方面（非线性成长、增长后的投入比））、边缘计算业务场景（实时响应、业务逻辑单一、收集并结构化数据、实时设备监控、去中心化应用、云资源调度、云资源聚合）、边缘计算关键技术（应用程序接口网关、无服务器/函数为服务 / Serverless/FaaS）。
所学总结：
《性能设计篇之“缓存”》
Cache Aside 更新模式
最常用的设计模式。
失效
先从缓存读数据，没有的话再从数据库中读取，然后保存一份到缓存中。
命中
从缓存中读取到数据，直接使用缓存的数据。
更新
将新的数据存入数据库，然后让缓存失效，可以将新数据更新至缓存中。
问题
读取操作在写操作之前发生，会造成脏数据。
解决方案
通过 2PC 或 Pzxos 协议保证一致性。Facebook 使用了降低并发时脏数据的概率，因为 2PC 太慢，而 Paxos 太复杂。
Read/Write Through 更新模式
应用程序可以认为后端就是一个单一的存储名，而存储自己维护自己的缓存。
Read Through
当缓存失效的时候（过期或 LRU 换出），由缓存服务自己来加载，对应用方是透明的。
Write Through
在更新数据时发生。没有命中缓存的话直接更新数据库，然后返回。如果命中了则更新缓存，然后由缓存自己更新数据库（同步操作）。
Write Behind Caching 更新模式
Write Back
Write Behind 又被称为 Write Back。就是 Linux 文件系统的 pagecache 算法。
套路
更新数据时只更新缓存不更新数据库，缓存会异步地批量更新至数据库。
问题
数据不是强一致的，还可能会丢失。
复杂度
操作系统会在仅当缓存需要失效时，才将它持久化。例如内存不够或进程退出，属于 Lazy Write 的范畴。
缓存设计的重点
外部缓存集群
保证集群的内存足够大，网络带宽足够流畅，缓存本质上是个内存和 IO 密集型应用。
数据分片
不同的缓存分布至不同的机器上。保证缓存集群可以不断地进行扩展操作。
命中率
达到 80% 以上就挺高了。毕竟热点数据只是少数。
一致性问题
用缓存提高性能会有数据更新的延迟。
缓存生命周期
时间太短的话会导致应用程序不断从数据库检索数据。时间太长的话会导致内存中积攒过多的冷门数据。
LRU 策略
在内存不足时优先清除最少人访问的缓存数据。从后往前开始淘汰数据。
锁竞争
LRU 在读写时需要加锁（单线程无并发的情况除外），所以 LRU 会导致更慢的缓存读写时间。
爬虫保护机制
我们需要避免爬虫来爬取那些数据，或是可以给外部提供 API，让第三方开发者拥有自己的调用接口（也是有缓存的）。
《性能设计篇之“异步处理”》
异步处理设计
异步任务处理
前台系统
用于记录用户的请求，收到请求后给客户端让其知道，并让其等待至处理完毕。
任务处理系统
将任务解耦，可以借助两个模型：Push 推模型和 Pull 拉模型。
Push 推模型
将任务分发给相应的服务去处理。可以起到调用的作用，但是需要知道下游服务的工作情况。
Pull 拉模型
由处理的服务来拉取要处理的任务。
Pull 的好处
上游服务无需关心下游服务的工作状态。
推拉结合
Push 做任务调度，类似于物流将相同商品的订单合并起来打包交给下游服务让其一次处理完毕；获将同一个用户的订单的不同商品拆成多个订单。而 Pull 则是去订阅 Push 发出的异步消息，处理相关的任务。
事件溯源
解决的问题
让我们看到某个数据的状态。
事件回放
只需要追加不可修改的数据操作事件而不保存最终状态。这保留了可以启动补偿操作的完整记录和历史记录。
事件重播
修改了某些逻辑之后需要做数据的修正时只需要将所有相关事件重播一边即可。
事件可变性
事件使用只追加的方式进行存储等操作。
事件记录
事件只描述以发生的操作以及其代表的操作所需的相关数据，其不会直接更新数据存储。
结合异步处理
让整个系统进行任务的统筹安排、批量处理。
异步处理分布式事务
一致性
现实生活中需要用到强一致性的场景并不多。
交易凭证
一个事务做 A 和 B 两件事，首先做 A 并记录下 A 操作的凭证，再通过 A 的凭证去进行 B 的操作。
注意点
- 需要保存好凭证，不然事务没办法进行；
- 凭证处理幂等性，确保在进行重试时只有一次真正的处理；
- 事务失败的时候，做补偿事务处理。
异步处理设计要点
事件驱动和事件溯源是两个比较关键的技术。
故障导致的问题
消息丢失，没收到通知，或通知收到了没处理。办法是任务处理完成后给发起方回传状态，确保没有遗漏。
幂等性支持
在发起方重做超时没有回传状态的任务时，需要处理的一方支持幂等性。发起方的行为类似于对账。
整体业务事务问题
在处理任务失败时，需要回滚，并进行补偿事务的流程。
是否适合异步处理
不是所有的业务都适合异步处理，特别是需要强一致性的地方。
任务积压情况
在任务积压的情况下要能快速或自动的进行扩容操作，否则可能会处理不过来并导致系统奔溃。
异步处理本质
将被动的任务处理变成主动的任务处理。
《性能设计篇之“数据库扩展”》
读写分离 CQRS
适用于读多写少的场景。
优点
- 实现容易。主从配置和服务框架的读写分离比较成熟；
- 把业务隔离。一个服务对数据库造成的影响不会波及其他服务；
- 均分读压力，读操作消耗 CPU。
缺点
- 主库出问题的话，所有服务都没办法进行写操作；
- 库间数据非实时同步，强一致读操作需要访问主库。
CQRS / 命令与查询职责分离
CQRS 是 Command and Query Responsibility Segregation。用户的操作分成两种：
- Command：写操作，增、删以及改；
- Query：读操作，查。
语义区分
- Command 会改变数据但不返回结果数据，而只返回执行状态；
- Query 不会改变数据，只返回结果数据。
语义区分好处
- 分工明确；
- 提高系统性能、可扩展性以及安全性；
- 逻辑清晰；
- 从数据驱动（Data-Driven）转变成任务驱动（Task-Driven）以及事件驱动（Event-Driven）。
将 Command 变成事件溯源（Event Sourcing）就只需要记录不可变更事件并借助回溯事件获取数据的状态。
分库分表 Sharding
影响数据库性能的两个大问题
数据库操作
借助 ElasticSearch 做关联查询，用 Hadoop 或其他数据分析应用来做报表分析。
数据库数据量
将数据库拆分成分布式存储。借助分库分表来实现。
两个关注点
分库策略
按规则数据库拆分成 N 个库：
- 按地理位置；
- 按日期；
- 按范围；
- 按哈希散列算法。
数据访问层
访问层中间件要能够解析 SQL 语句的能力，根据解析完毕的 SQL 来做路由操作。
分片策略
- 多租户：借助租户 ID 将他们隔开，按商家的 ID 划分；
- 数据种类：按商品库存分类划分，或按商家地域划分；
- 范围：按订单月份分表，可以快速检索和统计连续的数据；
- 哈希散列算法：按主键 % N 来划分，会遇到跨库跨表查询和事务以及哈希扩容问题。
分片模式注意点
- 要站在业务的角度而不是技术的角度去考虑如何做分片；
- 只考虑业务分片，不要用哈希散列，除非被迫。
数据库扩展设计重点
水平分片注意事项
- 需要定期重新平衡分片，保证均匀分布以及降低热点的可能性。需要开发用于快速重新平衡分片的工具和脚本；
- 借助索引表来进行分片。将数据的索引动态地记录在索引表中。在数据调度时更改索引表里该数据的位置；
- 通过并行方式从各个分片上提取数据并聚合成一个结果后返回。会增加数据访问逻辑的复杂性；
- 很难保证引用的完整性以及一致性，也即跨分片事务，尽量减少多个分片会受影响的操作。在必须跨分片改动数据时需要评估一致性以及是否采用两阶段提交方式；
- 做变更时，根据从生产环境拉的数据做好新的片分方式以及测试工作。
《性能设计篇之“秒杀”》
秒杀流程
用户角度
- 准备秒杀的着陆页（Landing Page），展示一个倒计时的按钮；
- 到时间点亮按钮，潜在用户可以对其进行点击操作；
- 需要做验证操作以防非人为抢单操作。
技术角度
- 前端不停的轮询查询后端看是否已准备就绪；
- 后端在前端的每一次轮询查询之后会返回一个准确的时间用以校对前端显示的时间；
- 当后端就绪时会返回一个地址；
- 地址将与按钮做关联；
- 如果在点击之后抢到库存，就进入支付页面，没抢到则返回秒杀已结束。
秒杀技术挑战
百万 TPS
百万并发会导致网站奔溃，网络带宽也不够用。理论上来说，百万 TPS 是需要非常多机器的。
热点数据
请求会集中在同一条数据库记录，分库分表也不会好转，因为这是单条热点数据。
秒杀解决方案
引入 CDN
让 CDN 来缓存这一个页面以供百万用户同时访问。
CDN 边缘节点
让几十上百的 CDN 边缘节点来均衡分担百万用户的请求。
统计数据
通过 CDN 节点上的服务来统计每个节点上的总用户数并回传至中心。
概率值
按照百分比划分可放行用户量，百万的 0.03% 就是 300。也就是一万里只有 300 人的请求会被放行，其余的请求会被丢弃并显示活动结束。
放行的数据量
百万用户的 0.03% 就是 300 个用户，产生的 TPS 是 300，这个并发量是可以处理的。
更多思考
适合使用边缘节点的场景
像双十一这样有各种复杂的业务逻辑以及第三方调用于一体的应用不适合用边缘节点。双十一需要考虑的方面：性能调整、性能规划、分布式弹力设计、性能测试、系统瓶颈、水平扩展。
适合使用边缘节点的场景
像外卖、共享单车、打车这些有地域特征的业务的一些简单业务逻辑就比较适合使用边缘节点。
《性能设计篇之“边缘计算”》
边缘计算的意义
趋势方面
数字化革命
将各种信息数字化，也就是将纸质数据存入计算机存储中。
硬件发展
各种硬件的处理速度增长很快，而价格也在下降。综合成本越来越低。
信息量以及数据量
信息和数据一直在增长，基础设施的综合指标也在增长，而价格也越来越亲民。
MB 时代
以新闻资讯为主的年代，内容都由服务供应商提供。
GB 时代
用户生成内容（UGC / User Generated Content）的时代，大部分内容由用户们来输出，像是论坛发帖、博客撰写、图片上传、视频分享等等。
TB 时代
移动互联网时代，大部分线下的服务像是外卖、打车、上门等服务都转成线上的形式。应用一般会收集用户的使用情况，服务器对数据进行归纳和总结。
PB 时代
人工智能时代，人脸识别等就需要硬件里类似于神经网络芯片的技术了。
成本方面
非线性成长
从支撑几十万用户到支撑上千万或上亿用户这过程所产生的成本不会呈线性增长。
增长后的投入比
- 十万用户时只需要 10 台服务器来处理百级 QPS；
- 百万用户时只需要 50 台服务器来处理千级 QPS；
- 千万用户时需要 700 台服务器来处理十万级 QPS；
- 亿级用户时需要上万台服务器来处理百万级 QPS。
边缘计算业务场景
实时响应
响应本地请求，例如人脸门禁、共享单车开锁。
业务逻辑单一
简单的业务逻辑，例如秒杀、抢红包等业务场景。
收集并结构化数据
例如将视频中的车牌信息转成文字并回传至服务器。
实时设备监控
线下设备的数据采集和监控。
去中心化应用
服务发现，让本地设备之间进行 P2P 通讯。
云资源调度
例如允许用户用不同厂商的云存储、厂商不同但功能相同的 API（第三方支付）。
云资源聚合
例如将语音转文字和语义识别的接口相结合并聚合出语音语义识别的接口来简化开发成本。
边缘计算关键技术
应用程序接口网关
可以参考之前的文章《01.10 Day 26 - 管理设计篇之“网关模式”》
无服务器/函数为服务 / Serverless/FaaS
将函数服务化，写一个函数，发布之后就可以在别处进行调用。
末了
重新总结了一下文中提到的内容：加速数据访问、典型的缓存模式、Cache Aside 更新模式、Read/Write Through 更新模式、Write Behind Caching 更新模式、各模式的优缺点、缓存设计重点、缓存集群、数据一致性、LRU 锁竞争、爬虫问题、异步通讯、提高系统稳定性及容错能力、统筹任务、提高系统吞吐量、异步通讯设计、推拉结合模型‘配合事件溯源、存储事务一致性、异步处理事务一致性、最终一致性、异步处理设计要点、秒杀业务流程、技术挑战、解决方案、抢车票问题、双十一问题、高并发架构、CDN 边缘节点计算、适合使用边缘节点的场景、边缘计算的意义、因发展趋势而新生的产物、大数据中心成本问题、边缘计算降低成本、边缘计算业务场景、边缘计算关键技术。
