同步

这篇文章咱们来聊一个很简略，然而很多人往往分不清的一个问题，同步异步、阻塞非阻塞到底怎么辨别？ 开篇先问大家一个问题：IO多路复用是同步IO还是异步IO？ 先思考一下，再持续往下读。 巨著《Unix网络编程》将IO模型划分为5种，别离是 阻塞IO非阻塞IOIO复用信号驱动IO异步IO集体认为这么分类并不是很好，因为从字面上了解阻塞IO和非阻塞IO就曾经是数学意义上的选集了，怎么又冒出了后边3种模型，会给初学者带来一些困扰。 接下来进入注释。 文章首发于公众号：蝉沐风的码场1. 一个简略的IO流程让咱们先摒弃咱们本来熟知的各种IO模型流程图，先看一个非常简单的IO流程，不波及任何阻塞非阻塞、同步异步概念的图。 客户端发动零碎调用之后，内核的操作能够被分成两步： 期待数据 此阶段网络数据进入网卡，而后网卡将数据放到指定的内存地位，此过程CPU无感知。而后通过网卡发动硬中断，再通过软中断，内核线程将数据发送到socket的内核缓冲区中。 数据拷贝 数据从socket的内核缓冲区拷贝到用户空间。 2. 阻塞与非阻塞阻塞与非阻塞在API上区别在于socket是否设置了SOCK_NONBLOCK这个参数，默认状况下是阻塞的，设置了该参数则为非阻塞。 2.1 阻塞假如socket为阻塞模式，则IO调用如下图所示。 当处于运行状态的用户线程发动recv零碎调用时，如果socket内核缓冲区内没有数据，则内核会将以后线程投入睡眠，让出CPU的占用。 直到网络数据达到网卡，网卡DMA数据到内存，再通过硬中断、软中断，由内核线程唤醒用户线程。 此时socket的数据曾经准备就绪，用户线程由用户态进入到内核态，执行数据拷贝，将数据从内核空间拷贝到用户空间，零碎调用完结。此阶段，开发者通常认为用户线程处于期待（称为阻塞也行）状态，因为在用户态的角度上，线程的确啥也没干（尽管在内核态干得累死累活）。 2.2 非阻塞如果将socket设置为非阻塞模式，调用便换了一副光景。 用户线程发动零碎调用，如果socket内核缓冲区中没有数据，则零碎调用立刻返回，不会挂起线程。而线程会持续轮询，直到socket内核缓冲区内有数据为止。 如果socket内核缓冲区内有数据，则用户线程进入内核态，将数据从内核空间拷贝到用户空间，这一步和2.1大节没有区别。 3. 同步与异步同步和异步次要看申请发起方对音讯后果的获取形式，是被动获取还是被动告诉。区别次要体现在数据拷贝阶段。 3.1 同步同步咱们其实曾经见识过了，2.1节和2.2节中的数据拷贝阶段其实都是同步！ 注：把同步的流程画在阻塞和非阻塞的第二阶段，并不是说阻塞和非阻塞的第二阶段只能搭配同步伎俩！同步指的是数据达到socket内核缓冲区之后，由用户线程参加到数据拷贝过程中，直到数据从内核空间拷贝到用户空间。 因而，IO多路复用，对于应用程序而言，依然只能算是一种同步，因为应用程序依然破费工夫期待IO后果，期待期间CPU要么用于遍历文件描述符的状态，要么用于休眠期待事件产生。 以select为例，用户线程发动select调用，会切换到内核空间，如果没有数据准备就绪，则用户线程阻塞到有数据来为止，select调用完结。完结之后用户线程获取到的只是「内核中有N个socket曾经就绪」的这么一个信息，还须要用户线程对着1024长度的描述符数组进行遍历，能力获取到socket中的数据，这就是同步。 举个生存中的例子，咱们给物流客服打电话询问咱们的包裹是否已达到，如果未达到，咱们就先睡一会儿，等到了之后客服给咱们打电话把咱们喊起来，而后咱们屁颠屁颠地去快递驿站拿快递。这就是同步阻塞。 如果咱们不想睡，就始终打电话问，直到包裹到了为止，而后再屁颠屁颠地去快递驿站拿快递。这就是同步非阻塞。 问题就是，能不能间接让物流的人把快递间接送到我家，别让我本人去拿啊！这就是异步。 3.2 现实的异步咱们现实中的完满异步应该是用户过程发动非阻塞调用，内核间接返回后果之后，用户线程能够立刻解决下一个工作，只须要IO实现之后通过信号或回调函数的形式将数据传递给用户线程。如下图所示。 因而，在现实的异步环境下，数据筹备阶段和数据拷贝阶段都是由内核实现的，不会对用户线程进行阻塞，这种内核级别的改良天然须要操作系统底层的性能反对。 3.3 事实的异步事实比现实要骨感一些。 Linux内核并没有太惹眼的异步IO机制，这难不倒各路大神，比方Node的作者采纳多线程模仿了这种异步成果。 比方让某个主线程执行次要的非IO逻辑操作，另外再起多个专门用于IO操作的线程，让IO线程进行阻塞IO或者非阻塞IO加轮询的形式来实现数据获取，通过IO线程和主线程之间通信进行数据传递，以此来实现异步。 还有一种计划是Windows上的IOCP，它在某种程度上提供了现实的异步，其外部仍然采纳的是多线程的原理，不过是内核级别的多线程。 遗憾的是，用Windows做服务器的我的项目并不是特地多，期待Linux在异步的畛域上获得更大的提高吧。 4. 异步阻塞？说完了同步异步、阻塞非阻塞，一个很天然的操作就是对他们进行排列组合。 同步阻塞同步非阻塞异步非阻塞异步阻塞然而异步阻塞是什么鬼？依照上文的解释，该IO模型在第一阶段应该是用户线程阻塞，期待数据；第二阶段应该是内核线程（或专门的IO线程）解决IO操作，而后把数据通过事件或者回调的形式告诉用户线程，既然如此，那么第一步的阻塞齐全没有必要啊！非阻塞调用，而后持续解决其余工作岂不是更好。 因而，压根不存在异步阻塞这种模型哦～ 5. 千万分清主语是谁最初给各位提个醒，和他人探讨阻塞非阻塞的时候千万要带上主语。 如果我问你，epoll是阻塞还是非阻塞？你怎么答复？ 应该说，epoll_wait这个函数自身是阻塞的，然而epoll会将socket设置为非阻塞。因而单纯把epoll认为阻塞是太委屈它，认为其是非阻塞又抬举它。 具体对于epoll的阐明能够参见IO多路复用中的epoll局部。 完～

作者：京东科技 文涛背景金融社区优惠文章是基于京东商城优惠商品批量化主动生成的，每日通过不同的渠道获取到待生成的SKU列表，并依据条件生成优惠文章。 然而，生成优惠文章之后续衍生问题： 该商品无优惠了，对应文章须要做勾销举荐或下架解决，怎么能更快的晓得该商品无优惠了呢？ 计划介绍计划比照计划1承接该商品所有变更信息的音讯，产生变更后二编文章。 长处： 实时，一旦变更立即晓得并更新文章。 毛病： 1 开销大，是要承接的音讯多，可能100台机器也不肯定能承接（亿级变更）。 2 耦合高，须要对接的业务方多，全副对接须要很长的周期及人力，同时对方产生业务变更须要通过人员同步更新逻辑。 计划2通过工作轮训文章，调内部接口判断该商品是否有优惠，之后做相应的解决。 长处： 1 业务模型较简略，只须要判断是否有优惠或优惠变更即可。 2 优惠侧投入较小，只须要投入调度工作的机器即可。 毛病： 不实时，数据量大了，对工作的实时性是个挑战。 计划3针对形式2的毛病，咱们推出了【可伸缩主动工作】 + 【首次曝光监测】的组合模式。 即本人实现散布式调度加强，进步数据处理能力，进步调度鲁棒性、自动化等能力，同时采纳首次曝光监测的形式，利用用户拜访文章时判断是否有优惠，并做相应勾销举荐或文章下线解决 长处： 1 较实时，第一批被举荐推到C端用户的文章有可能会看到无优惠兜底计划，其它人便不再被推送。 2 形式2的长处 毛病： 须要实现可伸缩主动工作组件 至此，如何保障千万量级的优惠文章监测优惠变更不至于周期太长成了难点。 接下来介绍可伸缩工作组件，是如何解决上述问题的： 可伸缩工作组件要害能力咱们心愿组件领有的能力 •工作自动化，完结主动从新执行 •工作鲁棒性强，意外中断可从断点处从新唤起 •工作可分治，可利用线程池及分布式集群将整体工作拆分成多个子工作执行 •工作可扩大，具备新工作探测能力 •工作可熔断，能够监测间断异样并终止执行 实现名词解释工作指令：触发某个工作的一条指令信息 工作开关：管制整体工作执行状况，如：进行执行，分时段执行等 redo指令：当工作执行实现后，收回的重做指令 工作监测：负责监测工作执行状况，依据工作状态解决工作 实现思路是否复用现有中间件？如：分布式工作，音讯队列等 答案是能够，并且集体感觉最好是优先利用中间件能力，并将中间件的能力定义成组件的可扩大能力，不便中间件替换，进步组件的通用性 如果应用现有中间件实现该如何实现？ 传统思路： 分布式工作负责查问全量文章，将查问后果发送MQ，消费者生产单条音讯，并进行业务解决 那么问题来了， 1 查问一轮工作须要多长时间呢？随着文章量的减少，调度周期设置多少适合呢？ 2 MQ的音讯将海量 显然这种形式不太适宜数据量大的状况 那么咱们的思路是： 1 将散布式调度形象成一个心跳监测模块，用于监测工作状态，以及探测新工作，这样工作执行周期固定10min即可，工作执行工夫也不会太长（理论执行工夫200ms左右） 2 将MQ形象成工作指令的载体，用于发送指令，接管指令，利用分布式的能力解决工作 3 将千万级的一次查问，拆分成多个查问，放大单次指令执行的周期，将千万级文章信息同步至ES，应用ES的滚动查问能力，在执行单次工作时，可滚动查问10-20万的文章 4 将分布式共识组件用作开关能力，用于管制组件执行，在大促或上游压力过高时动态控制工作执行 5 将Redis用于工作信息存储和分布式指令防重 至此，咱们应用到了散布式调度、音讯队列、Redis、分布式共识、ES等中间件能力。 ...

DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现各种异构数据源之间高效的数据同步功能。最近，阿里云cassandra团队为datax提供了cassandra读写插件，进一步丰富了datax支持的数据源，可以很方便实现cassandra之间以及cassandra与其他数据源之间的数据同步。本文简单介绍如何使用datax同步cassandra的数据，针对几种常见的场景给出配置文件示例，还提供了提升同步性能的建议和实测的性能数据。 datax快速入门使用datax同步数据的方法很简单，一共只需要三步： 部署datax。编写同步作业配置文件。运行datax，等待同步作业完成。datax的部署和运行都很简单，可以通过datax官方提供的下载地址下载DataX工具包，下载后解压至本地某个目录，进入bin目录，即可运行同步作业： $ cd {YOUR_DATAX_HOME}/bin$ python datax.py {YOUR_JOB.json}同步作业的配置格式可以参考datax文档。 一个典型的配置文件如下： { "job": { "content": [ { "reader": { "name": "streamreader", "parameter": { "sliceRecordCount": 10, "column": [ { "type": "long", "value": "10" }, { "type": "string", "value": "hello，你好，世界-DataX" } ] } }, "writer": { "name": "streamwriter", "parameter": { "encoding": "UTF-8", "print": true } } } ], "setting": { "speed": { "channel": 5 } } }}一个同步作业的配置文件主要包括两部分，setting包括任务调度的一些配置，content描述同步任务的内容，里面包含reader插件的配置和writer插件的配置。例如我们需要从mysql同步数据到cassandra，那么我们只需要把reader配置为mysqlreader，writer配置为cassandrawriter，并提供相应的插件配置信息即可。在datax项目页面上面可以看到datax支持的插件列表，点击对应的链接就可以查看相关插件的文档了解插件需要的配置内容和格式要求。例如，cassandra插件的文档可点击如下链接：读插件 写插件。 以下列举几种常见的场景。 ...

组件的状态是一种保存、处理和使用给定组件内部信息的方法，并允许你实现其自身的逻辑。状态本身其实是JavaScript中一个简单的对象(Plain Old Java[Script] Object)，并且改变它是使组件重新进行渲染的几种方法之一。 这是React背后最基本的思路之一,但是它(状态)有一些使用起来很棘手的属性，可能会导致应用程序出现意外行为。 更新状态组件中的构造函数是唯一一个你可以直接写this.state的地方，而在其他地方你应该使用this.setState，setState将接受最终合并到组件当前状态的一个对象或方法作为参数。 虽然技术上可以通过直接写入this.state来改变状态，但它不会导致组件使用新数据重新渲染，并且通常会导致状态的不一致。 setState是异步的setState导致协调(重新渲染组件树的过程)的事实是基于下一个属性 — setState是异步的。这允许我们在单个范围内多次调用setState，而不是触发不需要重新渲染整个组件树。 这就是为什么在更新后没有在状态中看到新值的原因。 // assuming this.state = { value: 0 }this.setState({ value: 1});console.log(this.state.value); // 0React还会尝试将setState分组调用或批量调用到一个回调中，这会导致我们第一次“陷阱”。 // assuming this.state = { value: 0 };this.setState({ value: this.state.value + 1});this.setState({ value: this.state.value + 1});this.setState({ value: this.state.value + 1});上面所有的调用过程结束后，this.state.value的值是1,而不是我们所期望的3。为了解决这个问题 … setState接受一个方法作为它的参数如果你在setState中传入一个函数作为第一个参数，React将以 at-call-time-current状态来调用它，并期望你返回一个对象来合并到状态中。所以更新我们以上的代码： // assuming this.state = { value: 0 };this.setState((state) => ({ value: state.value + 1}));this.setState((state) => ({ value: state.value + 1}));this.setState((state) => ({ value: state.value + 1}));最终的结果将如我们所期望的this.state.value = 3，记住在将状态更新为值时始终使用此语法，该值是根据以前的状态计算的！ ...

概述并发编程，即多条线程在同一时间段内“同时”运行。 在多处理器系统已经普及的今天，多线程能发挥出其优势，如：一个8核cpu的服务器，如果只使用单线程的话，将有7个处理器被闲置，只能发挥出服务器八分之一的能力（忽略其它资源占用情况）。同时，使用多线程，可以简化我们对复杂任务的处理逻辑，降低业务模型的复杂程度。 因此并发编程对于提高服务器的资源利用率、提高系统吞吐量、降低编码难度等方面起着至关重要的作用。 以上是并发编程的优点，但是它同样引入了一个很重要的问题：线程安全。 什么是线程安全问题线程在并发执行时，因为cpu的调度等原因，线程会交替执行。如下图例子所示 public class SelfIncremental { private static int count; public static void main(String[] args) { Thread thread1 = new Thread(() -> { for (int i = 0; i< 10000; i++) { count++; System.out.println(count); } }); Thread thread2 = new Thread(() -> { for (int i = 0; i< 10000; i++) { count++; System.out.println(count); } }); thread1.start(); thread2.start(); }}执行完毕后count的值并不是每次都能等于20000，会出现小于20000的情况，原因是thread1和thread2可能会交替执行。 如图所示： t1时刻: thread1 读取到count=100t2时刻: thread2 读取到count=100t3时刻: thread1 对count+1t4时刻: thread2 对count+1t5时刻: thread1 将101写入countt5时刻: thread2 将101写入count因为count++ 不是一个原子操作，实际上会执行三步： ...

今天自己写小程序的时候，近乎被异步搞到崩溃，不停地嵌套回调（我知道 await 和 promise，但是我嫌promise写起来跟裹脚布似的，而await我怕有兼容性问题也从来没有试过）言归正传，将小程序的异步调用变为同步(以下教程适用于所有异步，只是给小程序做了一下封装)。原理：增加事件队列，采用事件回调来完成同步化 以下代码复制粘贴到控制台即可测试效果；这里直接写es6代码了,先写个定时器版本的方便测试与理解先写个无注释版本的，方便直接看代码 class Async{ constructor() { this.list = []; this.sock = false; } request(obj) { setTimeout(() => { console.log(obj); this.sock = false; if(this.list[0]) this.do(this.list.shift()); }, 1000) } do(requestObj, async) { if(!async) { return this.request(requestObj); } if(this.sock) { this.list.push(requestObj); }else { this.sock = true; this.request(requestObj); } } }-----------以下为注释版本----------- class Async{ constructor() { this.list = []; // 定义 执行队列 this.sock = false; // 判断是否有任务正在执行 } request(obj) { setTimeout(() => { console.log(obj); this.sock = false; // 重置为没有任务正在执行 if(this.list[0]) // 如果队列中还有任务，执行下一个任务 this.do(this.list.shift()); }, 1000) // 模拟一个异步，一秒后执行任务，执行完成后执行下一个异步任务 } do(requestObj) { if(this.sock) // 如果有任务在执行 this.list.push(requestObj); // 将当前任务其增加到任务队列 else { this.sock = true; // 否则开始执行当前任务并设定'有任务在执行' this.request(requestObj); } } } var x = new Async(); x.do({url: 1}); // 一秒后打印 url: 1 x.do({url: 2}); // 两秒后打印 url: 2但是同步只是异步无可奈何的选择，所以不能全部否决掉异步 ...

服务器192.168.0.248：本地服务器47.56.34.2：远程服务器目的将远程服务器数据同步到本地服务器 前提两台服务器安装rsync和crontabsyum install -y rsyncyum install -y crontabs设置免密登陆在本地服务器中执行# 产生keyssh-keygen -t rsa# 拷贝到远程服务器ssh-copy-id -i /root/.ssh/id_rsa.pub "-p22 root@47.56.34.2"# 免密登陆ssh -p 22 root@47.56.34.2执行命令进行文件同步rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/# 输出日志rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/ 1> /home/logs/rsync.log 2>&1采用crond定时同步# 在本地服务器上，定时同步0 2 * * * root /home/backup/script/auto_rsync.sh# 在远程服务器上，定时备份数据库0 2 * * * root /root/backup/script/auto_mysqldump.sh同步脚本备份数据库脚本auto_mysqldump.sh#!/bin/bashDATE="$(date +%F)"backup_dir=/root/backup/databasemysqldump -uroot -pAsdf@123 pms > ${backup_dir}/pms-${DATE}.sql# 只保留前100个lPkgList=($(ls "${backup_dir}" | sort -nr))for ((j=100; j<${#lPkgList[@]}; ++j)); do rm -rf "${backup_dir}/${lPkgList[$j]}"done备份文件脚本auto_rsync.sh#!/bin/bashrsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/ 1> /home/logs/rsync.log 2>&1 rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/backup/database /home/backup/database/ 1> /home/logs/rsync-database.log 2>&1 命令详细使用方法http://man.linuxde.net/rsync-v, --verbose 详细模式输出。-q, --quiet 精简输出模式。-c, --checksum 打开校验开关，强制对文件传输进行校验。-a, --archive 归档模式，表示以递归方式传输文件，并保持所有文件属性，等于-rlptgoD。-r, --recursive 对子目录以递归模式处理。-R, --relative 使用相对路径信息。-b, --backup 创建备份，也就是对于目的已经存在有同样的文件名时，将老的文件重新命名为~filename。可以使用--suffix选项来指定不同的备份文件前缀。--backup-dir 将备份文件(如~filename)存放在在目录下。-suffix=SUFFIX 定义备份文件前缀。-u, --update 仅仅进行更新，也就是跳过所有已经存在于DST，并且文件时间晚于要备份的文件，不覆盖更新的文件。-l, --links 保留软链结。-L, --copy-links 想对待常规文件一样处理软链结。--copy-unsafe-links 仅仅拷贝指向SRC路径目录树以外的链结。--safe-links 忽略指向SRC路径目录树以外的链结。-H, --hard-links 保留硬链结。-p, --perms 保持文件权限。-o, --owner 保持文件属主信息。-g, --group 保持文件属组信息。-D, --devices 保持设备文件信息。-t, --times 保持文件时间信息。-S, --sparse 对稀疏文件进行特殊处理以节省DST的空间。-n, --dry-run现实哪些文件将被传输。-w, --whole-file 拷贝文件，不进行增量检测。-x, --one-file-system 不要跨越文件系统边界。-B, --block-size=SIZE 检验算法使用的块尺寸，默认是700字节。-e, --rsh=command 指定使用rsh、ssh方式进行数据同步。--rsync-path=PATH 指定远程服务器上的rsync命令所在路径信息。-C, --cvs-exclude 使用和CVS一样的方法自动忽略文件，用来排除那些不希望传输的文件。--existing 仅仅更新那些已经存在于DST的文件，而不备份那些新创建的文件。--delete 删除那些DST中SRC没有的文件。--delete-excluded 同样删除接收端那些被该选项指定排除的文件。--delete-after 传输结束以后再删除。--ignore-errors 及时出现IO错误也进行删除。--max-delete=NUM 最多删除NUM个文件。--partial 保留那些因故没有完全传输的文件，以是加快随后的再次传输。--force 强制删除目录，即使不为空。--numeric-ids 不将数字的用户和组id匹配为用户名和组名。--timeout=time ip超时时间，单位为秒。-I, --ignore-times 不跳过那些有同样的时间和长度的文件。--size-only 当决定是否要备份文件时，仅仅察看文件大小而不考虑文件时间。--modify-window=NUM 决定文件是否时间相同时使用的时间戳窗口，默认为0。-T --temp-dir=DIR 在DIR中创建临时文件。--compare-dest=DIR 同样比较DIR中的文件来决定是否需要备份。-P 等同于 --partial。--progress 显示备份过程。-z, --compress 对备份的文件在传输时进行压缩处理。--exclude=PATTERN 指定排除不需要传输的文件模式。--include=PATTERN 指定不排除而需要传输的文件模式。--exclude-from=FILE 排除FILE中指定模式的文件。--include-from=FILE 不排除FILE指定模式匹配的文件。--version 打印版本信息。--address 绑定到特定的地址。--config=FILE 指定其他的配置文件，不使用默认的rsyncd.conf文件。--port=PORT 指定其他的rsync服务端口。--blocking-io 对远程shell使用阻塞IO。-stats 给出某些文件的传输状态。--progress 在传输时现实传输过程。--log-format=formAT 指定日志文件格式。--password-file=FILE 从FILE中得到密码。--bwlimit=KBPS 限制I/O带宽，KBytes per second。-h, --help 显示帮助信息。问题遇到ssh修改了默认的端口22不能免密钥登录解决方法： ...

KeyDB项目是从redis fork出来的分支。众所周知redis是一个单线程的kv内存存储系统，而KeyDB在100%兼容redis API的情况下将redis改造成多线程。 项目git地址：https://github.com/JohnSully/KeyDB 网上公开的技术细节比较少，本文基本是通过阅读源码总结出来的，如有错漏之处欢迎指正。 多线程架构线程模型KeyDB将redis原来的主线程拆分成了主线程和worker线程。每个worker线程都是io线程，负责监听端口，accept请求，读取数据和解析协议。如图所示： KeyDB使用了SO_REUSEPORT特性，多个线程可以绑定监听同个端口。每个worker线程做了cpu绑核，读取数据也使用了SO_INCOMING_CPU特性，指定cpu接收数据。解析协议之后每个线程都会去操作内存中的数据，由一把全局锁来控制多线程访问内存数据。主线程其实也是一个worker线程，包括了worker线程的工作内容，同时也包括只有主线程才可以完成的工作内容。在worker线程数组中下标为0的就是主线程。主线程的主要工作在实现serverCron，包括： 处理统计客户端链接管理db数据的resize和reshard处理aofreplication主备同步cluster模式下的任务链接管理在redis中所有链接管理都是在一个线程中完成的。在KeyDB的设计中，每个worker线程负责一组链接，所有的链接插入到本线程的链接列表中维护。链接的产生、工作、销毁必须在同个线程中。每个链接新增一个字段int iel; /* the event loop index we're registered with */用来表示链接属于哪个线程接管。KeyDB维护了三个关键的数据结构做链接管理： clients_pending_write：线程专属的链表，维护同步给客户链接发送数据的队列clients_pending_asyncwrite：线程专属的链表，维护异步给客户链接发送数据的队列clients_to_close：全局链表，维护需要异步关闭的客户链接分成同步和异步两个队列，是因为redis有些联动api，比如pub/sub，pub之后需要给sub的客户端发送消息，pub执行的线程和sub的客户端所在线程不是同一个线程，为了处理这种情况，KeyDB将需要给非本线程的客户端发送数据维护在异步队列中。同步发送的逻辑比较简单，都是在本线程中完成，以下图来说明如何同步给客户端发送数据： 如上文所提到的，一个链接的创建、接收数据、发送数据、释放链接都必须在同个线程执行。异步发送涉及到两个线程之间的交互。KeyDB通过管道在两个线程中传递消息： int fdCmdWrite; //写管道int fdCmdRead; //读管道本地线程需要异步发送数据时，先检查client是否属于本地线程，非本地线程获取到client专属的线程ID，之后给专属的线程管到发送AE_ASYNC_OP::CreateFileEvent的操作，要求添加写socket事件。专属线程在处理管道消息时将对应的请求添加到写事件中，如图所示： redis有些关闭客户端的请求并非完全是在链接所在的线程执行关闭，所以在这里维护了一个全局的异步关闭链表。 锁机制KeyDB实现了一套类似spinlock的锁机制，称之为fastlock。fastlock的主要数据结构有： struct ticket{ uint16_t m_active; //解锁+1 uint16_t m_avail; //加锁+1};struct fastlock{ volatile struct ticket m_ticket; volatile int m_pidOwner; //当前解锁的线程id volatile int m_depth; //当前线程重复加锁的次数};使用原子操作__atomic_load_2，__atomic_fetch_add，__atomic_compare_exchange来通过比较m_active=m_avail判断是否可以获取锁。fastlock提供了两种获取锁的方式： try_lock：一次获取失败，直接返回lock：忙等，每1024 * 1024次忙等后使用sched_yield 主动交出cpu，挪到cpu的任务末尾等待执行。在KeyDB中将try_lock和事件结合起来，来避免忙等的情况发生。每个客户端有一个专属的lock，在读取客户端数据之前会先尝试加锁，如果失败，则退出，因为数据还未读取，所以在下个epoll_wait处理事件循环中可以再次处理。 Active-ReplicaKeyDB实现了多活的机制，每个replica可设置成可写非只读，replica之间互相同步数据。主要特性有： 每个replica有个uuid标志，用来去除环形复制新增加rreplay API，将增量命令打包成rreplay命令，带上本地的uuidkey，value加上时间戳版本号，作为冲突校验，如果本地有相同的key且时间戳版本号大于同步过来的数据，新写入失败。采用当前时间戳向左移20位，再加上后44位自增的方式来获取key的时间戳版本号。结束语云数据库Redis版（ApsaraDB for Redis）是一种稳定可靠、性能卓越、可弹性伸缩的数据库服务。基于飞天分布式系统和全SSD盘高性能存储，支持主备版和集群版两套高可用架构。提供了全套的容灾切换、故障迁移、在线扩容、性能优化的数据库解决方案。 本文作者：羽洵阅读原文 本文为云栖社区原创内容，未经允许不得转载。

拔掉数据库的电源会怎样？假设我们拔掉数据库的电源会怎样？ 在日前举行的阿里云“企业级”云灾备解决方案发布会上，阿里云智能技术战略总监陈绪就来了一场现场“断电”演示，拔掉了数据库的电源。 （直播回放：https://yq.aliyun.com/live/1104/event） 猜猜现场发生了什么？ 数据丢失，业务瘫痪，企业资金受损？ 上述情况统统没有出现！没有出现任何数据丢失，也没有业务瘫痪，10秒后，上云企业的业务就完全恢复了。 那么这是如何实现的呢？ 在会上，阿里云智能数据库产品事业部技术总监天羽为大家全面解析《云时代，数据库新型灾备架构》，详细介绍了在混合云架构下，从异地备份、容灾、双活到统一管理的数据库一站式灾备解决方案。 有了云数据库新型灾备架构，即使断电又何妨？通过阿里云提供的DBS、DTS、HDM等服务，您的企业也可轻松构建灾备体系，做到“有备无患”。 墨菲定律 鸡蛋不能放在一个篮子里对于每个企业而言，数据库都是其最为核心的资产。但是单点故障是不可避免的，因此为了提升数据安全，需要做的就是数据冗余。 国家对于数据库灾难恢复能力也定义了相应的标准。对于位于等级2~3的一般业务而言，需要每天进行备份；对于位于等级4的重要业务而言，需要每天全量+增量备份；对于等级5的关键业务而言，要求数据丢失不能超过半个小时，并且要求在分钟级别恢复业务；对于位于等级6的核心业务而言，则需要做到数据零丢失。 阿里巴巴数据库从备份到多活的发展经过了以下历程： 2012年之前，阿里巴巴采用的是异地冷备+热备方案，提供只读副本，当时异地冷备和热备可能出现异地延时比较长的问题，导致出现灾难之后敢不敢进行数据库切换成为一个问题，可能现在很多传统企业还在使用该方案。 2013年，阿里巴巴通过数据库实时日志的解析能力实现了同城双活。 2014年，阿里巴巴实现了异地双活。 2015年，阿里巴巴就实现了中美同步以及多个地域、多点写入的数据同步策略。 2016年，阿里巴巴实现了分布式数据强一致的能力以及异地多活能力。 在不断提升阿里巴巴灾备能力的过程中，我们也在阿里云上孵化了数据库备份（DBS）、数据传输（DTS）、混合云数据库管理（HDM），搭建从备份、容灾、双活及混合云统一管理的一站式云灾备解决方案。 对于等级1到等级4的业务而言，可以通过DBS将数据实时备份到阿里云OSS上，该方案具有低成本、秒级RPO的优势； 对于等级5的业务而言，可以通过DTS数据传输服务将本地IDC或者其他云产商的数据库备份到阿里云上去，实现热备或者双活解决方案，实现秒级RPO和秒级RTO。 阿里云数据库新型灾备方案众所周知，传统灾备解决方案存在成本高昂、实施困难、运维复杂、RTO和RPO无法保障等问题。 阿里云拥有遍布全球安全可靠的数据中心，是企业用户天然的异地灾备中心。阿里云的新型灾备方案可以为您提供低成本、高质量、开箱即用的数据库灾备服务。 1、数据库备份服务DBS数据库备份服务DBS结合阿里云对象存储服务OSS，能够为用户提供秒级RPO以及低成本的特性，并且实现了国家灾备等级4的相应能力。 用户自建的IDC或者来自其他云厂商的数据库可以通过DBS备份到阿里云OSS之上，而且整个备份的实现过程非常简单，只需要打通网络就可以通过DBS实现数据备份到云上，当出现灾难的时候就能够完成云上数据库快速恢复。 除了和云上数据库进行打通之外，对于数据的备份集而言，也可以通过数据湖服务直接进行查询和验证（无需恢复），这也是阿里云特有的能力之一。 阿里云数据库备份服务DBS主要有如下优势： 秒级RPO：因为数据库发生变更的时候，首先会记录日志，再刷新数据。而阿里巴巴沉淀了一整套数据库解析技术，通过这个技术能够实现秒级冷备到阿里云上的能力，并且其冷备数据和在线数据之间仅存在秒级延时。低成本：借助OSS的能力可以实现对于数据的周期性归档，并且允许数据库只备份核心关注的数据业务表，仅备份有效数据，同时进行加密和压缩。备份数据可在线读，验证有效性：基于DLA的数据湖能力，备份逻辑数据集允许用户直接进行备份集查询，查询里面的数据内容并且校验其中的数据。基于RDS的能力能够帮助用户在出现灾难时实现数据库的快速恢复。丰富的备份数据源：阿里云数据库备份服务DBS能够支持非常丰富的数据源，包括Oracle、MySQL、SQLServer、MongoDB以及Redis等。2、数据库热备以及双活架构DTS 结合DTS和RDS就能够实现云上数据库热备，可以实现国标等级5的灾备能力。无论是将业务中心建立在自建IDC还是其他云厂商上，通过DTS热备到阿里云上，当出现本地IDC出现数据库故障或者误操作的时候，用户就可以一键切换到云热备之上，实现秒级RPO和秒级RTO。 您还可以更进一步，借助DTS和RDS实现多活，除了将业务切换到阿里云上之外，还可以反向建立阿里云到本地IDC数据库的同步链路，从而建立双向同步通道，这样就能够提供异地双活能力，两端都可以进行写入和切换。业务也可以在云上和本地IDC之间进行分流，从而实现就近写入和就近服务的查询能力，同时能够支持实现容灾。 如果采用传统热备方案，将数据热备到云上之后可以支持实现秒级RPO的数据库切换，但是当切换完成之后如果想要去恢复灾备系统，则需要一定的恢复过程，但是当建立了双向同步通道之后，可以很快地切换到阿里云，同时很快地切换回来，因此能够支持企业实现在线的容灾演练。 关于阿里云数据库传输服务DTS： 阿里巴巴在2011年左右开始投入做数据库的日志解析，而DTS除了能够实现日志解析之外，还能够实现高效的数据同步，是阿里巴巴内部实现异地多活的基础设施，也是阿里巴巴的数据从生产到消费的数据流基础设施。 DTS也支持了非常丰富的数据源，包括关系型数据库、NoSQL及大数据等17种数据源，承担了阿里云上的40多万的数据传输任务。 3、基于DMS+HDM的数据库统一管理方案 除了上述的DBS和DTS两款灾备产品之外，当用户使用线下到线上的数据同步或者线下到线上数据热备之后，就会形成一个混合云数据库架构。 阿里云为此提供了一整套数据库混合云统一管理解决方案，该方案沉淀了阿里在脱敏审计、变更管控以及研发协同等多方面的能力。 在混合云上，如果数据库分布在自建的IDC、其他云厂商以及阿里云上，就可以通过阿里云的混合云数据库管理（HDM）进行统一管理，通过One Console实现统一监控、告警、性能优化和风险识别。 了解企业级云灾备解决方案——“十万先行者计划”，请点击：https://promotion.aliyun.com/ntms/act/hclouddr/index.html 相关阅读阿里云发布企业级云灾备解决方案，十万先行者计划开启普惠灾备专访阿里数据库备份专家 教你Pick最有效的备份系统 本文作者：七幕阅读原文 本文为云栖社区原创内容，未经允许不得转载。

分布式消息队列是是大型分布式系统不可缺少的中间件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。 对于一个架构师来说，在大型系统设计中，会经常需要面对同步和异步等架构问题，搞明白这些问题，能更好地实现程序并行执行，减少等待或无效操作，以及充分利用计算机的性能！ 本文将详细讲解：1.同步架构和异步架构的区别 2.异步架构的主要组成部分：消息生产者、消息消费者、分布式消息队列 3.异步架构的两种主要模型：点对点模型和发布订阅模型。 4.消息队列的好处 5.消息队列相关产品 建议用10min通读，搞懂分布式消息队列的核心内容。 一、同步架构和异步架构的区别 1.同步调用 是指从请求的发起一直到最终的处理完成期间，请求的调用方一直在同步阻塞等待调用的处理完成。 如图，在这个例子中客户端代码ClientCode，需要执行发送邮件sendEmail这样一个操作，它会调用EmailService进行发送，而EmailService会调用SmtpEmailAdapter这样一个类来进行处理，而这个类会调用远程的一个服务，通过SMTP和TCP协议把请求发送给它。 而远程服务器收到消息以后会对消息进行一系列的操作，然后将邮件发送出去，再进行返回。Adapter收到返回后，再返回给EmailService，EmailService收到返回后再把返回结果返回给Clientcode。 ClientCode在sendEmail发出请求后，就一直都阻塞在这里，等待最终调用结果的返回，是成功还是失败。因为这个过程是阻塞等待的，所以这个过程也就是同步调用。 2.异步调用 是指在请求发起的处理过程中，客户端的代码已经返回了，它可以继续进行自己的后续操作，而不需要等待调用处理完成，这就叫做异步调用。 异步调用过程，同样看刚刚发送邮件的例子，用户Clientcode调用EmailService以后，EmailService会把这个调用请求发送给消息队列，然后就立即返回了。Clientcode收到返回以后继续向下处理，不会继续阻塞等待。实际上消息发送到Queue后，还没有被处理，我们看到后面的消息消费，其实要比EmailService返回可能还要晚一点，EmailService返回以后消息才会被消费处理。 有一个QueueConsumer消息队列的消费者，从消息队列中取出这个消息，再把这个消息发送给SmtpAdapter，也就是调用SmtpAdapter，处理逻辑跟同步调用一样，SmtpAdapter通过SMTP的通讯协议，把消息发送给远程的一个服务器，进行邮件发送，通过RemoteServer进行处理，处理完了收到返回，再把返回结果通知消息队列Queue。 在这个过程中，客户端的调用，也就是应用程序的调用，和业务逻辑真正发送邮件的操作是不同步的。 二、异步架构的主要组成部分 使用异步调用架构的主要手段，就是通过消息队列构建，如下是它的架构图。 消息的生产者将消息发送到消息队列以后，由消息的消费者从消息队列中获取消息，然后进行业务逻辑的处理，消息的生产者和消费者是异步处理的，彼此不会等待阻塞，所以叫做异步架构。 使用消息队列构建一个异步调用架构，你需要了解如下3种角色。 1.消息的生产者 是客户端应用程序代码的一部分，用来初始化异步调用处理流程。在基于消息队列的处理中，生产者的职责非常少，它要做的就是创建一个合法的消息，并把这个消息发送到消息队列中，由应用开发者决定生产者的代码在哪里执行，什么时候发送消息。 2.消息队列 消息队列是消息发送的目的地和发给消费者的一个缓冲。消息队列实现的方法有好多种，可以用共享文件夹，也可以用关系数据库或者NoSQL系统，当然最主要的还是使用专门的分布式消息队列服务器来实现。 3.消息的消费者 消息的消费者从消息队列中接受并处理消息，消息的消费者也是由应用开发者实现的，但是它是一个异步处理的组件。消息的消费者不需要知道生产者存在，它只依赖消息队列中的消息。消息的消费者通常部署在独立的服务器上，和消息的生产者完全隔离，并且可以通过添加硬件的方式进行伸缩。 三、异步架构的两种主要模型 使用消息队列构建异步的调用架构，你还需要知道两种模型：点对点模型和发布订阅模型。 1.点对点模型 消费者和生产者只需要知道消息队列的名字，生产者发送消息到消息队列中，而消息队列的另一端是多个消费者竞争消费消息，每个到达消息队列的消息只会被路由到一个消费者中去，所以消费者看到的是全部消息的一个子集。我们看这张图，消息的生产者有多个，消息的消费者也有多个，多个生产者将消息发送到消息队列中，而有多个消费者去消息队列中对消息进行竞争性的消费。每个消息只会被一个消费者消费，每个消费者只会消费消息队列中的一部分消息。 2.发布订阅模型 在发布订阅模型中，消息可能被发送到不止一个消费者，生产者发送消息到一个主题，而不是队列中。消息被发布到主题后，就会被克隆给每一个订阅它的消费者，每个消费者接收一份消息复制到自己的私有队列。消费者可以独立于其他消费者使用自己订阅的消息，消费者之间不会竞争消息。常用的分布式消息队列都支持发布订阅模型，也就是说消息的发布订阅模型是分布式消息队列的一个功能特性。 3.两个模型的应用 点对点模型：主要用于一些耗时较长的、逻辑相对独立的业务。 比如说我前面的讲到的发送邮件这样一个操作。因为发送邮件比较耗时，而且应用程序其实也并不太关心邮件发送是否成功，发送邮件的逻辑也相对比较独立，所以它只需要把邮件消息丢到消息队列中就可以返回了，而消费者也不需要关心是哪个生产者去发送的邮件，它只需要把邮件消息内容取出来以后进行消费，通过远程服务器将邮件发送出去就可以了。而且每个邮件只需要被发送一次。所以消息只被一个消费者消费就可以了。 发布订阅模型：如新用户注册这样一个消息，需要使用按主题发布的方式。 比如新用户注册，一个新用户注册成功以后，需要给用户发送一封激活邮件，发送一条欢迎短信，还需要将用户注册数据写入数据库，甚至需要将新用户信息发送给关联企业的系统，比如淘宝新用户信息发送给支付宝，这样允许用户可以一次注册就能登录使用多个关联产品。一个新用户注册，会把注册消息发送给一个主题，多种消费者可以订阅这个主题。比如发送邮件的消费者、发送短信的消费者、将注册信息写入数据库的消费者，跨系统同步消息的消费者等。 四、消息队列的好处 1.实现异步处理，提升处理性能 对一些比较耗时的操作，可以把处理过程通过消息队列进行异步处理。这样做可以推迟耗时操作的处理，使耗时操作异步化，而不必阻塞客户端的程序，客户端的程序在得到处理结果之前就可以继续执行，从而提高客户端程序的处理性能。 2.可以让系统获得更好的伸缩性 耗时的任务可以通过分布式消息队列，向多台消费者服务器并行发送消息，然后在很多台消费者服务器上并行处理消息，也就是说可以在多台物理服务器上运行消费者。那么当负载上升的时候，可以很容易地添加更多的机器成为消费者。 如图中的例子，用户上传文件后，通过发布消息的方式，通知后端的消费者获取数据、读取文件，进行异步的文件处理操作。那么当前端发布更多文件的时候，或者处理逻辑比较复杂的时候，就可以通过添加后端的消费者服务器，提供更强大的处理能力。 3.可以平衡流量峰值，削峰填谷 使用消息队列，即便是访问流量持续的增长，系统依然可以持续地接收请求。这种情况下，虽然生产者发布消息的速度比消费者消费消息的速度快，但是可以持续的将消息纳入到消息队列中，用消息队列作为消息的缓冲，因此短时间内，发布者不会受到消费处理能力的影响。 从这张图可以看到，因为消息的生产者是直接面向用户请求的，而用户的请求访问压力是不均衡的。如淘宝每天的访问高峰是在上午10点左右，而新浪微博则可能在某个明星半夜发一条微博后突然出现访问高峰。 在访问高峰，用户的并发访问数可能超过了系统的处理能力，所以在高峰期就可能会导致系统负载过大，响应速度变慢，更严重的可能会导致系统崩溃。这种情况下，通过消息队列将用户请求的消息纳入到消息队列中，通过消息队列缓冲消费者处理消息的速度。 如图中所示，消息的生产者它有高峰有低谷，但是到了消费者这里，只会按照自己的最佳处理能力去消费消息。高峰期它会把消息缓冲在消息队列中，而在低谷期它也还是使用自己最大的处理能力去获取消息，将前面缓冲起来、来不及及时处理的消息处理掉。那么，通过这种手段可以实现系统负载消峰填谷，也就是说将访问的高峰消掉，而将访问的低谷填平，使系统处在一个最佳的处理状态之下，不会对系统的负载产生太大的冲击。 4.失败隔离和自我修复 因为发布者不直接依赖消费者，所以分布式消息队列可以将消费者系统产生的错误异常与生产者系统隔离开来，生产者不受消费者失败的影响。 当在消息消费过程中出现处理逻辑失败的时候，这个错误只会影响到消费者自身，而不会传递给消息的生产者，也就是应用程序可以按照原来的处理逻辑继续执行。 所以，这也就意味着在任何时候都可以对后端的服务器执行维护和发布操作。可以重启、添加或删除服务器，而不影响生产者的可用性，这样简化了部署和服务器管理的难度。 5.可以使生产者和消费者的代码实现解耦合 也就是说可以多个生产者发布消息，多个消费者处理消息，共同完成完整的业务处理逻辑，但是它们的不需要直接的交互调用，没有代码的依赖耦合。在传统的同步调用中，调用者代码必须要依赖被调用者的代码，也就是生产者代码必须要依赖消费者的处理逻辑代码，代码需要直接的耦合，而使用消息队列，这两部分的代码不需要进行任何的耦合。 耦合程度越低的代码越容易维护，也越容易进行扩展。 比如新用户注册，如果用传统同步调用的方式，那么发邮件、发短信、写数据库、通知关联系统这些代码会和用户注册代码直接耦合起来，整个代码看起来就是完成用户注册逻辑后，后面必然跟着发邮件、发短信这些代码。如果要新增一个功能，比如将监控用户注册情况，将注册信息发送到业务监控系统，就必须要修改前面的代码，至少增加一行代码，发送注册信息到监控系统，我们知道，任何代码的修改都可能会引起bug。 而使用分布式消息队列实现生产者和消费者解耦合以后，用户注册以后，不需要调用任何后续处理代码，只需要将注册消息发送到分布式消息队列就可以了。如果要增加新功能，只需要写个新功能的消费者程序，在分布式消息队列中，订阅用户注册主题就可以了，不需要修改原来任何一行代码。 这种解耦的特点对于团队的工作分工也很有帮助！从消息生产者的视角看，它只需要构建消息，将消息放入消息队列中，开发就完成了。而从消费者的开发视角看，它只需要从消息队列中获取消息，然后进行逻辑处理。它们彼此之间不进行任何耦合。消息的生产者不关心放入消息队列中下一步会发生什么，而消费者也不需要知道消息从哪里来。这两部分程序的开发者也可以不关心彼此的工作进展，他们开发的代码也不需要集成在一起，只要约定好消息格式，就可以各自开发了。 ...

一致性模型本质上是进程与数据存储的约定，通过一致性模型我们可以理解和推理在分布式系统中数据复制需要考虑的问题和基本假设。那么，一致性模型的具体实现有一些呢？本文会介绍一致性协议实现的主要思想和方法。 什么是一致性协议一致性协议描述了特定一致性模型的实际实现。一致性模型就像是接口，而一致性协议就像是接口的具体实现。一致性模型提供了分布式系统中数据复制时保持一致性的约束，为了实现一致性模型的约束，需要通过一致性协议来保证。 一致性协议根据是否允许数据分歧可以分为两种： 单主协议（不允许数据分歧）：整个分布式系统就像一个单体系统，所有写操作都由主节点处理并且同步给其他副本。例如主备同步、2PC、Paxos 都属于这类协议。多主协议（允许数据分歧）：所有写操作可以由不同节点发起，并且同步给其他副本。例如 Gossip、POW。可以发现，它们的核心区别在于是否允许多个节点发起写操作，单主协议只允许由主节点发起写操作，因此它可以保证操作有序性，一致性更强。而多主协议允许多个节点发起写操作，因此它不能保证操作的有序性，只能做到弱一致性。 值得注意的是，一致性协议的分类方式有很多种，主要是看从哪个角度出发进行归类，常用的另一个归类方式是根据同步/异步复制来划分，这里就不多做讨论了。下面对单主协议和多主协议分别做一些共性的分析，篇幅所限，不会深入到协议细节。 单主协议单主协议的共同点在于都会用一个主节点来负责写操作，这样能够保证全局写的顺序一致性，它有另一个名字叫定序器，非常的形象。 主备复制主备复制可以说是最常用的数据复制方法，也是最基础的方法，很多其他协议都是基于它的变种。 主备复制要求所有的写操作都在主节点上进行，然后将操作的日志发送给其他副本。可以发现由于主备复制是有延迟的，所以它实现的是最终一致性。 主备复制的实现方式：主节点处理完写操作之后立即返回结果给客户端，写操作的日志异步同步给其他副本。这样的好处是性能高，客户端不需要等待数据同步，缺点是如果主节点同步数据给副本之前数据缺失了，那么这些数据就永久丢失了。MySQL 的主备同步就是典型的异步复制。 两阶段提交两阶段提交（2PC）是关系型数据库常用的保持分布式事务一致性的协议，它也属于同步复制协议，即数据都同步完成之后才返回客户端结果。可以发现 2PC 保证所有节点数据一致之后才返回给客户端，实现了顺序一致性。 2PC 把数据复制分为两步： 表决阶段：主节点将数据发送给所有副本，每个副本都要响应提交或者回滚，如果副本投票提交，那么它会将数据放到暂存区域，等待最终提交。提交阶段：主节点收到其他副本的响应，如果副本都认为可以提交，那么就发送确认提交给所有副本让它们提交更新，数据就会从暂存区域移到永久区域。只要有一个副本返回回滚就整体回滚。可以发现 2PC 是典型的 CA 系统，为了保证一致性和可用性，2PC 一旦出现网络分区或者节点不可用就会被拒绝写操作，把系统变成只读的。由于 2PC 容易出现节点宕机导致一直阻塞的情况，所以在数据复制的场景中不常用，一般多用于分布式事务中（注：实际应用过程中会有很多优化）。 分区容忍的一致性协议分区容忍的一致性协议跟所有的单主协议一样，它也是只有一个主节点负责写入（提供顺序一致性），但它跟 2PC 的区别在于它只需要保证大多数节点（一般是超过半数）达成一致就可以返回客户端结果，这样可以提高了性能，同时也能容忍网络分区（少数节点分区不会导致整个系统无法运行）。分区容忍的一致性算法保证大多数节点数据一致后才返回客户端，同样实现了顺序一致性。 下面用一个简单的示例来说明这类算法的核心思想。假设现在有一个分布式文件系统，它的文件都被复制到 3 个服务器上，我们规定：要更新一个文件，客户端必须先访问至少 2 个服务器（大多数），得到它们同意之后才能执行更新，同时每个文件都会有版本号标识；要读取文件的时候，客户端也必须要访问至少 2 个服务器获取该文件的版本号，如果所有的版本号一致，那么该版本必定是最新的版本，因为如果前面的更新操作要求必须要有大多数服务器的同意才能更新文件。 以上就是我们熟知的 Paxos、ZAB、Raft 等分区容忍的一致性协议的核心思想：一致性的保证不一定非要所有节点都保持一致，只要大多数节点更新了，对于整个分布式系统来说数据也是一致性的。上面只是一个简单的阐述，真正的算法实现是比较复杂的，这里就不展开了。 分区容忍的一致性协议如 Paxos 是典型的 CP 系统，为了保证一致性和分区容忍，在网络分区的情况下，允许大多数节点的写入，通过大多数节点的一致性实现整个系统的一致性，同时让少数节点停止服务（不能读写），放弃整体系统的可用性，也就是说客户端访问到少数节点时会失败。 值得注意的是，根据 CAP 理论，假设现在有三个节点 A、B、C，当 C 被网络分区时，有查询请求过来，此时 C 因为不能和其他节点通信，所以 C 无法对查询做出响应，也就不具备可用性。但在工程实现上，这个问题是可以被绕过的，当客户端访问 C 无法得到响应时，它可以去访问 A、B，实际上对于整个系统来说还是部分可用性的，并不是说 CP 的系统一定就失去可用性。详细的分析参考分布式系统：CAP 理论的前世今生 多主协议相比单主协议为了实现顺序一致性，不允许多个节点并发写，多主协议恰恰相反，只保证最终一致性，允许多个节点并发写，能够显著提升系统性能。由于多主协议一般提供的都是最终一致性，所以常用在对数据一致性要求不高的场景中。 Gossip 协议就是一种典型的多主协议，很多分布式系统都使用它来做数据复制，例如比特币，作为一条去中心化的公链，所有节点的数据同步都用的是 Gossip 协议。此外，Gossip 协议也在一些分布式数据库中如 Dynamo 中被用来做分布式故障检测的状态同步，当有节点故障离开集群时，其他节点可以快速检测到。 ...

如果第二次看到我的文章，欢迎「文末」扫码订阅我个人的公众号（跨界架构师）哟~ 每周五早8点 按时送达到公众号。当然了，也会时不时加个餐～前面一篇文章中，Z哥和你聊了「异步」的意义，以及如何运用它。错过这篇文章的可以先去看一下再来（分布式系统关注点——深入浅出「异步」）。 其实我知道有不少小伙伴容易将「异步」和「非阻塞」搞混。脑海里印象可能是这样的：异步=非阻塞，同步=阻塞？ 其实并不是如此，Z哥我这次就想来帮你搞清楚这个问题。 同步与阻塞/非阻塞你平时编写的代码中，大部分的「同步」调用，本质上都是「阻塞」的。但是「同步」调用也可以做到「非阻塞」的效果。 还是拿我们上一篇中提到的排队买奶茶这个例子，看看为什么说是「同步」+「阻塞」。 文章里「同步」的例子说的是，你排队买奶茶，点完单继续“占着坑”，不让后面的人点单，等里面的店员做好奶茶，你拿走了后面的才能点单。这个其实就是「同步」+「阻塞」，「阻塞」体现在哪？ 因为这个时候你一直“占着坑”，生怕后面的人先点单，导致店员给他先做。所以，这个时候你就死死的盯着里面，这个就是「阻塞」，因为你除了盯着其它啥都干不了。 怎么让「同步」也能不阻塞呢？ 就是你虽然还是排着队“占着坑”，但是人没闲着，低头玩玩手机，时不时的问里面“我的奶茶做好了没？我的奶茶做好了没？”。这个就是「非阻塞」，因为你两次询问之间会间隔一段时间，可以在这个时候做其它的事情。本质上是通过将原本的一个「大同步」拆成多个「小同步」达到「非阻塞」的效果。 上图中，几次阻塞之间空白区域就可以用于做其它事，所以是「非阻塞」的。 异步与阻塞/非阻塞上一篇文章中的「异步」例子就是一个「非阻塞」的例子，我们来看看为什么。 奶茶店分了点单区和取餐区之后，做好的饮料就只能从取餐区拿，也意味着接待你进行点单的人并不是实际做奶茶的人。这个时候你会拿到一张取餐号，然后老老实实的去取餐区等着，而不是“占着xx不xx”。 如果你很着急要拿到奶茶，不断的问里面“我的奶茶做好了没？我的奶茶做好了没？”，那这个还是「同步」+「非阻塞」的模式。因为这个过程没有产生「回调」，是你在不断的主动发起“请求”。 但如果你不着急，就在边上开一局吃鸡，等着里面做好了叫号，到你号码了再去拿。这就是「异步」+「非阻塞」。因为这个事情是对方（里面的店员）触发完成的，这就是「回调」，是对你之前的“点单”请求进行的响应。一来一回完成一个完整的交互。 到这可能你会说，那异步不还是天然「非阻塞」的么？No、No、No。 阻塞不阻塞是你自己决定的，你可以阻塞啊。比如，你等的“回调”时候发现没带手机，玩不了吃鸡，那只能傻傻的在那等着，啥也干不了。如此，这个过程虽然还是「异步」的，但对你来说就是「阻塞」的。 工作中的同步/异步&阻塞/非阻塞「同步」+「阻塞」。这种最常见，平时写的大部分代码都是如此，就不多说了。 其实你仔细想一下就会发现，很多知名的框架，都是「同步」+「非阻塞」的，为什么呢？因为你可以继续像「同步」一样编写代码，但是可以享受到类似「异步」所能带来的更好的性能，何乐而不为？ 比如大名鼎鼎的linux中的io复用模型poll/select/epoll，本质上都是「同步」+「非阻塞」的。还有知名网络通信框架Netty。 我们在设计对外的api的时候也可以使用这种模式，降低一些耗时接口调用所产生的影响。这个阮一峰老师已经写的非常清楚了，我就直接贴个链接：http://www.ruanyifeng.com/blo...。 之所以大家会有错觉，认为「异步」=「非阻塞」，其实也不是没有道理。为什么呢？因为我在脑海中搜寻来一番，的确没想到有什么知名的框架/设计是使用「异步」+「阻塞」来实现的。如果哪位小伙伴有补充，可以在评论区留言告诉大家。 「异步」+「非阻塞」就多了。任何你看到callback关键字的框架都是。 总结好了，我们一起总结一下。 这次呢，Z哥先通过同步/异步、阻塞/非阻塞之间形成的4种组合形式，聊了下它们到底是怎么回事。 然后和你聊了一下工作中哪里能看到它们的存在，以及在一些典型场景下适合用哪一种模式。 希望对你有所启发。 最后送你一个记住这4个概念的最好办法。 同步阻塞：你干吧，我看着你干同步非阻塞：你干吧，我每隔5分钟来看看异步阻塞：你干吧，好了告诉我，我等着异步非阻塞：你干吧，好了告诉我，我先去忙别的了如果还是记不住，那就记住同步/异步表示“过程”，阻塞/非阻塞表示在这个过程中的“状态”。至于这句话是怎么来的，回来看这篇文章就行。 相关文章： 分布式系统关注点——深入浅出「异步」分布式系统关注点——360°全方位解读「缓存」 作者：Zachary 出处：https://www.cnblogs.com/Zacha... 如果你喜欢这篇文章，可以点一下文末的「赞」。 这样可以给我一点反馈。: ) 谢谢你的举手之劳。 ▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描下方的二维码~。定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。 如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

与你同行，抬头便是星空。 本文整理自Nacos Committer 张龙的现场分享，阿里巴巴中间件受权发布。 随着 Nacos 1.0.0 稳定版的发布，越来越多的企业开始在测试/预演/生产环境中逐步部署 Nacos。目前，除了部分企业已处于转型分布式架构的过程中，会考虑直接使用 Nacos 上生产，但仍有不少企业会考虑一些比较现实的问题： 存量用户如何迁移注册中心到 Nacos？多区域注册中心之间如何同步？已有注册中心与 Nacos 如何并存使用？这里，我将通过对 Nacos Sync 的介绍，来回答这三个问题。 Nacos Sync 是什么？Nacos Sync 是一个支持多种注册中心的同步组件，基于 SpringBoot 开发框架，数据层采用 Spring Data JPA，遵循了标准的 JPA 访问规范，支持多种数据源存储，默认使用 Hibernate 实现，更加方便的支持表的自动创建更新。 下图是 Nacos Sync 系统的概念图，Nacos Sync 通过从各个注册中心拉取注册的服务实例数据同步到 Nacos，左右两边是不同的注册中心，绿色代表目前是可以进行双向同步的，蓝色代表暂时只能进行单向同步。 Nacos Sync 使用了高效的事件异步驱动模型，支持多种自定义事件，使得同步任务处理的延时控制在3s，8C16G的单机能够支持6K的同步任务。 除了单机部署，Nacos Sync 也提供了高可用的集群部署模式，作为无状态设计，支持将任务等状态数据迁移到了数据库，使得集群扩展非常方便。 系统模块架构下图是 Nacos Sync 目前的系统架构图，画的比较简单，只是把一些比较重要的模块做了描述。 Web Console: 提供给用户进行注册中心和同步任务进行相关界面操作 Processor Frame: 注册中心和任务的业务处理逻辑 Timer Manager: 定时轮询数据库获取同步任务进行处理 Event Frame: 异步事件来进行同步任务的同步以及删除 Extension: 对接各种注册中心客户端的扩展实现 整体调用流程我们来看一下 Nacos Sync 一次完整的调用流程： ...

前言在架构篇中我们介绍了现代IM消息系统的架构，介绍了Timeline的抽象模型以及基于Timeline模型构建的一个支持『消息漫游』、『多端同步』和『消息检索』多种高级功能的消息系统的典型架构。架构篇中为了简化读者对Tablestore Timeline模型的理解，概要性的对Timeline的基本逻辑模型做了介绍，以及对消息系统中消息的多种同步模式、存储和索引的基本概念做了一个科普。 本篇文章是对架构篇的一个补充，会对Tablestore的Timeline模型做一个非常详尽的解读，让读者能够深入到实现层面了解Timeline的基本功能以及核心组件。最后我们还是会基于IM消息系统这个场景，来看如何基于Tablestore Timeline实现IM场景下消息同步、存储和索引等基本功能。 Timeline模型Timeline模型以『简单』为设计目标，核心模块构成比较清晰明了，主要包括： Store：Timeline存储库，类似数据库的表的概念。Identifier：用于区分Timeline的唯一标识。Meta：用于描述Timeline的元数据，元数据描述采用free-schema结构，可自由包含任意列。Queue：一个Timeline内所有Message存储在Queue内。Message：Timeline内传递的消息体，也是一个free-schema的结构，可自由包含任意列。Index：包含Meta Index和Message Index，可对Meta或Message内的任意列自定义索引，提供灵活的多条件组合查询和搜索。Timeline Store Timeline Store是Timeline的存储库，对应于数据库内表的概念。上图是Timeline Store的结构图，Store内会存储所有的Timeline数据。Timeline是一个面向海量消息的数据模型，同时用于消息存储库和同步库，需要满足多种要求： 支撑海量数据存储：对于消息存储库来说，如果需要消息永久存储，则随着时间的积累，数据规模会越来越大，需要存储库能应对长时间积累的海量消息数据存储，需要能达到PB级容量。低存储成本：消息数据的冷热区分是很明显的，大部分查询都会集中在热数据，所以对于冷数据需要有一个比较低成本的存储方式，否则随着时间的积累数据量不断膨胀，存储成本会非常大。数据生命周期管理：不管是对于消息数据的存储还是同步，数据都需要定义生命周期。存储库是用于在线存储消息数据本身，通常需要设定一个较长周期的保存时间。而同步库是用于写扩散模式的在线或离线推送，通常设定一个较短的保存时间。极高的写入吞吐：各类场景下的消息系统，除了类似微博、头条这种类型的Feeds流系统，像绝大部分即时通讯或朋友圈这类消息场景，通常是采用写扩散的消息同步模式，写扩散要求底层存储具备极高的写入吞吐能力，以应对消息洪峰。低延迟的读：消息系统通常是应用在在线场景，所以对于查询要求低延迟。Tablestore Timeline的底层是基于LSM存储引擎的分布式数据库，LSM的最大优势就是对写入非常友好，天然适合消息写扩散的模式。同时对查询也做了极大优化，例如热数据进缓存、bloom filter等等。数据表采用Range Partition的分区模式，能提供水平扩展的服务能力，以及能自动探测并处理热点分区的负载均衡策略。为了满足同步库和存储库对存储的不同要求，也提供了一些灵活的自定义配置，主要包括： Time to live（数据生命周期）：可自定义数据生命周期，例如永久保存，或者保存N天。Storage type（存储类型）：自定义存储类型，对存储库来说，HDD是最好的选择，对同步库来说，SSD是最好的选择。Timeline Module Timeline Store内能存储海量的Timeline，单个Timeline的详细结构图如上，可以看到Timeline主要包含了三大部分： Timeline Meta：元数据部分，用于描述Timeline，包括：Identifier：用于唯一标识Timeline，可包含多个字段。 Meta：用于描述Timeline的元数据，可包含任意个数任意类型的字段。Meta Index：元数据索引，可对元数据内任意属性列建索引，支持多字段条件组合查询和检索。Timeline Queue：用于存储和同步消息的队列，队列中元素由两部分组成：Sequence Id：顺序ID，队列中用于定位Message的位点信息，在队列中顺序ID保持递增。 Message：队列中承载消息的实体，包含了消息的完整内容。Timeline Data：Timeline的数据部分就是Message，Message主要包含：Message：消息实体，其内部也可以包含任意数量任意类型字段。 Message Index：消息数据索引，可对消息实体内任意列做索引，支持多字段条件组合查询和检索。IM消息系统建模 以一个简易版IM系统为例，来看如何基于Tablestore Timeline模型建模。按照上图中的例子，存在A、B、C三个用户，A与B发生单聊，A与C发生单聊，以及A、B、C组成一个群聊，来看下在这个场景下消息同步、存储以及读写流程分别如何基于Tablestore Timeline建模。 消息同步模型 消息同步选择写扩散模型，能完全利用Tablestore Timeline的优势，以及针对IM消息场景读多写少的特性，通过写扩散来平衡读写，均衡整个系统的资源。写扩散模型下，每个接收消息的个体均拥有一个收件箱，所有需要同步至该个体的消息需要投递到其收件箱内。图上例子中，A、B、C三个用户分别拥有收件箱，每个用户不同的设备端，均从同一个收件箱内拉取新消息。 消息同步库 收件箱存储在同步库内，同步库中每个收件箱对应一个Timeline。根据图上的例子，总共存在3个Timeline作为收件箱。每个消息接收端保存有本地最新拉取的消息的SequenceID，每次拉取新消息均是从该SequenceID开始拉取消息。对同步库的查询会比较频繁，通常是对最新消息的查询，所以要求热数据尽量缓存在内存中，能提供高并发低延迟的查询。所以对同步库的配置，一般是需要SSD存储。消息如果已经同步到了所有的终端，则代表收件箱内的该消息已经被消费完毕，理论上可以清理。但设计上来说不做主动清理，而是给数据定义一个较短的生命周期来自动过期，一般定义为一周或者两周。数据过期之后，如果仍要同步拉取新消息，则需要退化到读扩散的模式，从存储库中拉取消息。 消息存储库 消息存储库中保存有每个会话的消息，每个会话的发件箱对应一个Timeline。发件箱内的消息支持按会话维度拉取消息，例如浏览某个会话内的历史消息则通过读取发件箱完成。一般来说，新消息通过在线推送或者查询同步库可投递到各个接收端，所以对存储库的查询会相对来说较少。而存储库用于长期存储消息，例如永久存储，相对同步库来说数据量会较大。所以存储库的选择一般是HDD，数据生命周期根据消息需要保存的时间来定，通常是一个较长的时间。 消息索引库 消息索引库依附于存储库，使用了Timeline的Message Index，可以对存储库内的消息进行索引，例如对文本内容的全文索引、收件人、发件人以及发送时间的索引等，能支持全文检索等高级查询和搜索。 总结本篇文章主要对Tablestore Timeline模型进行了详解，介绍了Timeline各模块包括Store、Meta、Queue、Data和Index等，最后以一个简单的IM场景举例如何基于Timeline来建模。在下一篇实现篇中，会直接基于Tablestore Timeline来实现一个简易版的支持单聊、群聊、元数据管理以及消息检索的IM系统，敬请期待。 本文作者：木洛阅读原文 本文为云栖社区原创内容，未经允许不得转载。

背景在系统的快速迭代过程中，业务系统往往部署在同一个物理库，没有做核心数据和非核心数据的物理隔离。随着数据量的扩大这种情况会带来稳定性的风险，如库的慢sql，磁盘，IO等等都会相互整体影响，从而影响核心系统的业务稳定性，因此需要将核心业务的业务表从原有库里抽取出来，单独到新库里。而核心数据的迁移，涉及到的一个关键难点：如何平稳及用户无感知的迁移数据，本文将结合闲鱼商品库迁移实践，向大家展示如何解决这个难题的.闲鱼商品数据现状闲鱼商品数据量XX亿级别以上，采用分表分库和读写分离的MYSQL数据库集群来支撑线上查询服务,如下图，通过TDDL[1]数据库中间件进行高效统一管理。可能有些同学会对分表分库相关概念不了解，这里先简单做些介绍。01分表分库原理本质是数据库的水平拆分问题，把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题，下图描述分表分库的核心原理：当然分表分库也有负面影响，就是表结构变更及相关管理相比单表麻烦，有一定风险，具体如何决择，还是要根据实际情况来分析。02分表分库下全局Sequence生成分表分库解决在线服务容量和性能问题，但是也带来使用上的复杂度提升。灵活的配置路由规则和路由数据并提供简单易用的封装都是要考虑的，以便业务对此无感知。阿里开源中间件产品TDDL提供了解决方案，对应阿里云上产品为：DRDS[2]。TDDL关键原理不多做介绍，但是在数据库迁移过程中主键冲突风险是故障重要风险点，这里简要介绍下TDDL的全局唯一主键生成原理。如上图，TDDL Sequence是基于数据库更新＋内存分配：每次操作批量分配id，分配id的数量就是sequence的内步长，而原有id值就加上外部长值，后续的分配直接就在内存里拿，这样的优势：简单高效 缺点：无法保证自增顺序。另外数据迁移过程中，在新库中，为了保证跟原数据库主键非冲突，需要设置一个跃迁比较大的主键，防止出现两个库中的主键冲突，这是后续迁移中要注意的关键点之一。数据迁移方案通过前文的简单介绍，大家对闲鱼商品库现状有了初步了解，下面将给大家介绍一下闲鱼是如何做到稳定迁移商品库的。01核心思路数据迁移核心思路抽象起来其实很简单，即如何稳定平滑迁移数据，如下图所示:但围绕这个过程细化下去，我们会遇到不少问题，如：1、数据我们该如何迁移，是一次性？还是分阶段？2、如何校验数据迁移过程的正确性?3、我们业务改造有问题怎么办？如何尽早发现？如何回滚？4、我们的新库性能如何？带着这些问题，我们进一下细化梳理迁移方案。02实现方案如上图所示，整个方案分为几个部份：1、系统改造，包括SQL改造，双写开关，新库sequence创建。SQL改造：加载两套TDDL数据源，一套是给老库的，一套是给新库的，并且生成两套mybatis sql 模板。双写开关：设置好写新库，写老库的开关，用于线上迁移过程中双写过程及遇到问题及时回滚。sequence创建：迁移sequence表时，需要抬升新库的sequence表中的值，用于防止主键冲突，并且需要按照主键消耗量评估一个安全值，这是非常重要的一个细节，再次强调一下。2、稳定性保障，迁库是大事，改造过程中，稳定性重中之重，主要有系统压测，线上流量回放，故障演练。系统压测：主要针对新库进行性能测，防止新库有意外情况。线上流量回放：Edsger W. Dijkstra说过如果调试程序是一种标准的可以铲除BUG的流程，那么，编程就是把他们放进来的流程。通过引入线上数据在测试环境回放，可以尽可能的发现问题，保证改造后的稳定性。故障演练：通过注入一些人为故障，如写新库失败，新库逻辑有问题，及时的演练回滚策略。3、数据迁移，主要利用阿里云数据传输服务DTS[3]的数据迁移能力，涉及到全量迁移、增量迁移、一致性校验及反向任务。全量迁移:数据迁移首要目标如何将历史全量数据迁移到新库中，我们的做法是指定一个时间点，再根据这个时间点查找每张源表的最大及最小id,然后分别批量导到目标库中，如图：整个过程都是查询在线库的备库，因此不影响在线业务的数据库服务。增量迁移:由于迁移过程中业务服务一直运行，因此全量迁移完全成，并且要将全量时间点后的数据追回来，这里核心原理是同步全量时间位点后binlog日志数据来保证数据一致性，需要注意的是增量时间需要前移一小断时间(如5分钟)，其主要原因是全量迁移启动的那刻会有时间差，需要增量前移来保证数据最终一致性，如下图:一致性校验：通过全量及增量的迁移后，此时源库跟目标的数据理论上是一致的,但实际上应用在经过功能测试，线上流量回放等阶段，数据在这个过程中有可能会现不一致的情况,因此正式上线前，需要做数据一致性校验，其原理是分批查询源表(跟全量迁移的查询方式类似)，再跟目标库进行比对,如图所示：反向任务：迁移到新库后，会有一线离线业务对老库还有依赖，需要建立从新库到老库的回流任务，原理跟增量迁移一样，只是变更一下原库及目标库。03迁库流程到这里大家应该对迁库所涉及到点比较清楚了，但还有一个非常重要的事，即梳理整个迁库步骤非常关键，通常会有两种方案。方案一：1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。3、线上开双写，线上同时写新库及老库，这时需要关闭增量同步任务，防止无效覆盖。4、线上校验，执行预先准备的测试脚本并结合一致性校验工具，同时将读流量慢慢切到新库，验证双写逻辑。5、切换数据源，关闭双写并正式写入新库。6、创建反向任务，数据回流老库。方案二：1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。3、线上切开关，写新库， 同时需要关闭增量同步任务，防止无效覆盖。4、创建反向任务，数据回流老库。方案优缺点对比：总结起来方案1迁移流程相对复杂，对迁移的控制力度更细，适合业务复杂，底层改造比较多，想精细化控制迁移步骤的场景，方案2迁移相对简单，过程快速，适合业务流程相对简单，可控，想快速切换的场景，具体选选择哪个方案，同学们可以根据自身的业务情况做选择。这里考虑到闲鱼商品业务复杂，底层改造较多，从稳定性的角度考虑，最终选择方案1。方案1，最关键的是3、4、5步骤，因此需要预先做好回滚计划。04回滚方案回滚方案总原则是不丢数据。最有可能的发生点是双写期间新库出问题，导致线上服务异常，这时只要立即关闭写新库即可，另外就是切到新库后，新库出问题了(如性能问题)，可以立即切回到老库，并通过反向任务，保持数据一致性，最后若没启用分布式事务,双写的时间越短越好,有可能会有数据不一致情况。小结通过周密的迁移方案设计，以及DTS强大的数据迁移工具的能力，闲鱼商品库顺利完成XX亿在线数据库服务迁移，独立的物理部署显著提升商品库在线服务的稳定性。然而不同业务系统的数据库情况可能会有差异，如单库向多库迁移，单表向多表迁移等，不过整体方案大致类似，希望本文迁库实践方案能给大家提供一个可行的参考。本文作者：看松阅读原文本文来自云栖社区合作伙伴“闲鱼技术”，如需转载请联系原作者。

分布式系统中一个重要的问题就是数据复制，数据复制一般是为了增强系统的可用性或提高性能。而实现数据复制的一个主要难题就是保持各个副本的一致性。本文首先讨论数据复制的场景中一致性模型如此重要的原因，然后讨论一致性模型的含义，最后分析常用的一致性模型。为什么需要一致性模型数据复制主要的目的有两个：可用性和性能。首先数据复制可以提高系统的可用性。在保持多副本的情况，有一个副本不可用，系统切换到其他副本就会恢复。常用的 MySQL 主备同步方案就是一个典型的例子。另一方面，数据复制能够提供系统的性能。当分布式系统需要在服务器数量和地理区域上进行扩展时，数据复制是一个相当重要的手段。有了多个数据副本，就能将请求分流；在多个区域提供服务时，也能通过就近原则提高客户端访问数据的效率。常用的 CDN 技术就是一个典型的例子。但是数据复制是要付出代价的。数据复制带来了多副本数据一致性的问题。一个副本的数据更新之后，其他副本必须要保持同步，否则数据不一致就可能导致业务出现问题。因此，每次更新数据对所有副本进行修改的时间以及方式决定了复制代价的大小。全局同步与性能实际上是矛盾的，而为了提高性能，往往会采用放宽一致性要求的方法。因此，我们需要用一致性模型来理解和推理在分布式系统中数据复制需要考虑的问题和基本假设。什么是一致性模型首先我们要定义一下一致性模型的术语：1. 数据存储：在分布式系统中指分布式共享数据库、分布式文件系统等。2. 读写操作：更改数据的操作称为写操作（包括新增、修改、删除），其他操作称为读操作。下面是一致性模型的定义：一致性模型本质上是进程与数据存储的约定：如果进程遵循某些规则，那么进程对数据的读写操作都是可预期的。上面的定义可能比较抽象，我们用常见的强一致性模型来通俗的解释一下：在线性一致性模型中，进程对一个数据项的读操作，它期待数据存储返回的是该数据在最后一次写操作之后的结果。这在单机系统里面很容易实现，在 MySQL 中只要使用加锁读的方式就能保证读取到数据在最后一次写操作之后的结果。但在分布式系统中，因为没有全局时钟，导致要精确定义哪次写操作是最后一次写操作是非常困难的事情，因此产生了一系列的一致性模型。每种模型都有效限制了在对一个数据项执行读操作所应该返回的值。举个例子：假设记录值 X 在节点 M 和 N 上都有副本，当客户端 A 修改了副本 M 上 X 的值，一段时间之后，客户端 B 从 N 上读取 X 的值，此时一致性模型会决定客户端 B 是否能够读取到 A 写入的值。一致性模型主要可以分为两类：能够保证所有进程对数据的读写顺序都保持一致的一致性模型称为强一致性模型，而不能保证的一致性模型称为弱一致性模型。强一致性模型线性一致性（Linearizable Consistency）线性一致性也叫严格一致性（Strict Consistency）或者原子一致性（Atomic Consistency），它的条件是：1. 任何一次读都能读取到某个数据最近的一次写的数据。2. 所有进程看到的操作顺序都跟全局时钟下的顺序一致。线性一致性是对一致性要求最高的一致性模型，就现有技术是不可能实现的。因为它要求所有操作都实时同步，在分布式系统中要做到全局完全一致时钟现有技术是做不到的。首先通信是必然有延迟的，一旦有延迟，时钟的同步就没法做到一致。当然不排除以后新的技术能够做到，但目前而言线性一致性是无法实现的。顺序一致性（Sequential Consistency）顺序一致性是 Lamport（1979）在解决多处理器系统共享存储器时首次提出来的。参考我之前写的文章《分布式系统：Lamport 逻辑时钟》。它的条件是：任何一次读写操作都是按照某种特定的顺序。所有进程看到的读写操作顺序都保持一致。首先我们先来分析一下线性一致性和顺序一致性的相同点在哪里。他们都能够保证所有进程对数据的读写顺序保持一致。线性一致性的实现很简单，就按照全局时钟（可以简单理解为物理时钟）为参考系，所有进程都按照全局时钟的时间戳来区分事件的先后，那么必然所有进程看到的数据读写操作顺序一定是一样的，因为它们的参考系是一样的。而顺序一致性使用的是逻辑时钟来作为分布式系统中的全局时钟，进而所有进程也有了一个统一的参考系对读写操作进行排序，因此所有进程看到的数据读写操作顺序也是一样的。那么线性一致性和顺序一致性的区别在哪里呢？通过上面的分析可以发现，顺序一致性虽然通过逻辑时钟保证所有进程保持一致的读写操作顺序，但这些读写操作的顺序跟实际上发生的顺序并不一定一致。而线性一致性是严格保证跟实际发生的顺序一致的。弱一致性模型因果一致性（Causal Consistency）因果一致性是一种弱化的顺序一致性模型，因为它将具有潜在因果关系的事件和没有因果关系的事件区分开了。那么什么是因果关系？如果事件 B 是由事件 A 引起的或者受事件 A 的影响，那么这两个事件就具有因果关系。举个分布式数据库的示例，假设进程 P1 对数据项 x 进行了写操作，然后进程 P2 先读取了 x，然后对 y 进行了写操作，那么对 x 的读操作和对 y 的写操作就具有潜在的因果关系，因为 y 的计算可能依赖于 P2 读取到 x 的值（也就是 P1 写的值）。另一方面，如果两个进程同时对两个不同的数据项进行写操作，那么这两个事件就不具备因果关系。无因果关系的操作称为并发操作。这里只是简单陈述了一下，深入的分析见我之前写的文章《分布式系统：向量时钟》。因果一致性的条件包括：1. 所有进程必须以相同的顺序看到具有因果关系的读写操作。2. 不同进程可以以不同的顺序看到并发的读写操作。下面我们来分析一下为什么说因果一致性是一种弱化的顺序一致性模型。顺序一致性虽然不保证事件发生的顺序跟实际发生的保持一致，但是它能够保证所有进程看到的读写操作顺序是一样的。而因果一致性更进一步弱化了顺序一致性中对读写操作顺序的约束，仅保证有因果关系的读写操作有序，没有因果关系的读写操作（并发事件）则不做保证。也就是说如果是无因果关系的数据操作不同进程看到的值是有可能是不一样，而有因果关系的数据操作不同进程看到的值保证是一样的。最终一致性（Eventual Consistency）最终一致性是更加弱化的一致性模型，因果一致性起码还保证了有因果关系的数据不同进程读取到的值保证是一样的，而最终一致性只保证所有副本的数据最终在某个时刻会保持一致。从某种意义上讲，最终一致性保证的数据在某个时刻会最终保持一致就像是在说：“人总有一天会死”一样。实际上我们更加关心的是：1. “最终”到底是多久？通常来说，实际运行的系统需要能够保证提供一个有下限的时间范围。2. 多副本之间对数据更新采用什么样的策略？一段时间内可能数据可能多次更新，到底以哪个数据为准？一个常用的数据更新策略就是以时间戳最新的数据为准。由于最终一致性对数据一致性的要求比较低，在对性能要求高的场景中是经常使用的一致性模型。以客户端为中心的一致性（Client-centric Consistency）前面我们讨论的一致性模型都是针对数据存储的多副本之间如何做到一致性，考虑这么一种场景：在最终一致性的模型中，如果客户端在数据不同步的时间窗口内访问不同的副本的同一个数据，会出现读取同一个数据却得到不同的值的情况。为了解决这个问题，有人提出了以客户端为中心的一致性模型。以客户端为中心的一致性为单一客户端提供一致性保证，保证该客户端对数据存储的访问的一致性，但是它不为不同客户端的并发访问提供任何一致性保证。举个例子：客户端 A 在副本 M 上读取 x 的最新值为 1，假设副本 M 挂了，客户端 A 连接到副本 N 上，此时副本 N 上面的 x 值为旧版本的 0，那么一致性模型会保证客户端 A 读取到的 x 的值为 1，而不是旧版本的 0。一种可行的方案就是给数据 x 加版本标记，同时客户端 A 会缓存 x 的值，通过比较版本来识别数据的新旧，保证客户端不会读取到旧的值。以客户端为中心的一致性包含了四种子模型：1. 单调读一致性（Monotonic-read Consistency）：如果一个进程读取数据项 x 的值，那么该进程对于 x 后续的所有读操作要么读取到第一次读取的值要么读取到更新的值。即保证客户端不会读取到旧值。2. 单调写一致性（Monotonic-write Consistency）：一个进程对数据项 x 的写操作必须在该进程对 x 执行任何后续写操作之前完成。即保证客户端的写操作是串行的。3. 读写一致性（Read-your-writes Consistency）：一个进程对数据项 x 执行一次写操作的结果总是会被该进程对 x 执行的后续读操作看见。即保证客户端能读到自己最新写入的值。4. 写读一致性（Writes-follow-reads Consistency）：同一个进程对数据项 x 执行的读操作之后的写操作，保证发生在与 x 读取值相同或比之更新的值上。即保证客户端对一个数据项的写操作是基于该客户端最新读取的值。总结数据复制导致了一致性的问题，为了保持副本的一致性可能会严重地影响性能，唯一的解决办法就是放松一致性的要求。通过一致性模型我们可以理解和推理在分布式系统中数据复制需要考虑的问题和基本假设，便于结合具体的业务场景做权衡。每种模型都有效地限制了对一个数据项执行度操作应返回的值。通常来说限制越少的模型越容易应用，但一致性的保证就越弱。参考资料《分布式系统原理与范型》Distributed systems for fun and profitConsistency_model本文作者：肖汉松阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

今天遇到一个问题，Mysql持续报错，主从同步延时数过大或错误。所以这篇文章给大家分享下主从同步的机制原理以及问题排查思路。故障表现最直观的表现为：mysql> show slave status\G; // 状态一 Seconds_Behind_Master: NULL // 状态二 Seconds_Behind_Master: 0 // 状态三 Seconds_Behind_Master: 79连续查询，大部分时间该属性值=0，偶发性出现Null或者79等延时值。导致观察主从同步延时的监控持续报警。故障原因及解决方案多台备机的server-id一致，导致主机无法长时间同某一台备机连接，进而无法正常同步。修改server-id后，重启数据库恢复。主从同步机制MySQL的主从同步，又称为复制（replication），是一种内置的高可用高性能集群解决方案，主要功能有：数据分布：同步不需要很大带宽，可以实现多数据中心复制数据。读取的负载均衡：通过服务器集群，可以通过DNS轮询、Linux LVS等GSLB（全局负载均衡）方式，降低主服务器的读压力。数据库备份：复制是备份的一部分，但并不能代替备份。还需要与快照相结合。高可用性和故障转移：从服务器可以快速切换为主服务器，减少故障的停机时间和恢复时间。主从同步分为3步：主服务器（master）把数据更改记录到二进制日志（binlog）中。从服务器（slave）把主服务器的二进制日志复制到自己的中继日志（relay log）中。从服务器重做中继日志中的日志，把更改应用到自己的数据库上，达到数据的一致性。主从同步是一个异步实时的同步，会实时的传输，但存在执行上的延时，如果主服务器压力很大，延时也会相应扩大。通过上面的图，可以看到一共需要3个线程：主服务器的日志传送线程：负责将二进制日志增量传送到备机从服务器的I/O线程：负责读取主服务器的二进制日志，并保存为中继日志从服务器的SQL线程，负责执行中继日志查看MySQL线程我们可以使用show full processlist;命令来查看MySQL的状态：主机的状态：备机的状态：可以看到，我的集群架构为1台主机、4台备机，所以在主机中有4个同步线程（已经发送所有的binlog数据到备机，等待binlog日志更新），1个查看命令线程（show full processlist）。在备机中有1个查看命令线程，1个I/O线程（等待主机发送同步数据事件），1个SQL线程（已经读取了所有中继日志，等待I/O线程来更新它）。查看同步状态因为主从同步是异步实时的，也就是会存在延时的情况，我们可以通过show slave status;来查看备机上的同步延时：在主从同步中我们需要关注的一些属性，已经给大家标红了：Slave_IO_State: 当前I/O线程的状态Master_Log_File: 当前同步的主服务器的二进制文件Read_Master_Log_Pos: 当前同步的主服务器的二进制文件的偏移量，单位为字节，如图中为已经同步了12.9M(13630580/1024/1024)的内容Relay_Master_Log_File: 当前中继日志同步的二进制文件Slave_IO_Running: 从服务器中I/O线程的运行状态，YES为运行正常Slave_SQL_Running: 从服务器中SQL线程的运行状态，YES为运行正常Exec_Master_Log_Pos: 表示同步完成的主服务器的二进制日志偏移量Seconds_Behind_Master: 表示从服务器数据比主服务器落后的持续时长同样可以通过show master status;命令来查看主服务器的运行状态：正常运行的主从同步状态：Slave_IO_Running: YESSlave_SQL_Running: YESSeconds_Behind_Master: 0问题排查在理解了主从同步的机制后，再来看今天遇到的问题，通过查看备机状态，我们观察在三种状态下的几个关键属性值：mysql> show slave status\G;#状态一： Slave_IO_State: Reconnecting after a failed master event read Slave_IO_Running: No Slave_SQL_Running: Yes Seconds_Behind_Master: NULL#状态二： Slave_IO_State: Waiting for master to send event Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0#状态三： Slave_IO_State: Queueing master event to the relay log Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 636通过MySQL主从复制线程状态转变，我们可以看到三种状态的不同含义：# 状态一# 线程正尝试重新连接主服务器，当连接重新建立后，状态变为Waiting for master to send event。Reconnecting after a failed master event read# 状态二# 线程已经连接上主服务器，正等待二进制日志事件到达。如果主服务器正空闲，会持续较长的时间。如果等待持续slave_read_timeout秒，则发生超时。此时，线程认为连接被中断并企图重新连接。Waiting for master to send event# 状态三# 线程已经读取一个事件，正将它复制到中继日志供SQL线程来处理。Queueing master event to the relay log在这里，我们可以猜测，由于某些原因，从服务器不断的和主服务器进行断开并尝试重连，重连成功后又再次断开。我们再看看主机的运行情况：发现问题出在10.144.63.*和10.144.68.*两台机器上，我们查看其中一台的错误日志：190214 11:33:20 [Note] Slave: received end packet from server, apparent master shutdown: 190214 11:33:20 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log ‘mysql-bin.005682’ at postion 13628070拿到关键字Slave: received end packet from server, apparent master shutdown: Google搜索一下，在文章Confusing MySQL Replication Error Message中可以看到原因为两台备机的server-id重复。One day it happen to me, and took me almost an hour to find that out.Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.Could MySQL just use the servername intead of a numeric value?问题修复定位了问题，我们确认下是否重复，发现两台备机的该字段确实相同：vim my.cnf#replicationlog-bin=mysql-bin# 这个随机数字相同导致的server-id=177230069sync_binlog=1更改一个其他不同的数字，保存，重启MySQL进程，报警恢复。总结最终来看，这个问题的解决非常简单，但从刚开始的迷茫到最后的思路清晰，都是我们排查问题所常见的，这篇文章的主要收获是让你明白主从同步的机制和追查问题的思路，希望下次我们都能很快的解决主从同步带给我们的问题。参考资料《MySQL基础内幕 InnoDB存储引擎 第2版》P8.7 复制MySQL主从复制线程状态转变: http://www.ywnds.com/?p=3821Confusing MySQL Replication Error Message: https://www.percona.com/blog/… ...

分析core不是一件容易的事情。试想，一个系统运行了很长一段时间，在这段时间里，系统会积累大量正常、甚至不正常的状态。这个时候如果系统突然出现了一个问题，那这个问题十有八九跟长时间积累下来的状态有关系。分析core，就是分析出问题时，系统产生的“快照”，追溯历史，找出问题发生源头。这有点像是从案发现场，推导案发经过一样。soft lockup！今天这个“案件”，我们从soft lockup说起。soft lockup是内核实现的夯机自我诊断功能。这个功能的实现，和线程的优先级有关系。这里我们假设有三个线程A、B、和C。他们的优先级关系是A<B<C。这意味着C优先于B执行，B优先于A执行。这个优先级关系，如果倒过来叙述，就会产生一个规则：如果C不能执行，那么B也没有办法执行，如果B不能执行，那基本上A也没法执行。soft lockup实际上就是对这个规则的实现：soft lockup使用一个内核定时器（C线程），周期性地检查，watchdog（B线程）有没有正常运行。如果没有，那就意味着普通线程（A线程）也没有办法正常运行。这时内核定时器（C线程）会输出类似上图中的soft lockup记录，来告诉用户，卡在cpu上的，有问题的线程的信息。具体到这个“案件”，卡在cpu上的线程是python，这个线程正在刷新tlb缓存。老搭档ipi和tlb如果我们对所有夯机问题的调用栈做一个统计的话，我们肯定会发现，tlb和ipi是一对形影不离的老搭档。其实这不是偶然的。系统中，相对于内存，tlb是处理器本地的cache。这样的共享内存和本地cache的架构，必然会提出一致性的要求。如果每个处理器的tlb“各自为政”的话，那系统肯定会乱套。满足tlb一致性的要求，本质上来说只需要一种操作，就是刷新本地tlb的同时，同步地刷新其他处理器的tlb。系统正是靠tlb和ipi这对老搭档的完美配合来完成这个操作的。这个操作本身的代价是比较大的。一方面，为了避免产生竞争，线程在刷新本地tlb的时候，会停掉抢占。这就导致一个结果：其他的线程，当然包括watchdog线程，没有办法被调度执行（soft lockup）。另外一方面，为了要求其他cpu同步地刷新tlb，当前线程会使用ipi和其他cpu同步进展，直到其他cpu也完成刷新为止。其他cpu如果迟迟不配合，那么当前线程就会死等。不配合的cpu为什么其他cpu不配合去刷新tlb呢？理论上来说，ipi是中断，中断的优先级是很高的。如果有cpu不配合去刷新tlb，基本上有两种可能：一种是这个cpu刷新了tlb，但是做到一半也卡住了；另外一种是，它根本没有办法响应ipi中断。通过查看系统中所有占用cpu的线程，可以看到cpu基本上在做三件事情：idle，正在刷新tlb，和正在运行java程序。其中idle的cpu，肯定能在需要的时候，响应ipi并刷新tlb。而正在刷新tlb的cpu，因为停掉了抢占，且在等待其他cpu完成tlb刷新，所以在重复输出soft lockup记录。这里问题的关键，是运行java的cpu，这个我们在下一节讲。java不是问题，踩到的坑才是问题java线程运行在0号cpu上，这个线程的调用栈，满满的都是故事。我们可以简单地把线程调用栈分为上下两部分。下边的是system call调用栈，是java从系统调用进入内核的执行记录。上边的是中断栈，java在执行系统调用的时候，正好有一个中断进来，所以这个cpu临时去处理了中断。在linux内核中，中断和系统调用使用的是不同的内核栈，所以我们可以看到第二列，上下两部分地址是不连续的。netoops持有等待分析中断处理这部分调用栈，从下往上，我们首先会发现，netoops函数触发了缺页异常。缺页异常其实就是给系统一个机会，把指令踩到的虚拟地址，和真正想要访问的物理机之间的映射关系给建立起来。但是有些虚拟地址，这种映射根本就是不存在的，这些地址就是非法地址（坑）。如果指令踩到这样的地址，会有两种后果，segment fault（进程）和oops（内核）。很显然netoops踩到了非法地址，使得系统进入了oops逻辑。系统进入oops逻辑，做的第一件事情就是禁用中断。这个非常好理解。oops逻辑要做的事情是保存现场，它当然不希望，中断在这个时候破坏问题现场。接下来，为了保存现场的需要，netoops再一次被调用，然后这个函数在几条指令之后，等在了spinlock上。要拿到这个spinlock，netoops必须要等它当前的owner线程释放它。这个spinlock的owner是谁呢？其实就是当前线程。换句话说，netoops拿了spinlock，回过头来又去要这个spinlock，导致当前线程死锁了自己。验证上边的结论，我们当然可以去读代码。但是有另外一个技巧。我们可以看到netoops函数在踩到非法地址的时候，指令rip地址是ffffffff8137ca64，而在尝试拿spinlock的时候，rip是ffffffff8137c99f。很显然拿spinlock在踩到非法地址之前。虽然代码里的跳转指令，让这种判断不是那么的准确，但是大部分情况下，这个技巧是很有用的。缺页异常，错误的时间，错误的地点这个线程进入死锁的根本原因是，缺页异常在错误的时间发生在了错误的地点。对netoops函数的汇编和源代码进行分析，我们会发现，缺页发生在ffffffff8137ca64这条指令，而这条指令是inline函数utsname的指令。下图中框出来的四条指令，就是编译后的utsname函数。而utsname函数的源代码其实就一行。return &current->nsproxy->uts_ns->name;这行代码通过当前进程的task_struct指针current，访问了uts namespace相关的内容。这一行代码，之所以会编译成截图中的四条汇编指令，是因为gs寄存器的0xcbc0项，保存的就是current指针。这四条汇编指令做的事情分别是，取current指针，读nsproxy项，读uts_ns项，以及计算name的地址。第三条指令踩到非法地址，是因为nsproxy这个值为空值。空值nsproxy我们可以在两个地方验证nsproxy为空这个结论。第一个地方是读取当前进程task_sturct的nsproxy项。另外一个是看缺页异常的时候，保存下来的rax寄存器的值。保存下来的rax寄存器值可以在图三中看到，下边是从task_struct里读出来的nsproxy值。正在退出的线程那么，为什么当前进程task_struct这个结构的nsproxy这一项为空呢？我们可以回头看一下，java线程调用栈的下半部分内容。这部分调用栈实际上是在执行exit系统调用，也就是说进程正在退出。实际上参考代码，我们可以确定，这个进程已经处于僵尸（zombie）状态了。因而nsproxy相关的资源，已经被释放了。namespace访问规则最后我们简单看一下nsproxy的访问规则。规则一共有三条，netoops踩到空指针的原因，某种意义上来说，是因为它间接地违背了第三条规则。netoops通过utsname访问进程的namespace，因为它在中断上下文，所以并不算是访问当前的进程，也就是说它应该查空。另外我加亮的部分，进一步佐证了上一小节的结论。/*``* the namespaces access rules are:``*``* 1\. only current task is allowed to change tsk-&gt;nsproxy pointer or``* any pointer on the nsproxy itself``*``* 2\. when accessing (i.e. reading) current task's namespaces - no``* precautions should be taken - just dereference the pointers``*``* 3\. the access to other task namespaces is performed like this``* rcu_read_lock();``* nsproxy = task_nsproxy(tsk);``* if (nsproxy != NULL) {``* / *``* * work with the namespaces here``* * e.g. get the reference on one of them``* * /``* } / *``* * NULL task_nsproxy() means that this task is``* * almost dead (zombie)``* * /``* rcu_read_unlock();``*``*/回顾最后我们复原一下案发经过。开始的时候，是java进程退出。java退出需要完成很多步骤。当它马上就要完成自己使命的时候，一个中断打断了它。这个中断做了一系列的动作，之后调用了netoops函数。netoops函数拿了一个锁，然后回头去访问java的一个被释放掉的资源，这触发了一个缺页。因为访问的是非法地址，所以这个缺页导致了oops。oops过程禁用了中断，然后调用netoops函数，netoops需要再次拿锁，但是这个锁已经被自己拿了，这是典型的死锁。再后来其他cpu尝试同步刷新tlb，因为java进程关闭了中断而且死锁了，它根本收不到其他cpu发来的ipi消息，所以其他cpu只能不断的报告soft lockup错误。本文作者：声东阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

Dragonfly 是一个由阿里巴巴开源的云原生镜像分发系统，主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发难题。随着企业数字化大潮的席卷，行业应用纷纷朝微服务架构演进，并通过云化平台优化业务管理。Dragonfly 源于阿里巴巴，从实际落地场景出发，前瞻性地解决了云原生镜像分发的__效率、流控与安全__三大难题。Dragonfly 目前承载了阿里全集团 90%以上的文件下载任务、日分发峰值达到 1 亿次，100%成功支撑双十一营销活动数据抵达数万台机器，github Star 数已达到 2500+。2018 年 11 月 14 日已正式进入 CNCF，成为 CNCF 沙箱级别项目（Sandbox Level Project）。Dragonfly 的由来随着阿里集团业务爆炸式增长，2015 年时发布系统日均发布量突破两万，很多应用的机器规模开始破万，发布失败率开始增高，而根本原因则是发布过程需要大量的文件拉取，文件服务器扛不住大量的请求，当然第一时间会想到服务器扩容，可是扩容后又发现后端存储成为瓶颈且扩容成本也非常巨大（按照我们的计算，为了满足业务需求，不阻碍业务的发展，后续至少需要 2000 台高配物理机且上不封顶）。此外，大量来自不同 IDC 的客户端请求消耗了巨大的网络带宽，造成网络拥堵。同时，阿里巴巴很多业务走向国际化，大量的应用部署在海外，海外服务器下载要回源国内，浪费了大量的国际带宽，而且还很慢；如果传输大文件，网络环境差，失败的话又得重来一遍，效率极低。于是我们很自然的就想到了 P2P 技术，P2P 技术并不新鲜，当时也调研了很多国内外的系统，但是调研的结论是这些系统的规模和稳定性都无法达到我们的期望，因此就有了Dragonfly这个产品的诞生。Dragonfly 能解决哪些问题作为一款通用文件分发系统，Dragonfly 主要能够解决以下几个方面的问题：大规模下载问题：应用发布过程中需要下载软件包或者镜像文件，如果同时有大量机器需要发布，比如 1000台，按照 500MB 大小的镜像文件计算，如果直接从镜像仓库下载，假设镜像仓库的带宽是 10000Mbps，那么理想状态下至少需要 10 分钟，而且实际情况很可能是仓库早已被打挂。远距离传输问题：针对跨地域跨国际的应用，比如阿里速卖通，它既要在国内部署，又要在美国和俄罗斯部署，而存储软件包的源一般只在一个地域，比如国内上海，那么在美国或者俄罗斯的机器当要下载软件包的时候就要通过国际网络传输，但是国际网络不仅延时高而且极不稳定，严重影响传输效率，进而导致业务不能及时上线新功能或者问题补丁，由此甚至会产生业务故障。带宽成本问题：除了传输效率问题，高昂的带宽成本也是一个非常严重的问题，很多互联网公司尤其是视频相关的公司，带宽成本往往可以占据其总体成本的很大一部分。安全传输问题：据统计，每年因为网络安全问题导致的经济损失高达 4500 亿美元，所以安全必须是第一生命线，文件传输过程中如果不加入任何安全机制，文件内容很容易被嗅探到，假设文件中包含账号或者秘钥之类的数据，一旦被截获，后果将不堪设想。Dragonfly 是如何解决这些问题的通过 P2P 技术解决大规模镜像下载问题，原理如下：针对上图有几个概念需要先解释：PouchContainer：阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术。Registry：容器镜像的存储仓库，每个镜像由多个镜像层组成，而每个镜像层又表现为一个普通文件。Block：当通过Dragonfly下载某层镜像文件时，蜻蜓的SuperNode会把整个文件拆分成一个个的块，SuperNode 中的分块称为种子块，种子块由若干初始客户端下载并迅速在所有客户端之间传播，其中分块大小通过动态计算而来。SuperNode：Dragonfly的服务端，它主要负责种子块的生命周期管理以及构造 P2P 网络并调度客户端互传指定分块。DFget__：__Dragonfly的客户端，安装在每台主机上，主要负责分块的上传与下载以及与容器 Daemon 的命令交互Peer：下载同一个文件的 Host 彼此之间称为 Peer。主要下载过程如下：首先由 Pouch Container 发起 Pull 镜像命令，该命令会被 DFget 代理截获。然后由 DFget 向 SuperNode 发送调度请求。SuperNode 在收到请求后会检查对应的文件是否已经被缓存到本地，如果没有被缓存，则会从 Registry 中下载对应的文件并生成种子块数据（种子块一旦生成就可以立即传播，而并不需要等到 SuperNode 下载完成整个文件后才开始分发），如果已经被缓存，则直接生成分块任务。客户端解析相应的任务并从其他 Peer 或者 SuperNode 中下载分块数据，当某个 Layer 的所有分块下载完成后，一个 Layer 也就下载完毕，此时会传递给容器引擎使用，而当所有的 Layer 下载完成后，整个镜像也就下载完成了。通过上述 P2P 技术，可以彻底解决镜像仓库的带宽瓶颈问题，充分利用各个 Peer 的硬件资源和网络传输能力，达到规模越大传输越快的效果。Dragonfly的系统架构不涉及对容器技术体系的任何改动，完全可以无缝支持容器使其拥有 P2P 镜像分发能力，以大幅提升文件分发效率！结合 CDN 与预热技术解决远距离传输问题通过 CDN 缓存技术，每个客户端可以就近从 SuperNode 中下载种子块，而无需跨地域进行网络传输，CDN 缓存原理大致如下：同一个文件的第一个请求者会触发检查机制，根据请求信息计算出缓存位置，如果缓存不存在，则触发回源同步操作生成种子块；否则向源站发送 HEAD 请求并带上 If-Modified-Since 字段，该字段的值为上次服务器返回的文件最后修改时间，如果响应码为 304，则表示源站中的文件目前还未被修改过，缓存文件是有效的，然后再根据缓存文件的元信息确定文件是否是完整的，如果完整，则缓存完全命中；否则需要通过断点续传方式把剩下的文件分段下载过来，断点续传的前提是源站必须支持分段下载，否则还是要同步整个文件。如果 HEAD 请求的响应码为200，则表示源站文件已被修改过，缓存无效，此时需要进行回源同步操作；如果响应码既不是 304 也不是 200，则表示源站异常或地址无效，下载任务直接失败。通过 CDN 缓存技术可以解决客户端回源下载以及就近下载的问题，但是如果缓存不命中，针对跨域远距离传输的场景，SuperNode 回源同步的效率将会非常低，这会直接影响到整体的分发效率，为了解决该问题，Dragonfly采用了一种自动化层级预热机制来最大程度的提升缓存命中率，其大致原理如下：通过 Push 命令把镜像文件推送到 Registry 的过程中，每推送完一层镜像就会立即触发 SuperNode 以 P2P 方式把该层镜像同步到 SuperNode 本地，通过这种方式，可以充分利用用户执行Push和Pull操作的时间间隙（大概10分钟左右），把镜像的各层文件同步到 SuperNode 中，这样当用户执行 Pull 命令时，就可以直接利用 SuperNode 中的缓存文件，自然而然也就没有远距离传输的问题了。通过动态压缩和智能化调度解决带宽成本问题通过动态压缩，可以在不影响 SuperNode 和 Peer 正常运行的情况下，对文件中最值得压缩的部分实施相应的压缩策略，从而可以节约大量的网络带宽资源，同时还能进一步提升分发速率，相比于传统的 HTTP 原生压缩方式，动态压缩主要有以下几个方面的优势：动态压缩的优势首先自然是动态性，它可以保证只有在 SuperNode 和 Peer 负载正常的情况下才会开启压缩，同时只会对文件中最值得压缩的分块进行压缩且压缩策略也是动态确定的；此外，通过多线程压缩方式可以大幅提升压缩速率，而且借助 SuperNode 的缓存能力，整个下载过程只需要压缩一次即可，压缩收益比相对于 HTTP 原生方式至少提升 10 倍。除了动态压缩外，通过 SuperNode 强大的任务调度能力，可以尽量使在同一个网络设备下的 Peer 互传分块，减少跨网络设备、跨机房的流量，从而进一步降低网络带宽成本。通过加密插件解决安全传输问题在下载某些敏感类文件（比如秘钥文件或者账号数据之类的文件）时，传输的安全性必须要得到有效保障，在这方面，Dragonfly主要做了以下几个方面的工作：支持 HTTP Header 传输，以满足那些需要通过 Header 来进行权限验证的下载请求通过自研的数据存储协议对数据块进行包装传输，后续还会对包装的数据进行再加密即将支持安全加密功能插件化通过多重校验机制，可以严格防止数据被篡改Dragonfly目前的成熟度如何在阿里巴巴集团内部，Dragonfly作为全集团基础技术构件，目前已经承载了全集团 90%以上的文件下载任务，包括镜像文件、应用软件包、算法数据文件、静态资源文件以及索引文件等等，日分发峰值目前可以达到 1 亿次，为集团业务提供了高效稳定的文件分发能力；同时，每年双十一大家买买买的过程中，其中最为关键的营销活动数据（数 GB 大小）也是在将近零点的时候通过Dragonfly来成功（100%成功）抵达数万台机器上的，万一在这个过程中有一点点问题，双十一会如何，你懂的……目前 Dragonfly 也已经开源，在开源社区中， 目前 Star 数 2500+，同时有非常多的外部用户对 Dragonfly 表现出浓厚的兴趣，也有很多外部公司正在使用 Dragonfly 来解决他们在镜像或者文件分发方面遇到的各种问题，比如中国移动、滴滴、科大讯飞等；此外，Dragonfly 已成为全中国第三个进入CNCF Sandbox 级别的项目，后续我们还会继续加油努力，争取尽快毕业！通过以上介绍，我相信针对Dragonfly是否足够成熟，大家心里应该也有杆秤了吧，当然，Dragonfly还有很多事情需要不断完善和改进，在这里诚邀各路人才，一起把Dragonfly打造成一款世界级的产品！未来规则展望成为CNCF毕业项目，为云原生应用提供更加丰富和强大的文件分发能力。开源版与集团内部版融合，给社区开放出更多的高级特性。智能化方面进行更多探索和改进。本文作者：amber涂南阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

[原文地址：https://blog.ti-node.com/blog…]要想更好了解socket编程，有一个不可绕过的环节就是IO．在Linux中，一切皆文件．实际上要文件干啥？不就是读写么？所以，这句话本质就是"IO才是王道"．用php的fopen打开文件关闭文件读读写写，这叫本地文件IO．在socket编程中，本质就是网络IO．所以，在开始进一步的socket编程前，我们必须先从概念上认识好IO．如果到这里你还对IO没啥概念，那么我就通过几个词来给你一个大概的印象：同步，异步，阻塞，非阻塞，甚至是同步阻塞，同步非阻塞，异步阻塞，异步非阻塞．是不是晕了？截至到目前为止，你可以简单地认为只要搞明白这几个名词的含义以及区别，就算弄明白IO了，至少了可以继续往下看了．先机械记忆一波儿：IO分为两大种，同步和异步．同步IO：阻塞IO非阻塞IOIO多路复用（包括select，poll，epoll三种）信号驱动IO异步IO那么如何理解区别这几个概念呢？尤其是同步和阻塞，异步和非阻塞，看起来就是一样的．我先举个例子结合自己的理解来说明一下：你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，你自己看着点儿！＂．于是你就站在旁边只等馒头．此时的你，是阻塞的，是同步的．阻塞表现在你除了等馒头，别的什么都不做了．同步表现在等馒头的过程中，阿梅不提供通知服务，你不得不自己要等到＂馒头出炉＂的消息．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，你自己看着点儿！＂．于是你就站在旁边发微信，然后问一句：＂好了没？＂，然后发QQ，然后再问一句：＂好了没？＂．此时的你，是非阻塞的，是同步的．非阻塞表现在你除了等馒头，自己还干干别的时不时会主动问问馒头好没好．同步表现在等馒头的过程中，阿梅不提供通知服务，你不得不自己要等到＂馒头出炉＂的消息．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，蒸好了我打电话告诉你！＂．但你依然站在旁边只等馒头，此时的你，是阻塞的，是异步的．阻塞表现在你除了等馒头，别的什么都不做了．异步表现在等馒头的过程中，阿梅提供电话通知＂馒头出炉＂的消息，你只需要等阿梅的电话．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，蒸好了我打电话告诉你！＂．于是你就走了，去买了双新球鞋，看了看武馆，总之，从此不再过问馒头的事情，一心只等阿梅电话．此时的你，是非阻塞的，是异步的．非阻塞表现在你除了等馒头，自己还干干别的时不时会主动问问馒头好没好．异步表现在等馒头的过程中，阿梅提供电话通知＂馒头出炉＂的消息，你只需要等阿梅的电话．如果你仔细品过上面案例中的每一个字，你就能慢慢体会到之所以异步和非阻塞，同步和阻塞容易混淆，仅仅是因为二者的表现形式稍微有点儿相似而已．阻塞和非阻塞关注的是：在等馒头的过程中，你在干啥．同步和异步关注的是：等馒头这件事，你是一直等到＂馒头出炉＂的结果，还是立即跑路等阿梅告诉你的＂馒头出炉＂．重点的是你是如何得知＂馒头出炉＂的．所以现实世界中，最傻的人才会采用异步阻塞的IO方式去写程序．其余三种方式，更多的人都会选择同步阻塞或者异步非阻塞．同步非阻塞最大的问题在于，你需要不断在各个任务中忙碌着，导致你的大脑混乱，非常累．[原文地址：https://blog.ti-node.com/blog…]