共计 4640 个字符，预计需要花费 12 分钟才能阅读完成。
欢迎大家前往腾讯云 + 社区，获取更多腾讯海量技术实践干货哦~
本文由 mariolu 发表于云 + 社区专栏
序言（初衷）
设计该系统初衷是基于描绘业务（或机器集群）存储模型，分析代理缓存服务器磁盘存储与回源率的关系。系统意义是在腾讯云成本优化过程中，量化指导机房设备扩容。前半部分是介绍背景，对 CDN 缓存模型做一些理论思考。后半部分会实际操作搭建一个微型但是五脏俱全的分布式通用系统架构，最后赋予该系统一些跟背景相关的功能，解决成本优化中遇到的实际问题。
缓存服务器存储模型架构（背景）：
图 1 存储模型
腾讯 CDN 的线上路由是用户à分布于各地区各运营商的 OC->SOC->SMid-> 源站。各个层级节点部署的都是缓存服务器。来自用户的部分请求流量命中服务器，另一部分产生回源流量。
随着业务带宽自然增长，用户端带宽增长，假设业务回源率不变的情况下，磁盘缓存淘汰更新（淘汰）速率变快，表现为以下业务瓶颈（iowait 变高、回源带宽变高，由于磁盘空间大小受限的缓存淘汰导致回源率变高）。
为了说明这个原理。我们假设两个极端：一个是设备磁盘容量无限大，业务过来的流量缓存只受源站缓存规则受限。只要缓存没过期，磁盘可以无限缓存，回源流量只需要首次访问的流量，所以这个回源量（率）只跟业务特性（重复率）有关系。另一个极端是磁盘极限小（归零），那么无论业务设置缓存是否过期，客户端访问量都是 1 比 1 的回源量。假设业务平均的缓存周期是 1 个小时。那么这 1 个小时的首次缓存带宽（同一 cache key 的多次访问，我们认为是一次）将是这个硬盘的所需要的空间。这个大小是合理的，可以保证磁盘足够容纳业务的量。假设这个量达不到，或者本来达到了，但是由于业务自然增长了，1 个小时内地首次缓存带宽变多，硬盘空间也不够用。
设备扩容是个解决办法。但是压测系统在这之前，没有客观数据证明需要扩容多大设备。或者扩容多少设备没有进行灰度验证，设备到位拍脑袋直接线上部署机器。我们在实验机器进行线上日志的重放，模拟出存储模拟曲线，来指导线上机房合理的设备存储。这就是建设重放日志系统的意义。
麻雀虽小，五脏俱全的重放日志模型（总览）
这一章，我们定义了下列模块：
模拟日志服务器：下载线上某个机房的一段时间周期的访问日志。一个日志存放 10 分钟访问记录。机房有几台机器就下载几份日志。日志服务器同时提供任务分片信息的查询服务。假设我们需要重放任务 id 为 pig_120t 的任务切片。下图既为任务切片详情。
图 2 日志服务器的日志分片文件
任务控制器：启动任务或者结束任务总开关。任务分配均匀分配给具体的肉鸡和代理服务器。插入任务到 Task Pool 中，收集服务端的实时总流量、回源流量、总请求次数和回源次数数据并插入到回源率结果数据表。
肉鸡：轮询 Task Pool 的任务表。如果有任务，则按照任务明细（时间、线上机房 ip）向日志服务器请求下载该分片的日志。重放请求到指定的代理服务器。
代理服务端：提供实时回源数据查询服务。并且安装 nws 缓存服务器等组件，该机器等同于线上机房的软件模块。
实时展示界面：可随时查看实时回源率和一些任务异常状态信息。
图 3 为客户端和服务端的互动图。图 4 是任务控制端在任务进行中和其他模块的联动过程。
图 3 肉鸡和代理服务端的架构
图 4 控制端的任务联动过程
分布式系统特点
日志重放模型核心是一个高性能压测系统，但是需要添加一些逻辑：日志下载、日志分析重构、结果数据收集、数据上报展示。分布式系统核心是：是否做到了可拓展、可恢复、简易搭建、容错、自动化。以下内容会一一展开。
先说说高性能：在一个通用模型中。我们模拟线上日志，这个系统要做到高效、因为我们的重放日志速度要比线上的 qps 还要快。机器的重放速度决定了分析结果的速度。同时更快的速度，所需要的肉鸡资源更少。笔者在 python 各个 url 请求库和 golang 中，最终敲定使用了 golang 实现肉鸡。golang 做到了和原生 c +epoll 一样快的速度，但是代码实现容易多了。理论上我们对一台做过代理端性能瓶颈分析。线上日志比模拟日志更复杂，qps 适度下降是必然的。Golang 这个客户端达到预期目标。
可扩展：在我们可能会随时增加模拟机器集群的肉鸡数量，或者更多的闲置代理服务器资源加入压测任务。所以系统在可用机器数据表随时加入新的机器。
图 5 系统的动态可扩展
可恢复：分布式系统不同于单机模式。不能避免可能有各种故障，有时候系统部分节点出错了，我们更倾向于不用这个节点，而不是继续使用未处理完成的结果。即非 0 即 1，无中间状态。还有分布式系统网络传输延迟不可控。所以压测系统设计了一套容错机制：包括心跳检测失败，自动在数据表剔除肉鸡服务端。接口异常容错。超时过期未完成任务去除。crontab 定时拉取退出进程等。
简易搭建：使用 ajs 接口，和批处理安装脚本。自动化部署肉鸡和服务端。配置 dns 解析 ip（日志服务器，任务池、回源率结果所在的数据库 ip），tcp time_wait 状态的复用，千万别忘了还有一些系统限制放开（放开 ulimit fd limit，这里设置 100000，永久设置需要编辑 /etc/security/limits.conf）。如果肉鸡有依赖程序运行库需要同时下载。在肉鸡机器下载肉鸡客户端和配置、在服务端机器下载服务端和配置，下载定时拉起程序脚本，并添加到 crontab 定时执行。以上都用批处理脚本自动执行。
一些设计范式的思考
Single-productor and Multi-consumer
在肉鸡客户端的设计中：读日志文件一行一条记录，添加到消息管道，然后多个执行 worker 从消息管道取 url，执行模拟请求。消息管道传送的是一条待执行的日志 url。IO 消耗型程序指的是如果 consumer 执行访问日志并瞬间完成结果，但是 productor 需要对日志进行复杂的字符串处理（例如正则之类的），那么它下次取不到数据，就会被管道 block 住。另外一种是 CPU 消耗型程序，如果日志 url 已经预先处理好了，productor 只是简单的 copy 数据给消息管道。而 consumer 访问 url，经过不可预知的网络延迟。那么多个 consumer（因为是包括网络访问时间，consumer 个数设计超过 cpu 核数，比如 2 倍）同时访问，读端速度慢于写端数度。在对一个日志文件进行实验，我们发现处理 18w 条记录日志的时间是 0.3s，而执行完这些 url 的访问任务则需要 3 分钟。那么很显然这是一个 CPU 消耗性进程。如果是 IO 消耗型的程序。Golang 有种叫 fan out 的消息模型。我们可以这样设计：多个读端去读取多个 chan list 的 chan，一个写端写一个 chan。Fanout 则将写端的 chan，循环写到 chan list 的 chan 中。
Map-reduce
我们有时会做一个地理位置一个运营商的机房日志分析。一个机房包含数台机器 ip。合理的调度多个肉鸡客户端并行访问日志，可以更快速得到合并回源率数据。
并行机制，经典的 map-reduce，日志文件按机房机器 ip 纬度切片分发任务，启动 N 个肉鸡同时并行访问，等最后一台肉鸡完成任务时，归并各个肉鸡数据按成功请求数量、成功请求流量、失败请求数量、失败请求流量等方式做统计。同时用于和线上日志做校样。这里的 mapper 就是肉鸡，产生的数据表，我们按照关注的类型去提取就是 reducer。
简化的 map-reducer（不基于分布式文件系统），map 和 reduce 中间的数据传递用数据表实现。每个 mapper 产生的日志数据先放在本地，然后再上报给数据表。但是数据表大小的限制，我们只能上传头部访问 url。所以如果用这个办法实现，数据是不完整的，或者不完全正确的数据。因为也许两台肉鸡合并的头部数据正好就包括了某肉鸡未上传的日志（该日志因为没有到达单机肉鸡访问量 top 的标准）。
那么如何解决这个问题呢，根本原因在于汇总数据所在的文件系统是本地的，不是分布式的（hadoop 的 hdfs 大概就是基于这种需求发明的把）。如果是状态码纬度，这种思路是没问题的，因为 http 状态码总量就那么少。那么如果是 url 纬度，比如说某机房给单肉鸡的单次任务在 10 分钟的 url 总数据量达到 18 万条。只看日志重复数 >100 的肉鸡数据。这样误差最大值是 100* 肉鸡数，所以对于 10 台肉鸡的机房，只要是综合合并结果 >1000。都是可信任的。如果是域名纬度，少数头部客户流量占比大多数带宽。这也就是所谓的 hot-key，少数的 hot-key 占据了大多数比例的流量。所以域名纬度时，这个时候可以把关注点缩放在指定域名的 url 列表。如果本地上报给数据表的数据量太大，url 也可以考虑进行短地址压缩。当然如果不想弯道超车的话，需要硬解决这个问题，那可能得需要 hdfs 这种分布式文件系统。
Stream-Processing
我们进行日志客户端系统，需要向日志服务器下载此次任务所需要的日志（一般是一个机器 10 分钟的访问日志）。首先本地日志会去任务服务器查询重放任务。接着去日志服务器下载。如果该模拟集群是在 DC 网络组建，那么下载一个 10 分钟（约 150M 左右的文件）日志几乎在 1 两秒内搞定，但是如果这个分布式系统是组建于 OC 网络，那么 OC 网络的肉鸡服务器要去 DC（考虑机房可靠性，日志服务器架设在 DC 网络）下载，经过 nat 转化内网到外网，下载则需要 10s 左右。如果为了等待日志服务器下载完，也是一笔时间开销。
在分布式系统中，所谓的 stream-processing，和 batch processing 不同的是，数据是无边界的。你不知道什么时候日志下载完。而 batch processing 的前后流程关系，好比生产流水线的工序，前一道完成，后一道才开始，对于后一道是完全知道前一道的输出结果有多少。
所谓的流式处理则需要在前一道部分输出结果到达时，启动后一道工序，前一道工序继续输出，后一道则需要做出处理事件响应。后一道需要频繁调度程序。
消息系统（message broker）：前一道的部分输出，输入给消息系统。消息系统检测到是完整的一条日志，则可以产生后一道工序的输入。这里我们会碰到一个问题。下载日志的速度（10s）会远远快于执行重放这些日志的速度（3min）。按照一个消息系统可能的动作是：无 buffer 则丢弃，按照队列缓存住，执行流控同步后一道工序和前一道工序的匹配速度。这里我们选择了按照队列缓存住这个方案。当然在一个严谨的分布式数据库设计，message broker 是一个能考率到数据丢失的节点。Broker 会把完整数据发给后道工序，同时会把 buffer 数据缓存到硬盘备份，以防程序 core dump。如果对于慢速前道工序，可以进行综合方案配置，丢弃或者流控。这里消息 broker 不同于数据库，他的中间未处理数据是暂时存储，处理过的消息要清除存储。
总结
当然：现实中的生产线的分布式系统会远比这个复杂，但是本文实现的从 0 到 1 的迷你麻雀分布式系统有一定的实践意义。它不是一蹴而就的，不断地版本迭代。当然该系统也完成了作者的 kpi- 存储模型分析，在中途遇到问题时，进行的设计思考和改良，在此总结分享给大家。
问答文字识别在格式上有什么要求？相关阅读原来你是这样的 http2 我是怎么一步步用 go 找出压测性能瓶颈 HTTP/ 2 之服务器推送 (Server Push) 最佳实践【每日课程推荐】机器学习实战！快速入门在线广告业务及 CTR 相应知识