分布式

什么是日志?日志就是按照时间顺序追加的、完全有序的记录序列，其实就是一种特殊的文件格式，文件是一个字节数组，而这里日志是一个记录数据，只是相对于文件来说，这里每条记录都是按照时间的相对顺序排列的，可以说日志是最简单的一种存储模型，读取一般都是从左到右，例如消息队列，一般是线性写入log文件，消费者顺序从offset开始读取。由于日志本身固有的特性，记录从左向右开始顺序插入，也就意味着左边的记录相较于右边的记录“更老”, 也就是说我们可以不用依赖于系统时钟，这个特性对于分布式系统来说相当重要。日志的应用日志在数据库中的应用日志是什么时候出现已经无从得知，可能是概念上来讲太简单。在数据库领域中日志更多的是用于在系统crash的时候同步数据以及索引等，例如MySQL中的redo log，redo log是一种基于磁盘的数据结构，用于在系统挂掉的时候保证数据的正确性、完整性，也叫预写日志，例如在一个事物的执行过程中，首先会写redo log，然后才会应用实际的更改，这样当系统crash后恢复时就能够根据redo log进行重放从而恢复数据(在初始化的过程中，这个时候不会还没有客户端的连接)。日志也可以用于数据库主从之间的同步，因为本质上，数据库所有的操作记录都已经写入到了日志中，我们只要将日志同步到slave，并在slave重放就能够实现主从同步，这里也可以实现很多其他需要的组件，我们可以通过订阅redo log 从而拿到数据库所有的变更，从而实现个性化的业务逻辑，例如审计、缓存同步等等。日志在分布式系统中的应用分布式系统服务本质上就是关于状态的变更，这里可以理解为状态机，两个独立的进程(不依赖于外部环境，例如系统时钟、外部接口等)给定一致的输入将会产生一致的输出并最终保持一致的状态，而日志由于其固有的顺序性并不依赖系统时钟，正好可以用来解决变更有序性的问题。我们利用这个特性实现解决分布式系统中遇到的很多问题。例如RocketMQ中的备节点，主broker接收客户端的请求，并记录日志，然后实时同步到salve中，slave在本地重放，当master挂掉的时候，slave可以继续处理请求，例如拒绝写请求并继续处理读请求。日志中不仅仅可以记录数据，也可以直接记录操作，例如SQL语句。日志是解决一致性问题的关键数据结构，日志就像是操作序列，每一条记录代表一条指令，例如应用广泛的Paxos、Raft协议，都是基于日志构建起来的一致性协议。日志在Message Queue中的应用日志可以很方便的用于处理数据之间的流入流出，每一个数据源都可以产生自己的日志，这里数据源可以来自各个方面，例如某个事件流(页面点击、缓存刷新提醒、数据库binlog变更)，我们可以将日志集中存储到一个集群中，订阅者可以根据offset来读取日志的每条记录，根据每条记录中的数据、操作应用自己的变更。在此我向大家推荐一个架构学习交流群。交流学习群号：897889510 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多这里的日志可以理解为消息队列，消息队列可以起到异步解耦、限流的作用。为什么说解耦呢？因为对于消费者、生产者来说，两个角色的职责都很清晰，就负责生产消息、消费消息，而不用关心下游、上游是谁，不管是来数据库的变更日志、某个事件也好，对于某一方来说我根本不需要关心，我只需要关注自己感兴趣的日志以及日志中的每条记录。我们知道数据库的QPS是一定的，而上层应用一般可以横向扩容，这个时候如果到了双11这种请求突然的场景，数据库会吃不消，那么我们就可以引入消息队列，将每个队数据库的操作写到日志中，由另外一个应用专门负责消费这些日志记录并应用到数据库中，而且就算数据库挂了，当恢复的时候也可以从上次消息的位置继续处理(RocketMQ和Kafka都支持Exactly Once语义)，这里即使生产者的速度异于消费者的速度也不会有影响，日志在这里起到了缓冲的作用，它可以将所有的记录存储到日志中，并定时同步到slave节点，这样消息的积压能力能够得到很好的提升，因为写日志都是有master节点处理，读请求这里分为两种，一种是tail-read，就是说消费速度能够跟得上写入速度的，这种读可以直接走缓存，而另一种也就是落后于写入请求的消费者，这种可以从slave节点读取，这样通过IO隔离以及操作系统自带的一些文件策略，例如pagecache、缓存预读等，性能可以得到很大的提升。在此我向大家推荐一个架构学习交流群。交流学习群号：575745314 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多。分布式系统中可横向扩展是一个相当重要的特性，加机器能解决的问题都不是问题。那么如何实现一个能够实现横向扩展的消息队列呢? 假如我们有一个单机的消息队列，随着topic数目的上升，IO、CPU、带宽等都会逐渐成为瓶颈，性能会慢慢下降，那么这里如何进行性能优化呢?1.topic/日志分片，本质上topic写入的消息就是日志的记录，那么随着写入的数量越多，单机会慢慢的成为瓶颈，这个时候我们可以将单个topic分为多个子topic，并将每个topic分配到不同的机器上，通过这种方式，对于那些消息量极大的topic就可以通过加机器解决，而对于一些消息量较少的可以分到到同一台机器或不进行分区2.group commit，例如Kafka的producer客户端，写入消息的时候，是先写入一个本地内存队列，然后将消息按照每个分区、节点汇总，进行批量提交，对于服务器端或者broker端，也可以利用这种方式，先写入pagecache，再定时刷盘，刷盘的方式可以根据业务决定，例如金融业务可能会采取同步刷盘的方式。3.规避无用的数据拷贝4.IO隔离结语日志在分布式系统中扮演了很重要的角色，是理解分布式系统各个组件的关键，随着理解的深入，我们发现很多分布式中间件都是基于日志进行构建的，例如Zookeeper、HDFS、Kafka、RocketMQ、Google Spanner等等，甚至于数据库，例如Redis、MySQL等等，其master-slave都是基于日志同步的方式，依赖共享的日志系统，我们可以实现很多系统: 节点间数据同步、并发更新数据顺序问题(一致性问题)、持久性(系统crash时能够通过其他节点继续提供服务)、分布式锁服务等等，相信慢慢的通过实践、以及大量的论文阅读之后，一定会有更深层次的理解。

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由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相应知识