这篇文章是根据我在SFDC(SegmentFault Developer Conference)大会上的分享整理而成。

今天我给大家分享的题目是『基础设施服务的微服务化』。微服务这一两年非常火，今天的服务器端的分享主题应该至少90%和微服务相关。同时你会发现，云，容器等技术的发展都是在给微服务铺路，因为用户本质上需要的是服务，不是资源。但大多数和微服务相关的讨论都是分析业务应用如何微服务化，如何远程调用，如何服务治理，谈论基础设施服务的却很少，我们今天来聊聊这个。

讨论微服务，遇到的第一个问题就是多微的服务才能叫微服务呢？是否有个标准，比如多少行代码，多少个方法，多少个接口？

我们来看看微服务这个概念的最早定义：

我们不用全部仔细看完，只需看看我标出来的几个关键词：

1. small service这个好理解，就是微服务就是小服务。
2. independently deployable可独立部署。微服务就是将原来的共享库的依赖方式，改为远程调用的依赖方式，每个微服务都是独立部署的服务。
3. fully automated deployment完全的自动化部署。这点往往被大家忽略，为什么微服务就要完全的自动化部署呢？因为以前的几个服务，被拆分为成百上千的服务，如果没有完全的自动化部署，基本上是不可维护的。当然，你可以说『我就是不差钱，我就招上千个人来管这些服务』：）就不叫微服务了？也能行，但这也违背了我们搞微服务的目标吧。

所以我们再回归到微服务这个概念。我个人认为微服务化本身包含两层意思，一层是拆，这个大家提到的多，将大的服务拆成小的服务粒度，通过远程调用解决依赖。但同时它也有另外一层意思，就是合，就是整个系统的微服务的所有组件之间应该是一个整体的分布式系统，按集群化的方式来设计，服务之间能互相感知，进行自动化协作。

我们来看一个微服务的一个例子。

这里面有ABCD四个服务，每个服务都依赖数据库以及缓存，对外的服务有负载均衡器，服务之间互相依赖，异步交互通过队列进行。通过这样一个简单的微服务例子，我们可以看出基础设施都有哪些。

那我们的问题就来了 — 基础设施服务是否需要微服务化？

要解答这个问题，我们先看看当前的基础设施服务的主要解决方案：

第一种是大的互联网公司普遍使用的一种方案。基础设施服务托管给基础设施部门，基础设施部门包含运维，DBA 等。比如开发人员需要一套 mysql 服务的时候，提出申请，基础设施部门负责搭建和运维，开发人员只需要连接 mysql 的 IP 进行使用即可。另外一种方式是托管给云厂商，是使用当前云的基础设施服务。比如QingCloud，AWS，还有阿里云等，都提供基础设施服务，比如需要一套 mysql，在控制台即可创建，然后获取到连接 IP ，这样可以省去运维基础设施服务的成本。

但是这两种方式都有一些问题：

1. 开发测试流程中的基础设施服务如何部署，如何自动化？这个没法委托给基础设施部门，需要开发人员自己动手搞。但开发人员一方面也没有精力搞一套完整的自动化工具，但即便是搞了，也解决不了开发环境和线上环境异构的问题。前面有位讲师的分享也说到了这个问题，异构问题总会导致故障，没出现故障也是时候没到。
2. 另外一个问题就是基础设施服务迁移、伸缩、故障恢复时应用如何感知？比如有个 mysql 集群，当前数据库请求量太大，扩容了从库，应用如何自动感知到这个变化，从而使用新的从库？

我们再回顾下微服务的要求：

当前的基础设施服务的解决方案，不能满足微服务的集群化，自动化这两点要求。我们可以得出结论：

基础设施服务属于微服务系统中的一部分，需要和业务服务互相感知，需要被微服务化。

这就引出了我们的另外一个问题：

基础设施服务如何微服务化？这个主要有以下难点：

基础设施服务种类多样。比如前面那个简单的微服务系统，就用到了很多基础设施服务，各种服务的有各种不同的配置方式。同时，这些服务的集群机制也是多种多样的。我们举几个例子来说明下。

Zookeeper 的主要配置文件是 zoo.cfg，这个配置文件中需要列出整个集群中的所有节点，以及对应的server id。另外，每个节点还有一个独立的 myid 配置文件，这个文件中写了当前节点的 server id。比如要把这个集群扩展到5个节点，首先要要算出新的节点的 server id 号，生成新的节点的myid 配置文件，同时需要变更每个节点的 zoo.cfg 配置文件，把新节点的 server id 和 IP 都写进去，然后重启服务。

HAproxy 的配置文件中的每个 backend 后会配置一个 server 列表。如果后端服务伸缩，就需要变更这个 server 列表。

Redis Cluster 的这个例子我只是想说明下， redis 并不是通过配置文件来维护集群信息的，而是通过动态命令。创建集群，增删节点，都需要调用命令进行。

Kafka 是通过 Zookeeper 来做服务发现的，所以如果 Zookeeper 集群变更，就需要变更它的配置文件中的 zookeeper.connect 配置项。

粗略的看了以上的几个例子，大家对基础设施服务的配置和集群的多样性有了初步的体验。既然要微服务化，就需要设计服务的注册发现以及配置变更方案。微服务理想中的方案是应用内部自发现，监听配置中心，自动进配置变更。但现实的状况我们前面的例子也看到了，我们也不可能等待这么多的服务逐渐都改造升级了再用，所以唯一可行的办法就是通过非侵入的方式，进行第三方的服务注册，以及配置变更。

下面我介绍一下我们 QingCloud 应用调度系统的一些实践。

我们在 IaaS 调度系统之上构建了应用集群的调度系统，它知道集群里的 vm 节点的变化，然后将集群的基础信息注册到我们的元信息服务 metad 中。每个 vm 节点里面都运行一个 confd 进程，监听 metad 的元信息，一旦发生变化，则变更本地的配置和服务。比如左图的这个例子，应用集群依赖一个 zookeeper 集群，二者都关联在 metad 中。如果 zookeeper 集群的节点发生变化，应用集群是可以通过 metad 感知到变化，并且通过 confd 进行配置变更。下面我分别简单介绍一下使用到的一些组件。

Etcd 是一个开源的分布式的一致性 kv 存储，提供元信息的持久化，同时它支持 watch 机制，可以实现变更推送。

Metad 是我们自己研发的一个开源的元信息服务。它的后端对接 etcd ，和 etcd 实时同步数据。我们前面也说了，当前我们的方案是通过调度系统进行服务注册。这种注册方式有一个问题就是，节点启动的时候，它不清楚自己所处的角色，也就是不知道『我是谁』。人生哲学的头一个难题就是回答『我是谁』，服务器也有这个困境。所以我们在 metad 中保存了 IP 到元信息之间的映射关系，客户端请求一个固定的接口 /self 就可以拿到自己本节点的信息，当前节点所处的集群的信息，以及当前集群依赖的其他集群的信息。它也支持 watch 机制，实现变更推送。

Confd 是一个开源的配置变更工具，我们在其基础上进行了二次开发，后端对接 metad。它通过监听 metad 的变更通知，同步元信息到本地缓存，然后根据模板渲染配置文件，如果发现配置不一样，则进行应用的配置变更，同时触发脚本让应用程序重新加载配置（reload 或者 restart）。下面我们通过一个例子来说明下。

还是一个 zookeeper 的例子，我们首先有个集群的编排配置文件，定义了其中每个节点的镜像，cpu，内存，磁盘，节点数量，以及启动，停止等 service 脚本。

我们给 zoo.cfg 定义了一个配置文件模板，这个模板是给 confd 用来渲染配置文件的。模板的语法是 go template 语法，如果不熟悉这个模板语法也没关系，大家可以看出这段脚本是在循环配置中心的 hosts 列表，然后生成 server id 和 IP 之间的映射配置。

这是那个 myid 配置文件的模板，这个很简单，我们给集群的每个几点都会分配一个 sid，这种情况，直接吧 sid 写到 myid 配置文件就好。

同时，我们的集群编排支持 kvm 和 docker 两种镜像，这样就可以实现 kvm 和 docker 的混排。如果应用有特殊需求 docker 镜像不能满足，比如 kernel 版本，则可以使用 kvm 镜像。当然我们这里的 docker 镜像不是标准的 docker 镜像方式，镜像默认启动的进程，也就是 init 进程必须是 confd，然后应用通过 confd 来启动。这个方式和 大家用 docker 的习惯不一样，比如 zookeeper 的镜像，习惯启动的第一个进程就是 zookeeper 服务。

那我们为什么不用 docker 默认的方式呢？

这也是一个理想和现实妥协的方案。理想中的 docker 应用配置，应该是静态配置通过环境变量，动态的通过配置中心。比如 jvm 的启动内存设置就是静态配置，通过环境变量传递，如果应用需要变更内存设置，直接销毁旧的容器实例，重新启动新的并传递新的环境变量即可。但现实的状况，我们前面也举了好几个例子，大多数应用的配置还都是通过配置文件，无论动态还是静态。我们为了变更应用的配置文件，就需要通过 confd，所以我们的 docker 镜像默认先启动 confd。

以上就是我们当前的实践方案。下面我们和业界的其他一些方案做一些比较。

Ansible/Puppet/Salt/Chef 这一系列配置变更以及自动化工具，本质上都是纯静态的配置变更工具。它们是把变量通过模板渲染成配置文件，这里的静态指的是这些变量在编写配置规则时就是确定的，所以它们的复用机制不够通用。比如有人写了一个自动部署 zookeeper 集群的 ansible 模块，但当你想用这个模块部署自己的服务的时候，会发现需要有许多变量需要修改，比如网络，等等。它们的静态模式导致的另外一个问题就是服务的依赖变更不好解决，比如前面 HAProxy 那个例子，当后端服务伸缩的时候，要变更 HAProxy 配置，还是得手动修改变量，然后重新执行配置变更脚本。所以它们只能是半人工半自动化工具，对动态的故障迁移以及伸缩，容灾也没有好的办法。

Kubernetes 的目标是通用的容器编排系统，做了很多通用的抽象，试图通过 DNS，虚拟 IP 这样的通用机制来解决服务间的依赖问题。比如前面那个 mysql 的例子，mysql 从库伸缩后应用如何感知？它的解决方案是 mysql slave 可以作为一个独立的服务，会分配一个 DNS name，以及一个 虚拟 IP。应用连接的时候通过 DNS 以及虚拟 IP 进行，并不需要知道后面的每个从库节点 IP。但这种方式的问题就是有些场景满足不了，比如前面的 zookeeper，集群中的每个节点都需要能和其他节点直接通信，类似的还有 elasticsearch。Kubernetes 的 elasticsearch 解决方案是给 elasticsearch 写一个插件，通过 kubernetes 提供的注册中心的接口来发现集群中的其他节点。但如果应用不支持插件就比较麻烦，比如 redis cluster，文末有个 redis cluster 运行在 k8s 上的案例，做法是把每个节点都作为一个 service，如果要扩展节点的话，必须新增 k8s 的 service 配置文件，然后节点运行之后再通过手动调用命令进行初始化。它支持全局的配置文件映射，但只是纯静态配置，不支持变更。

Mesos 的目标是通用的资源调度和分配系统，如果把应用要放到 Mesos 之上，应用需要通过扩展 framework 来实现，开发成本比较高。如果用通用的容器方式，也有和k8s类似的问题。

所以当前看来，我们的方案是相对可行度比较高，容易实践，对各种不同的集群应用的包容性也比较高的方案。

最后再介绍一下我们的新应用中心。主要基于前面的应用调度系统，给企业提供应用标准化开发平台，可以快速将应用云化，实现应用的秒级部署和弹性伸缩。同时提供计费服务以及客服平台，让企业应用快速实现商业化。当前还在邀请内测阶段。

那这个对我们开发者有什么意义呢？一方面我觉得可能会带来基础研发运维部门在企业中的角色转换。因为当前基础研发运维部门在企业中属于业务支撑的部门，基本上是成本部门，并不是直接生产利润的部门。但如果有了这样的平台，基础研发运维部门可以通过企业应用市场将自己的基础组件共享出来，进行售卖。比如每个大一点的互联网公司都会搞一套 mysql 的分布式的集群方案，进行自动的分库分表，如果能在应用市场中找到这样的工具，中小企业肯定也是愿意买单的。所以也可以说服务器端研发人员的春天到了。以前我们很羡慕搞客户端开发的人，自己做个 app 就可以放到应用市场去售卖，现在服务器端开发也可以了。我这里不是说我们一家就能把这个春天带来，而是说服务器端的应用标准化，已经是大势所趋，大家都在做这方面的尝试。可以做个预测，2017年，各容器编排集群，各云厂商，都会推出自己的类似的解决方案，可以期待。

我的分享就这里。

相关链接

1. Etcd 架构与实现解析本人的一篇关于 etcd 的文章，想深入了解 etcd 的可以看看。
2. Kubernetes 架构浅析本人的一篇关于 k8s 的文章，想深入了解 k8s 的可以看看。
3. Mesos 架构以及源码浅析本人的一篇关于 mesos 的文章，想深入了解 mesos 的可以看看。
4. kubernetes cloud plugin for elasticsearch文中提到的通过k8s api 进行节点发现的 elasticsearch 插件
5. kubernetes 上运行 redis cluster 的例子
6. confd我们修改版的confd仓库地址。
7. metad仓库地址。

本文基于我在2月27日Gopher北京聚会演讲整理而成，进行了一些补充以及调整。投稿给《高可用架构》公众号首发。

聊这个话题之前，先梳理下两个概念，几乎所有讲并发的文章都要先讲这两个概念：

• 并发（concurrency）并发的关注点在于任务切分。举例来说，你是一个创业公司的CEO，开始只有你一个人，你一人分饰多角，一会做产品规划，一会写代码，一会见客户，虽然你不能见客户的同时写代码，但由于你切分了任务，分配了时间片，表现出来好像是多个任务一起在执行。
• 并行（parallelism）并行的关注点在于同时执行。还是上面的例子，你发现你自己太忙了，时间分配不过来，于是请了工程师，产品经理，市场总监，各司一职，这时候多个任务可以同时执行了。

所以总结下，并发并不要求必须并行，可以用时间片切分的方式模拟，比如单核cpu上的多任务系统，并发的要求是任务能切分成独立执行的片段。而并行关注的是同时执行，必须是多（核）cpu，要能并行的程序必须是支持并发的。本文大多数情况下不会严格区分这两个概念，默认并发就是指并行机制下的并发。

为什么并发程序这么难?

We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction. —— Akka

Akka官方文档开篇这句话说的好，之所以写正确的并发，容错，可扩展的程序如此之难，是因为我们用了错误的工具和错误的抽象。（当然该文档本来的意思是Akka是正确的工具，但我们可以独立的看待这句话）。

那我们从最开始梳理下程序的抽象。开始我们的程序是面向过程的，数据结构+func。后来有了面向对象，对象组合了数结构和func，我们想用模拟现实世界的方式，抽象出对象，有状态和行为。但无论是面向过程的func还是面向对象的func，本质上都是代码块的组织单元，本身并没有包含代码块的并发策略的定义。于是为了解决并发的需求，引入了Thread（线程）的概念。

线程（Thread）

1. 系统内核态，更轻量的进程
2. 由系统内核进行调度
3. 同一进程的多个线程可共享资源

线程的出现解决了两个问题，一个是GUI出现后急切需要并发机制来保证用户界面的响应。第二是互联网发展后带来的多用户问题。最早的CGI程序很简单，将通过脚本将原来单机版的程序包装在一个进程里，来一个用户就启动一个进程。但明显这样承载不了多少用户，并且如果进程间需要共享资源还得通过进程间的通信机制，线程的出现缓解了这个问题。

线程的使用比较简单，如果你觉得这块代码需要并发，就把它放在单独的线程里执行，由系统负责调度，具体什么时候使用线程，要用多少个线程，由调用方决定，但定义方并不清楚调用方会如何使用自己的代码，很多并发问题都是因为误用导致的，比如Go中的map以及Java的HashMap都不是并发安全的，误用在多线程环境就会导致问题。另外也带来复杂度：

1. 竞态条件（race conditions）如果每个任务都是独立的，不需要共享任何资源，那线程也就非常简单。但世界往往是复杂的，总有一些资源需要共享，比如前面的例子，开发人员和市场人员同时需要和CEO商量一个方案，这时候CEO就成了竞态条件。
2. 依赖关系以及执行顺序如果线程之间的任务有依赖关系，需要等待以及通知机制来进行协调。比如前面的例子，如果产品和CEO讨论的方案依赖于市场和CEO讨论的方案，这时候就需要协调机制保证顺序。

为了解决上述问题，我们引入了许多复杂机制来保证：

• Mutex(Lock) （Go里的sync包, Java的concurrent包）通过互斥量来保护数据，但有了锁，明显就降低了并发度。
• semaphore 通过信号量来控制并发度或者作为线程间信号（signal）通知。
• volatile Java专门引入了volatile关键词来，来降低只读情况下的锁的使用。
• compare-and-swap 通过硬件提供的CAS机制保证原子性（atomic），也是降低锁的成本的机制。

如果说上面两个问题只是增加了复杂度，我们通过深入学习，严谨的CodeReview，全面的并发测试（比如Go语言中单元测试的时候加上-race参数），一定程度上能解决（当然这个也是有争议的，有论文认为当前的大多数并发程序没出问题只是并发度不够，如果CPU核数继续增加，程序运行的时间更长，很难保证不出问题）。但最让人头痛的还是下面这个问题：

系统里到底需要多少线程？

这个问题我们先从硬件资源入手，考虑下线程的成本：

• 内存（线程的栈空间）
  每个线程都需要一个栈（Stack）空间来保存挂起（suspending）时的状态。Java的栈空间（64位VM）默认是1024k，不算别的内存，只是栈空间，启动1024个线程就要1G内存。虽然可以用-Xss参数控制，但由于线程是本质上也是进程，系统假定是要长期运行的，栈空间太小会导致稍复杂的递归调用（比如复杂点的正则表达式匹配）导致栈溢出。所以调整参数治标不治本。

• 调度成本（context-switch）
  我在个人电脑上做的一个非严格测试，模拟两个线程互相唤醒轮流挂起，线程切换成本大约6000纳秒/次。这个还没考虑栈空间大小的影响。国外一篇论文专门分析线程切换的成本，基本上得出的结论是切换成本和栈空间使用大小直接相关。

• CPU使用率
  我们搞并发最主要的一个目标就是我们有了多核，想提高CPU利用率，最大限度的压榨硬件资源，从这个角度考虑，我们应该用多少线程呢？
  

  这个我们可以通过一个公式计算出来，100/(15+5)*4=20，用20个线程最合适。但一方面网络的时间不是固定的，另外一方面，如果考虑到其他瓶颈资源呢？比如锁，比如数据库连接池，就会更复杂。

作为一个1岁多孩子的父亲，认为这个问题的难度好比你要写个给孩子喂饭的程序，需要考虑『给孩子喂多少饭合适？』，这个问题有以下回答以及策略：

• 孩子不吃了就好了（但孩子贪玩，不吃了可能是想去玩了）
• 孩子吃饱了就好了（废话，你怎么知道孩子吃饱了？孩子又不会说话）
• 逐渐增量，长期观察，然后计算一个平均值（这可能是我们调整线程常用的策略，但增量增加到多少合适呢？）
• 孩子吃吐了就别喂了（如果用逐渐增量的模式，通过外部观察，可能会到达这个边界条件。系统性能如果因为线程的增加倒退了，就别增加线程了）
• 没控制好边界，把孩子给给撑坏了 （这熊爸爸也太恐怖了。但调整线程的时候往往不小心可能就把系统搞挂了）

通过这个例子我们可以看出，从外部系统来观察，或者以经验的方式进行计算，都是非常困难的。于是结论是：

让孩子会说话，吃饱了自己说，自己学会吃饭，自管理是最佳方案。

然并卵，计算机不会自己说话，如何自管理？

但我们从以上的讨论可以得出一个结论：

• 线程的成本较高（内存，调度）不可能大规模创建
• 应该由语言或者框架动态解决这个问题

线程池方案

Java1.5后，Doug Lea的Executor系列被包含在默认的JDK内，是典型的线程池方案。

线程池一定程度上控制了线程的数量，实现了线程复用，降低了线程的使用成本。但还是没有解决数量的问题，线程池初始化的时候还是要设置一个最小和最大线程数，以及任务队列的长度，自管理只是在设定范围内的动态调整。另外不同的任务可能有不同的并发需求，为了避免互相影响可能需要多个线程池，最后导致的结果就是Java的系统里充斥了大量的线程池。

新的思路

从前面的分析我们可以看出，如果线程是一直处于运行状态，我们只需设置和CPU核数相等的线程数即可，这样就可以最大化的利用CPU，并且降低切换成本以及内存使用。但如何做到这一点呢？

陈力就列，不能者止

这句话是说，能干活的代码片段就放在线程里，如果干不了活（需要等待，被阻塞等），就摘下来。通俗的说就是不要占着茅坑不拉屎，如果拉不出来，需要酝酿下，先把茅坑让出来，因为茅坑是稀缺资源。

要做到这点一般有两种方案：

1. 异步回调方案典型如NodeJS，遇到阻塞的情况，比如网络调用，则注册一个回调方法（其实还包括了一些上下文数据对象）给IO调度器（linux下是libev，调度器在另外的线程里），当前线程就被释放了，去干别的事情了。等数据准备好，调度器会将结果传递给回调方法然后执行，执行其实不在原来发起请求的线程里了，但对用户来说无感知。但这种方式的问题就是很容易遇到callback hell，因为所有的阻塞操作都必须异步，否则系统就卡死了。还有就是异步的方式有点违反人类思维习惯，人类还是习惯同步的方式。

2. GreenThread/Coroutine/Fiber方案这种方案其实和上面的方案本质上区别不大，关键在于回调上下文的保存以及执行机制。为了解决回调方法带来的难题，这种方案的思路是写代码的时候还是按顺序写，但遇到IO等阻塞调用时，将当前的代码片段暂停，保存上下文，让出当前线程。等IO事件回来，然后再找个线程让当前代码片段恢复上下文继续执行，写代码的时候感觉好像是同步的，仿佛在同一个线程完成的，但实际上系统可能切换了线程，但对程序无感。

GreenThread

• 用户空间 首先是在用户空间，避免内核态和用户态的切换导致的成本。
• 由语言或者框架层调度
• 更小的栈空间允许创建大量实例（百万级别）

几个概念

• Continuation 这个概念不熟悉FP编程的人可能不太熟悉，不过这里可以简单的顾名思义，可以理解为让我们的程序可以暂停，然后下次调用继续（contine）从上次暂停的地方开始的一种机制。相当于程序调用多了一种入口。
• Coroutine 是Continuation的一种实现，一般表现为语言层面的组件或者类库。主要提供yield，resume机制。
• Fiber 和Coroutine其实是一体两面的，主要是从系统层面描述，可以理解成Coroutine运行之后的东西就是Fiber。

Goroutine

Goroutine其实就是前面GreenThread系列解决方案的一种演进和实现。

• 首先，它内置了Coroutine机制。因为要用户态的调度，必须有可以让代码片段可以暂停/继续的机制。
• 其次，它内置了一个调度器，实现了Coroutine的多线程并行调度，同时通过对网络等库的封装，对用户屏蔽了调度细节。
• 最后，提供了Channel机制，用于Goroutine之间通信，实现CSP并发模型（Communicating Sequential Processes）。因为Go的Channel是通过语法关键词提供的，对用户屏蔽了许多细节。其实Go的Channel和Java中的SynchronousQueue是一样的机制，如果有buffer其实就是ArrayBlockQueue。

Goroutine调度器

这个图一般讲Goroutine调度器的地方都会引用，想要仔细了解的可以看看原博客。这里只说明几点：

1. M代表系统线程，P代表处理器（核），G代表Goroutine。Go实现了M:N的调度，也就是说线程和Goroutine之间是多对多的关系。这点在许多GreenThread/Coroutine的调度器并没有实现。比如Java1.1版本之前的线程其实是GreenThread（这个词就来源于Java），但由于没实现多对多的调度，也就是没有真正实现并行，发挥不了多核的优势，所以后来改成基于系统内核的Thread实现了。
2. 某个系统线程如果被阻塞，排列在该线程上的Goroutine会被迁移。当然还有其他机制，比如M空闲了，如果全局队列没有任务，可能会从其他M偷任务执行，相当于一种rebalance机制。这里不再细说，有需要看专门的分析文章。
3. 具体的实现策略和我们前面分析的机制类似。系统启动时，会启动一个独立的后台线程（不在Goroutine的调度线程池里），启动netpoll的轮询。当有Goroutine发起网络请求时，网络库会将fd（文件描述符）和pollDesc（用于描述netpoll的结构体，包含因为读/写这个fd而阻塞的Goroutine）关联起来，然后调用runtime.gopark方法，挂起当前的Goroutine。当后台的netpoll轮询获取到epoll（linux环境下）的event，会将event中的pollDesc取出来，找到关联的阻塞Goroutine，并进行恢复。

Goroutine是银弹么？

Goroutine很大程度上降低了并发的开发成本，是不是我们所有需要并发的地方直接go func就搞定了呢？

Go通过Goroutine的调度解决了CPU利用率的问题。但遇到其他的瓶颈资源如何处理？比如带锁的共享资源，比如数据库连接等。互联网在线应用场景下，如果每个请求都扔到一个Goroutine里，当资源出现瓶颈的时候，会导致大量的Goroutine阻塞，最后用户请求超时。这时候就需要用Goroutine池来进行控流，同时问题又来了：池子里设置多少个Goroutine合适？

所以这个问题还是没有从更本上解决。

Actor模型

Actor对没接触过这个概念的人可能不太好理解，Actor的概念其实和OO里的对象类似，是一种抽象。面对对象编程对现实的抽象是对象=属性+行为（method），但当使用方调用对象行为（method）的时候，其实占用的是调用方的CPU时间片，是否并发也是由调用方决定的。这个抽象其实和现实世界是有差异的。现实世界更像Actor的抽象，互相都是通过异步消息通信的。比如你对一个美女say hi，美女是否回应，如何回应是由美女自己决定的，运行在美女自己的大脑里，并不会占用发送者的大脑。

所以Actor有以下特征：

• Processing – actor可以做计算的，不需要占用调用方的CPU时间片，并发策略也是由自己决定。
• Storage – actor可以保存状态
• Communication – actor之间可以通过发送消息通讯

Actor遵循以下规则：

• 发送消息给其他的Actor
• 创建其他的Actor
• 接受并处理消息，修改自己的状态

Actor的目标：

• Actor可独立更新，实现热升级。因为Actor互相之间没有直接的耦合，是相对独立的实体，可能实现热升级。
• 无缝弥合本地和远程调用 因为Actor使用基于消息的通讯机制，无论是和本地的Actor，还是远程Actor交互，都是通过消息，这样就弥合了本地和远程的差异。
• 容错 Actor之间的通信是异步的，发送方只管发送，不关心超时以及错误，这些都由框架层和独立的错误处理机制接管。
• 易扩展，天然分布式 因为Actor的通信机制弥合了本地和远程调用，本地Actor处理不过来的时候，可以在远程节点上启动Actor然后转发消息过去。

Actor的实现：

• Erlang/OTP Actor模型的标杆，其他的实现基本上都一定程度参照了Erlang的模式。实现了热升级以及分布式。
• Akka（Scala,Java）基于线程和异步回调模式实现。由于Java中没有Fiber，所以是基于线程的。为了避免线程被阻塞，Akka中所有的阻塞操作都需要异步化。要么是Akka提供的异步框架，要么通过Future-callback机制，转换成回调模式。实现了分布式，但还不支持热升级。
• Quasar (Java) 为了解决Akka的阻塞回调问题，Quasar通过字节码增强的方式，在Java中实现了Coroutine/Fiber。同时通过ClassLoader的机制实现了热升级。缺点是系统启动的时候要通过javaagent机制进行字节码增强。

Golang CSP VS Actor

二者的格言都是：

Don’t communicate by sharing memory, share memory by communicating

通过消息通信的机制来避免竞态条件，但具体的抽象和实现上有些差异。

• CSP模型里消息和Channel是主体，处理器是匿名的。
  也就是说发送方需要关心自己的消息类型以及应该写到哪个Channel，但不需要关心谁消费了它，以及有多少个消费者。Channel一般都是类型绑定的，一个Channel只写同一种类型的消息，所以CSP需要支持alt/select机制，同时监听多个Channel。Channel是同步的模式（Golang的Channel支持buffer，支持一定数量的异步），背后的逻辑是发送方非常关心消息是否被处理，CSP要保证每个消息都被正常处理了，没被处理就阻塞着。
• Actor模型里Actor是主体，Mailbox（类似于CSP的Channel）是透明的。
  也就是说它假定发送方会关心消息发给谁消费了，但不关心消息类型以及通道。所以Mailbox是异步模式，发送者不能假定发送的消息一定被收到和处理。Actor模型必须支持强大的模式匹配机制，因为无论什么类型的消息都会通过同一个通道发送过来，需要通过模式匹配机制做分发。它背后的逻辑是现实世界本来就是异步的，不确定（non-deterministic）的，所以程序也要适应面对不确定的机制编程。自从有了并行之后，原来的确定编程思维模式已经受到了挑战，而Actor直接在模式中蕴含了这点。

从这样看来，CSP的模式比较适合Boss-Worker模式的任务分发机制，它的侵入性没那么强，可以在现有的系统中通过CSP解决某个具体的问题。它并不试图解决通信的超时容错问题，这个还是需要发起方进行处理。同时由于Channel是显式的，虽然可以通过netchan（原来Go提供的netchan机制由于过于复杂，被废弃，在讨论新的netchan）实现远程Channel，但很难做到对使用方透明。而Actor则是一种全新的抽象，使用Actor要面临整个应用架构机制和思维方式的变更。它试图要解决的问题要更广一些，比如容错，比如分布式。但Actor的问题在于以当前的调度效率，哪怕是用Goroutine这样的机制，也很难达到直接方法调用的效率。当前要像OO的『一切皆对象』一样实现一个『一切皆Actor』的语言，效率上肯定有问题。所以折中的方式是在OO的基础上，将系统的某个层面的组件抽象为Actor。

再扯一下Rust

Rust解决并发问题的思路是首先承认现实世界的资源总是有限的，想彻底避免资源共享是很难的，不试图完全避免资源共享，它认为并发的问题不在于资源共享，而在于错误的使用资源共享。比如我们前面提到的，大多数语言定义类型的时候，并不能限制调用方如何使用，只能通过文档或者标记的方式（比如Java中的@ThreadSafe ,@NotThreadSafe annotation）说明是否并发安全，但也只能仅仅做到提示的作用，不能阻止调用方误用。虽然Go提供了-race机制，可以通过运行单元测试的时候带上这个参数来检测竞态条件，但如果你的单元测试并发度不够，覆盖面不到也检测不出来。所以Rust的解决方案就是：

• 定义类型的时候要明确指定该类型是否是并发安全的
• 引入了变量的所有权（Ownership）概念 非并发安全的数据结构在多个线程间转移，也不一定就会导致问题，导致问题的是多个线程同时操作，也就是说是因为这个变量的所有权不明确导致的。有了所有权的概念后，变量只能由拥有所有权的作用域代码操作，而变量传递会导致所有权变更，从语言层面限制了竞态条件出现的情况。

有了这机制，Rust可以在编译期而不是运行期对竞态条件做检查和限制。虽然开发的时候增加了心智成本，但降低了调用方以及排查并发问题的心智成本，也是一种有特色的解决方案。

结论

革命尚未成功 同志任需努力

本文带大家一起回顾了并发的问题，和各种解决方案。虽然各家有各家的优势以及使用场景，但并发带来的问题还远远没到解决的程度。所以还需努力，大家也有机会啊。

最后抛个砖 构想:在Goroutine上实现Actor？

• 分布式 解决了单机效率问题，是不是可以尝试解决下分布式效率问题？
• 和容器集群融合 当前的自动伸缩方案基本上都是通过监控服务器或者LoadBalancer，设置一个阀值来实现的。类似于我前面提到的喂饭的例子，是基于经验的方案，但如果系统内和外部集群结合，这个事情就可以做的更细致和智能。
• 自管理 前面的两点最终的目标都是实现一个可以自管理的系统。做过系统运维的同学都知道，我们照顾系统就像照顾孩子一样，时刻要监控系统的各种状态，接受系统的各种报警，然后排查问题，进行紧急处理。孩子有长大的一天，那能不能让系统也自己成长，做到自管理呢？虽然这个目标现在看来还比较远，但我觉得是可以期待的。

引用以及扩展阅读

1. 本文的演讲视频
2. 本文的演讲pdf
3. CSP model paper
4. Actor model paper
5. Quantifying The Cost of Context Switch
6. JCSP 在Java中实现CSP模型的库
7. Overview of Modern Concurrency and Parallelism Concepts
8. Golang netchan 的讨论
9. quasar vs akka
10. golang 官方博客的 concurrency is not parallelism
11. go scheduler, 文中的调度器图片来源
12. handling-1-million-requests-per-minute-with-golang 一个用Goroutine的控流实践

FAQ：

高可用架构公众号网友『闯』：有个问题 想请教一下 你说1024个线程需要1G的空间作为栈空间 到时线程和进程的地址空间都是虚拟空间 当你没有真正用到这块虚地址时 是不会把物理内存页映射到虚拟内存上的 也就是说每个线程如果调用没那么深 是不会将所有栈空间关键到内存上 也就是说1024个线程实际不会消耗那么多内存

答： 你说的是对的，java的堆以及stack的内存都是虚拟内存，实际上启动一个线程不会立刻占用那么多内存。但线程是长期运行的，stack增长后，空间并不会被回收，也就是说会逐渐增加到xss的限制。这里只是说明线程的成本。另外即便是空线程（启动后就sleep），据我的测试，1核1G的服务器，启动3万多个线程左右系统就挂掉了(需要先修改系统线程最大数限制，在/proc/sys/kernel/threads-max中)，和理想中的百万级别还是有很大差距的。

2016年底，已经担任CTO两年多时间的李纯走上飞机，踏上了前往美国硅谷的旅途。他参加的是由极客邦科技举办的中国技术开放日活动，此次活动聚集了国内互联网顶尖的技术人和创业者，他们会拜访硅谷企业，学习和交流经验。

对于李纯来说，此次行程属于重游故地。之前他在eBay/Paypal工作十二年，对这片土地已经熟悉得不能再熟悉，之后他回国，带领阿里人进入B+时代。李纯的每一步的发展看起来都会根据外部环境、机缘巧合的不同而有所不同，但是在技术能力成长的方面，他却一直有一条很清晰的路线。成长是漫长的，充满了点滴细节，没有一蹴而就，但是智慧和经验却可以复用。

我从毕业后就从事计算机软件工作到今天，技术在不断更新，新的商业机会不断出现。我们这一代可以说非常幸运地赶上了这个行业的黄金时代。

我是2002年底在互联网泡沫破裂、发展最低谷时加入的eBay。之前工作主要集中在B2B软件、电信系统和互联网技术领域，在大型公司、硅谷的startup、自己的创业公司都工作过。自我感觉无论在技术、产品、业务还是管理上都有不错的积累，但是面向C类的电商业务还是第一次接触。

我在eBay十二年的工作经历，做了4份跨度蛮大的工作。

头三年在搜索团队，加入eBay就与三个Research Lab的搜素专家、两个测试工程师，在没有业务方，没有产品经理的情况下，用了半年多的时间，开发并上线了eBay的第一代搜索引擎。这个引擎在没有做任何大的架构与技术改造情况下，支撑了eBay后来十几年的业务复杂度及体量的增长，从投入和产出比来讲我想应该是eBay最成功的项目了。

在搜素团队做了一段管理后，被调到技术平台部负责eBay的电商后台技术框架团队，干了三年，主要贡献和积累还是在架构和技术管理层面。2008年自己感到需要些变化，差点离开。

当时eBay要在上海扩大中国研发中心的规模，希望我去负责。就这样在eBay上海研发中心工作了三年，对国际企业海外研发中心的建设与发展积累了各种酸甜苦辣的经验和教训。

最后三年我又回到美国，负责Paypal的支付风控技术团队。主要工作是把通过十几年业务与技术积累，对Paypal做出巨大贡献的传统实时风控系统迁移到新一代的基于大数据的技术体系上。

无论是从工作的成就感还是在过程中学到的东西，我非常珍惜和感谢在eBay/Paypal的十二年。不过也很高兴，看到B类业务的重新兴起，有机会回到自己最感兴趣的B类互联网业务中。

与很多在海外工作的华人一样，我一直有强烈的回国愿望，其间也回来过两次，因为家庭原因又回到美国。现在孩子已经长大，自己可以轻松上阵，所以就全身心回到国内发展了。概括的来讲，尤其是在大型公司，在美国更像是守成，在中国更多仍是创业。渴望挑战和探索未知的人都会被中国互联网发展的速度和前景所吸引。

其实中国与美国创业型公司的地域性差异已经变的越来越小，更多要看公司个体的业务模式、创始人背景及推崇的文化。

目前看，在美国特别是硅谷，技术型的创业公司会比国内多一些。这主要是硅谷有着几十年引领全世界高科技发展的历史，是全球顶尖技术人才最大的汇集地，技术的氛围和人才都比较充分有关。而中国有大量的技术转化为商业的机会，商业上成功的道路相对比较清晰，投入与产出比对投资人来说也更加合理。对有一定规模的公司，两地的差别会相对大一些。

美国的中、大型公司，即使是互联网与高科技领域的新型公司，管理体制与流程都比较成熟，每个人的工作职责和范围也是相对明确和固定的，更加强调每个人发挥自己的专业能力完成本职工作，基本上是一个萝卜一个坑。

在中国，随着互联网在C类电商及个人生活中的普遍应用，产生了一批以BAT为代表的迅速成功的互联网公司，也培养出大量的人才。这些公司可以发展的空间和机会仍然巨大，对有专业深度和广度的专家及leader的需求是非常强烈的。每个人工作的职责及可发挥的空间会更加开放，但同时你的独立思考，推动变化及拿到结果的能力和愿望会变的更为重要。

以ERP、CRM和SCM为主的企业软件有着比互联网技术公司更长的历史，对企业用户有着很强的影响力。但是随着以互联网为核心的公司的发展，这些传统软件公司的转型相对较慢，无论从人才及满足客户互联网化需求方面都遇到了很大挑战。

以互联网模式a成长出来的技术公司在服务B类用户时，也需要做适当的调整和改变，特别是如何满足企业级用户在流程的严密性、数据的结构性、需求的专业性等方面的要求。在我看来，目前机会很大，就是看谁能够选择传统软件和互联网技术的优势，充分利用大数据，云计算等新技术为B类用户创造新的价值，提升效率。

1688做为国内最大的B类贸易平台，确实承担了很多差异非常大的业务流程。比如说服务线下零售小店主的零售通业务，我们打造了一套链接快销品供应商，仓储与配送物流提供商，线下小店之间的供应链体系，能够帮助线下小店以最合理的价钱，最快的时间，最有效的工具采购到最适合自己客户的商品。

另外一个极端，在钢铁行业，我们把1688电商产品及供应链能力以SaaS和开发框架的模式输出给由五矿和阿里巴巴合资的第三方公司五阿哥，由他们利用自己在钢铁行业的专业能力与资源，开发了独立的钢铁电商网站。

这两块业务在上层看有着具大差别，而且一个是阿里内部业务，另一个是第三方独立公司，但是所用的底层电商与供应链技术是完全相同的，所有的数据也是完全相通的。所面临的最大挑战是配合业务的节奏，用最合理的产品与技术架构，更快地积累和完善核心供应链能力，同时在不同的行业打造适合不同用户需求的前端产品。

在大量机会和需求下做好取舍，集中经历在重点领域打深打透。即支撑业务当前需要，也要有产品和技术的良性积累。

记得2000年左右，Gartner Group预言B2B ecommerce会从1999年的1450亿美金在2004年达到72900亿美金。在全球特别是美国出现了大量的B2B创业公司。大家当然知道后来的结果，在过去15年， C类电商蓬勃发展的时期，大量的B类电商公司都销声匿迹。

随着互联网发展到新的阶段，无论从传统企业对互联网及大数据的需求，还是在云计算，互联网底层技术的成熟度来看，目前 B类业务进入互联网化的时机已经相当成熟。做为在B2B领域的从业者，很高兴看到投资人对这个领域的认可。

当然，最后还是要看我们服务B类用户的产品与技术公司是否能够把握时机，为各行各业的企业用户带来真正的价值。另一方面，由于B类业务的复杂性和多样性，这个行业的成功更要依赖不同公司共同的推动与协同，以生态的力量和标准化的模式来完成而不是排他性的竞争。

阿里巴巴 B2B 1.0 是为用户提供的商机与信息匹配，2.0做的是B2B电商与营销， 3.0就是通过供应链服务的方式帮助中小企业实现互联网化的转型。具体做的就是在不同行业中为中小企业提供出一个灵活，方便和低成本的智能互联网供应链平台。与eBay的工作相比，C类电商主要解决的是在大体量用户下的高效与稳定。B类主要挑战是解决业务的复杂性，多样性及多系统的集成。

最初我们通过全球化互联网技术解决信息互通；机器翻译解决语音互通；CRM、流量与联盟技术解决平台买卖家用户积累；商品搜素与推荐解决客户匹配；RFQ与询盘满足商务沟通等手段提升了全球中小企业商机的建立和交流的效率。

后来阿里巴巴B2B平台完成了信息向交易的转化，建立在阿里集团互联网、大数据及电商中台的基础上在现货批发、电商卖家采购、跨境一般贸易等B类交易领域支撑了每年几千亿内贸，上百亿美元跨境B类贸易的平台。

从今年开始，我们开始全面进入B类电商贸易的深水区，也是我们认为能够为B类用户带来互联网化价值的互联网供应链层面。阿里B2B共分为三个阶段：

• 第一阶段，建立信息网站提供信息和营销服务平台，让买家更加方便的找到所需购买的产品，并和卖家联系；
• 第二阶段，实现线上化、产品化，支撑业务朝交易、采购平台转型，促进在平台完成业务交易；
• 第三阶段，以数据驱动、结合供应链能力及平台化建设，建立智能供应链网络平台、为B2B业务国际化贸易铺路，探索与科技合作伙伴建立合作关系，建立B2B技术生态圈。

技术上我们主要解决三个问题。

1. 符合企业用户特色的基于结构化数据和流程的互联互通；
2. 基于大数据的全球中小企业信息库与智能供应链；
3. 基于行业标准的服务、开发与开放生态体系。

过去十几年互联网技术的应用创造了很多快速成功的业务模式，对技术的挑战主要在用快速迭代的模式支持业务的快速发展来取得市场优势，业务成功后对大流量、高并发线上交易平台（OLTP）的稳定性、可用性及高性能的支撑。

随着互联网平台数据的积累和带来的潜在价值，基于大数据相关技术也得到了迅速的发展。B类互联网业务的发展，肯定会推动新技术的出现和成功利用，可能是IoT，可能是区块链。

从工程和架构来看，可能会更加强调产品的抽象和通用性、大型系统之间的集成、标准的制定推广。作为技术人员，一方面要快速学习和了解当前技术发展的趋势和方向，同时要根据自己所在业务场景判断和选择适合的技术手段和整体架构。

每个人的发展都会根据外部环境，机缘巧合有所不同，很难有一个固定模式。不过我可以从技术能力成长的角度分享一下自己的经历。

在工作早期，我的兴趣主要放在了具体技术能力的积累。毕业后第一个工作在北大方正用C/C++在Windows 1.03操作系统上写企业排版软件。后来到美国后第一个工作做EDI软件，主要是在微软技术体系里用C++和DCOM做企业商用软件。

差不多工作了6年多，才感觉自己真正理解了这些技术背后的本质和内涵。同时这段时间，也在工作中找各种机会实践其他技术，比如Unix、CORBA、OLAP及后来的Java技术都做过。这些经验扩展了自己的技术广度，也为后来互联网时期新技术层出不限，自己可以快速学习，做出正确判断打下了一个很好的基础。

做企业商用产品对软件开发的产品化和商业化要求比较高，但后来证明，这个能力即使在非产品业务的电信及互联网公司也是非常有用的。后来也是技术兴趣的驱动，加入了美国当时发展最快的一家电信公司做OSS／BSS系统的架构师，做了很多大型、复杂系统之间的架构设计、系统集成、新技术的用研和引进等工作。自己有机会从宏观的角度去看一些技术和架构，进一步扩展了自己的技术视野。

在互联网发展的吸引下，90年代末从美国中西部来到硅谷一家比较火的互联网startup做总架构师，然后又与几个伙伴一起拿到风投，回国创业做基于互联网技术的B2B与EAI产品。这段时间，开始更加关注技术与业务的关系，如何根据业务、市场和用户的需求来选择适当的技术、产品与团队。

很高兴的是，我那几年一直坚持，即使做架构师、做管理也不要轻易放弃自己动手写程序的能力，甚至在担任自己创业公司CTO、管理近百人的技术团队时，仍然写了当时B2B集成平台中最核心的代码。

再后来就到了eBay/Paypal，有机会学习和实践用合理的架构与技术，工程师文化及管理模式来支撑互联网模式的业务。 今天来到阿里巴巴B2B技术部，我们所面临的业务模式和技术挑战与传统的互联网电商又有着新的不同，而且深深感觉到在B2B业务的下一阶段，技术的作用是至关重要的。

不敢说我们已经完全想清楚了，但是我们团队在不断的探索和尝试如何发力来支持我们的业务。 我感到最幸运的是，在这个领域工作近30年，一直有机会学习新的技术和能力，同时也有新的业务模式出现，可以利用自己过去的经验和知识做一些有意义的事情。

技术和商业仍在日新月异的进步，在互联网领域，更好的时代正在到来。因此对这个领域，对新踏入这个领域的年轻人，我仍然充满信心。

在技术人员成长方面，我感受比较深刻的有三点。

1. 对新技术发自内心的喜爱和好奇，对自己产品和代码的尊重与自豪，是技术人员从优秀走向杰出的关键因素；
2. 从用户需求出发找到最适合的技术（即使是非时髦技术）解决问题，比从最时髦技术出发找问题来解决对技术人员的成长帮助更大；
3. 帮助他人成功，是自己成功的最佳路径。

想象得到，谈起计算机软件和互联网的工作经历，阿里巴巴B2B事业群CTO李纯先生就不经意地流露出他的感恩和幸福感，他说他很幸运，他们这一代赶上了这个行业的黄金时代。

不可否认的是，前十年甚至前二十年，互联网的黄金时代造就了无数互联网时代的弄潮儿，他们在互联网技术领域里指点江山，挥斥方遒。如果，上个世纪初是风云际会、时势造英雄，让多少具有侠义情怀的中国人会怀揣仗剑天涯的梦想。那么，在这个世纪，全世界是一个地球村的当下，他们的梦想已然被拓展，更是在逐步完成着。

作者：李纯

编辑：Cindy

文章出处：InfoQ（订阅号ID：infoqchina）

从电子邮件到论坛，从论坛到微博，再从微博到现在的视频直播。当人们在网上发言的速度越来越接近口语的时候，也就给网络喷子带来了越来越多的便利。虽然从人类学会说到现在，还没有什么办法能阻止人类之间互相对骂。但网络空间不比线下，一个人用嘴骂人只能被少数人听到，而在网上却可能影响几千人几万人。在最新一季的南方公园中，甚至认为网络喷子是川普当选和第三次世界大战以及人类登上火星的主要原因。

如何阻止网络喷子成为了各大互联网公司的一个共同的课题，而美国游戏直播平台 Twitch 则为其它同行们提供了一个新鲜的思路。Twitch 今天上线了一个全新的工具 AutoMod，帮助主播们打击活跃在自己聊天室内的喷子。

AutoMod 并不是事后审查，而是将那些疑似有攻击性和歧视性的弹幕直接移入待审核列表由人来决定这些内容是否可以被放出来。根据选项，它可以过滤四类内容，分别是人身攻击、性语言、侵略词语和亵渎词语。

所有的专业喷子都会对任何使用机器过滤他们语言的行为感到不屑，因为他们总是能在第一时间找到突破屏蔽的方法。但是 Twitch 声称其工具远远不是一般的「关键词过滤列表」工作模式，而是采用了深度学习和自然语言识别系统。也就是说 AutoMod 是以整句和语意的方式在识别每一条弹幕中的「恶意」程度。Twitch 的发言人说：「除了不当的词语和短语之外，特定的表情符号的搭配和替换某些词语用的另外一些词语也会在第一时间被机器学会并过滤出来。」

根据 Twitch 的介绍，为了能够让这个拦截系统能够成功的跟上喷子的脚步，Twitch 使用了亚马逊 AWS 的机器学习平台作为后盾。亚马逊在去年到今年卖的火热的人工智能音箱 Echo 里集成的智能助手 Alexa 就是使用这一深度学习平台调教出来的。这让人看到了一丝将喷子从 Twitch 平台彻底驱逐的希望。

AutoMod 目前提供英文版，同时也在测试阿拉伯语，捷克语，法语，德语，意大利语，日语，韩语，波兰语，葡萄牙语，俄语，西班牙语和土耳其语等 12 个语言的测试版本。Twitch 主播可以在设置面板里将其打开。

不过如你所见，博大精深的汉语并不在其中。

在Python中如果要连接数据库，不管是 MySQL、 SQL Server、 PostgreSQL亦或是SQLite，使用时都是采用游标的方式，所以就不得不学习Python DB-API。

Python所有的数据库接口程序都在一定程度上遵守 Python DB-API 规范。DB-API定义了一系列必须的对象和数据库存取方式，以便为各种底层数据库系统和多种多样的数据库接口程序提供一致的访问接口。由于DB-API 为不同的数据库提供了一致的访问接口， 在不同的数据库之间移植代码成为一件轻松的事情。

Python连接数据库流程：

使用connect创建connection连接

connect 方法生成一个 connect 对象, 我们通过这个对象来访问数据库。符合标准的模块都会实现 connect 方法。connect 函数的参数如下所示：

• user Username
• password Password
• host Hostname
• database Database name
• dsn Data source name

数据库连接参数可以以一个 DSN 字符串的形式提供，示例：connect(dsn=’host:MYDB’,user=’root’,password=’ ’)

当然，不同的数据库接口程序可能有些差异，并非都是严格按照规范实现，例如MySQLdb则使用 db 参数而不是规范推荐的 database 参数来表示要访问的数据库：

MySQLdb连接时可用参数

• host: 数据库主机名.默认是用本地主机
• user: 数据库登陆名.默认是当前用户
• passwd: 数据库登陆的秘密.默认为空
• db: 要使用的数据库名.没有默认值
• port: MySQL服务使用的TCP端口.默认是3306
• charset: 数据库编码

psycopg2连接时可用参数：

• dbname – 数据库名称 (dsn连接模式)
• database – 数据库名称
• user – 用户名
• password – 密码
• host – 服务器地址 (如果不提供默认连接Unix Socket)
• port – 连接端口 (默认5432)

其中connect对象又有如下方法:

• close():关闭此connect对象, 关闭后无法再进行操作，除非再次创建连接
• commit():提交当前事务，如果是支持事务的数据库执行增删改后没有commit则数据库默认回滚
• rollback():取消当前事务
• cursor():创建游标对象

使用cursor创建游标对象

cursor游标对象又有如下属性和方法:

常用方法:

• close():关闭此游标对象
• fetchone():得到结果集的下一行
• fetchmany([size = cursor.arraysize]):得到结果集的下几行
• fetchall():得到结果集中剩下的所有行
• excute(sql[, args]):执行一个数据库查询或命令
• excutemany(sql, args):执行多个数据库查询或命令

常用属性:

• connection:创建此游标对象的数据库连接
• arraysize:使用fetchmany()方法一次取出多少条记录，默认为1
• lastrowid:相当于PHP的last_inset_id()

其他方法：

• __iter__()：创建一个可迭代对象（可选）
• next()：获取结果集的下一行（如果支持迭代的话）
• nextset()：移到下一个结果集（如果支持的话）
• callproc(func[,args])：调用一个存储过程
• setinputsizes(sizes)：设置输入最大值（必须有，但具体实现是可选的）
• setoutputsizes(sizes[,col])：设置大列 fetch 的最大缓冲区大小

其他属性：

• description：返回游标活动状态（包含7个元素的元组）：（name, type_code, display_size, internal_size, precision, scale, null_ok）只有 name 和 type_cose 是必需的
• rowcount：最近一次 execute() 创建或影响的行数
• messages：游标执行后数据库返回的信息元组（可选）
• rownumber：当前结果集中游标所在行的索引（起始行号为 0）

DB-API只中的错误定义

错误类的层次关系：

StandardError
|__Warning
|__Error
|__InterfaceError
|__DatabaseError
|__DataError
|__OperationalError
|__IntegrityError
|__InternalError
|__ProgrammingError
|__NotSupportedError

其他参考文档：

• https://www.python.org/dev/peps/pep-0249/
• http://wiki.python.org/moin/DatabaseInterfaces

The post Python连接数据库之DB-API appeared first on 标点符.

作为后端应用的开发者，我们经常开发、调试、测试完我们的应用并发布到生产环境，用户就可以直接访问到我们的应用了。但对于互联网应用，在你的应用和用户之间还隔着一层低调的或厚或薄的负载均衡层软件，它们不显山不露水默默的发挥着重要的作用，以至于我们经常忽略了它们的存在。因为负载均衡层通常不在一般开发人员的问题域内，而且它们一般都是现成且成熟的解决方案，以至于我们习惯性的忽略和认为乏善可陈。其实不然，本文就写写我对负载均衡层次结构的认知和理解。

硬负载

所谓「硬负载」就是采用硬件设备来提供负载均衡。

在七、八年前那时我在做 Java 的企业软件开发，开发出来的企业级 Java 应用程序就部署在像 Weblogic 之类的应用容器中。而这类应用容器软件又跑在 Unix 的小型机上。把硬件和软件一体打包作为企业应用解决方案卖给客户。这类应用部署的方案十分简单，层级也比较浅。为了保证可靠性，使用两套小型机上各部署一个 Weblogic Server，在应用服务前面使用像 F5 之类的硬件负载均衡器，如下图所示。

由于小型机和前面的 F5 负载均衡硬件都比较贵，所以出于可靠性、可维护性和成本的综合考虑，一般应用部署两套跑在两台小型机上，在前面共享一个 F5 做负载均衡。而一般 F5 和小型机这类硬件设备都至少是 5 个 9 的可靠性保障，所以整体的系统可靠性基本有保障。

进入互联网时代后，应用开发拥抱开源，部署使用更廉价的 PC Server 和免费开源的应用容器。负载均衡也逐步从硬负载向软负载变迁，由于互联网应用的海量特性和部署规模的急剧膨胀，前端负载均衡也开始变得丰富起来。

软负载

进入互联网公司后，我们刚开始开发应用时，业务规模小用户量还不大，机器数量也少（<10）。所以一开始的负载均衡的结构也是很简单的，类似硬负载只是把硬件换成了免费的开源软件并跑在可用性是有 3 个 9 的廉价 PC Server 上。

前面一个 LVS 后面跟着几个应用服务，后来为了方便做按域名的分流和适配切流量上线，中间又加了一层 Nginx。

这样就变成了两层软负载结构了，LVS 负责 4 层，Nginx 负责 7 层。 但 Nginx 只负责了单机内多实例的负载均衡，这里主要是因为当时 PC Server 是物理机，CPU 16/32 core，内存 32/64G 不等，为了更充分的利用资源，一台物理机上都部署了多个应用服务实例，而考虑到 Nginx 工作在 7 层的开销远高于 LVS/DR 模式，所以一般在一个 Nginx 后面挂的实例数也不会超过 10 个。

但随着业务发展和用户流量上升，机器规模也在不断扩张，导致一个网段内的 IP 都不够用了，这套负载结构又遇到了横向扩展的瓶颈，因为 LVS/DR 模式下跨不了网段。所以后来又在 LVS 和 Nginx 之间加了一层 HAProxy，负载结构就变成了下面这样。

其实加了 HAProxy 之后，它也是工作在 7 层，这样 Nginx 这层看起来就不是很有必要。但三层的负载结构能支撑更大规模的集群，而原本在 Nginx 层做了一套方便研发切流量上线的运维管理系统，所以牺牲一点性能换取现在的可维护性和将来扩展性，Nginx 这层就一直保留下来了。而且 Nginx 相比 HAProxy 不是纯粹的负载均衡器，它还能提供 cache 功能，对于某些 HTTP 请求实际只走到 Nginx 这层就可以通过缓存命中而返回。

DNS负载

随着业务发展，公司开始了多个 IDC 的建设，考虑到 IDC 级别的容灾，集群开始部署到多个 IDC。跨 IDC 的负载均衡方案可以简单通过 DNS 轮询来实现，但可控性不好。所以我们没有采用这种，而是采用一主加多子域名的方式来基于业务场景实现动态域名调度和负载。主域名下实际是一个动态流量调度器，跨多个 IDC 部署，对于 HTTP 请求基于重定向方式跳子域名，对于 TCP 方式每次建立长连接前请求分配实际连接的子域名，如下图所示。

CDN负载

最后再加上互联网应用必不可少的 CDN 将静态资源请求的负载分流，那么整个负载的层次结构就完整了。

SSL 带来的负载结构变化

随着互联网的普及，安全问题益发严重，原本早期只有银行网银等使用 HTTPS 方式访问，现在电商类网站也开始启用全站 HTTPS 了。引入 SSL 后对负载结构带来了什么影响么？SSL 属于应用层的协议，所以只能在 7 层上来做，而 HAProxy 也是支持 SSL 协议的，所以一种方式是只需简单的让 HAProxy 开启 SSL 支持完成对内解密对外加密的处理。

但 HAProxy 的作者不太赞同这种方案，因为引入 SSL 处理是有额外的性能开销的。那么在承担确定流量的情况下，假设原本需要 M 台 HAProxy，在开启了 SSL 后可能需要 M + N 台 HAProxy。随着流量增长，这种方式的横向扩展成本较高（毕竟 SSL 证书按服务器数量来收费的）。他给出的解决方案是再独立一层 SSL 代理缓存层，像下面这样。

L4 和 L7 之间独立的 SSL 代理缓存层只负责 SSL 协议的处理，把 HTTPS 转换成 HTTP，并检查本地缓存是否命中。若未命中再转发请求到后端的 L7 层应用负载均衡层。这样的好处是每个层次都可以根据流量来独立伸缩，而且 SSL 层显然可以跨多个应用共享，更节省成本。如果按这个思路来重新调整我们前面的负载均衡结构层次，将会演变成下面这样。

其实，这时我觉得应用前面的那层 Nginx 可能就显得多余了点，不是必需的。但如果现实这么演进下来很可能就会有这么一层冗余的东西存在很长一段时间，这就是理想和现实之间的差距吧。

总结

好了，本文到此为止。作为一名后台开发我其实对上面提及的各类开源软件如何配置、调优和管理并不熟悉，这属于运维开发的问题域范畴。但这并不妨碍我去了解我所开发的应用所处的整个环境是怎样的，多了解些你工作领域范围边界外的 What 和 Why，有时也能帮助我们更好的设计和解决自身问题域内的问题，别为自己设限而最终画地为牢。

本来以为负载均衡这个古老的课题已经定型了，在写本文时又看到新闻，在近日举办的第十三届网络系统设计与实现 USENIX 研讨会上，来自 Google 的工程师又分享了其自研的 Maglev 负载均衡器。刚下了论文还没看，回头看了再来写写。

参考

[1] HAProxy Documentation.  HAProxy Management Guide
[2] HAProxy Documentation.  HAProxy Starter Guide
[3] Willy Tarreau.  Making applications scalable with Load Balancing
[4] LVS wiki.  Load balancing
[5] Wikipedia.  Virtual Router Redundancy Protocol
[6] shuming.  LVS 工作模式以及工作原理

相关文章

• Java 性能优化的五大技巧
• 大话程序猿眼里的高并发（下）
• 大话程序猿眼里的高并发（上）
• 性能优化那些事
• Java性能优化指南，及唯品会的实战
• 关于业务架构的一些思考
• Java应用架构的演化之路
• 图解微服务架构演进
• 什么是Java对象分配率？
• Java 自动装箱性能

在最近几年里，我写了很多有关 HTTPS 和 HTTP/2 的文章，涵盖了证书申请、Nginx 编译及配置、性能优化等方方面面。在这些文章的评论中，不少读者提出了各种各样的问题，我的邮箱也经常收到类似的邮件。本文用来罗列其中有代表性、且我知道解决方案的问题。

为了控制篇幅，本文尽量只给出结论和引用链接，不展开讨论，如有疑问或不同意见，欢迎留言讨论。本文会持续更新，欢迎大家贡献自己遇到的问题和解决方案。

实际上，遇到任何有关部署 HTTPS 或 HTTP/2 的问题，都推荐先用 Qualys SSL Labs's SSL Server Test跑个测试，大部分问题都能被诊断出来。

申请 Let's Encrypt 证书时，一直无法验证通过

这类问题一般是因为 Let's Encrypt 无法访问你的服务器，推荐尝试 acme.sh的 DNS 验证模式，一般都能解决。

网站无法访问，提示 ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

使用 Chrome 53 访问使用 Symantec 证书的网站，很可能会出现这个错误提示。这个问题由 Chrome 的某个 Bug 引起，目前最好的解决方案是升级到 Chrome 54+。相关链接：

• Out of date Chrome results in ERR_CERTIFICATE_TRANSPARENCY_REQUIRED for Symantec operated sites；
• Warning | Certificate Transparency error with Chrome 53；

浏览器提示证书有错误

首先确保网站使用的是合法 CA 签发的有效证书，其次检查 Web Server 配置中证书的完整性（一定要包含站点证书及所有中间证书）。如果缺失了中间证书，部分浏览器能够自动获取但严重影响 TLS 握手性能；部分浏览器直接报证书错误。

如果只有老旧浏览器（例如 IE8 on Windows XP）提示这个错误，多半是因为你的服务器同时部署了使用不同证书的多个 HTTPS 站点，这样，不支持 SNI（Server Name Indication）的浏览器通常会获得错误的证书，从而无法访问。

要解决浏览器不支持 SNI 带来的问题，可以将使用不同证书的 HTTPS 站点部署在不同服务器上；还可以利用 SAN（Subject Alternative Name）机制将多个域名放入同一张证书；当然你也可以直接无视这些老旧浏览器。特别地，使用不支持 SNI 的浏览器访问商业 HTTPS CDN，基本都会因为证书错误而无法使用。

有关 SNI 的更多说明，请看「 关于启用 HTTPS 的一些经验分享（二）」。

启用 HTTP/2 后网站无法访问，提示 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

这个问题一般是由于 CipherSuite 配置有误造成的。建议对照「 Mozilla 的推荐配置、 CloudFlare 使用的配置」等权威配置修改 Nginx 的 ssl_ciphers配置项。

有关这个问题的具体原因，请看「 从启用 HTTP/2 导致网站无法访问说起」。

网站无法访问，提示 ERR_SSL_VERSION_OR_CIPHER_MISMATCH

出现这种错误，通常都是配置了不安全的 SSL 版本或者 CipherSuite —— 例如服务器只支持 SSLv3，或者 CipherSuite 只配置了 RC4 系列，使用 Chrome 访问就会得到这个提示。解决方案跟上一节一样。

还有一种情况会出现这种错误 —— 使用不支持 ECC 的浏览器访问只提供 ECC 证书的网站。例如在 Windows XP 中，使用 ECC 证书的网站只有 Firefox 能访问（Firefox 的 TLS 自己实现，不依赖操作系统）；Android 平台中，也需要 Android 4+ 才支持 ECC 证书。如果是这种情况，有一个比较完美的解决方案，请看「 开始使用 ECC 证书」。

在 Nginx 启用 HTTP/2 后，浏览器依然使用 HTTP/1.1

Chrome 51+ 移除了对 NPN 的支持，只支持 ALPN，而浏览器和服务端都支持 NPN 或 ALPN，是用上 HTTP/2 的大前提。换句话说，如果服务端不支持 ALPN，Chrome 51+ 无法使用 HTTP/2。

OpenSSL 1.0.2 才开始支持 ALPN —— 很多主流服务器系统自带的 OpenSSL 都低于这个版本，所以推荐在编译 Web Server 时自己指定 OpenSSL 的位置。

详见「 为什么我们应该尽快支持 ALPN」。

升级到 HTTPS 后，网站部分资源不加载或提示不安全

记住一个原则：HTTPS 网站的所有外链资源（CSS、JS、图片、音频、字体文件、异步接口、表单 action 地址等等）都需要升级为 HTTPS，就不会遇到这个问题了。

详见「 关于启用 HTTPS 的一些经验分享（三）」。

本文链接： https://imququ.com/post/troubleshooting-https.html， 参与讨论

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

经过三个月的完善与修复，经过几个项目的检验，SpringBlade稳定版终于发布啦！

SpringBlade是基于多个优秀的开源项目，高度整合封装而成的快速开发平台。

鸣谢

1.JFinal
2.eova
3.hutool
4.beetl
5.beetlsql
6.dreamlu
7.kisso
8.spring-shiro-training

内置功能

• 用户管理

• 角色管理

• 菜单管理

• 字典管理

• 部门管理

• 附件管理

• 参数管理

• 连接池监视

• 日志管理

• 代码生成

技术选型
1、后端
* 核心框架：Spring Framework
* 安全框架：Apache Shiro
* 视图框架：Spring MVC
* 服务端验证：Blade Validator
* 任务调度：Spring Task
* 持久层框架：beetlsql
* 模板引擎：beetl
* 数据库连接池：Alibaba Druid
* 缓存框架：Ehcache
* 日志管理：SLF4J、LOGBACKUP
* 工具类：Apache Commons、FastJson、EASYPOI、BladeToolBox


2、前端
* JS框架：jQuery
* CSS框架：Twitter Bootstrap
* 客户端验证：JQuery-html5Validate
* 富文本：KindEcitor
* 数据表格：jqGrid
* 树结构控件：jQuery zTree
* 弹出层：Layer
* 日期控件： LayDate
* 图表控件：echarts

代码示例

实体类

@Table(name = "notice")
@BindID(name = "id")
@SuppressWarnings("serial")
public class Notice extends BaseModel {
    private String id;
    private Integer creater;
    private String content;
    private String title;
    private Date createTime;

    @AutoID
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }   
    .....................

}

新增

    @ResponseBody
    @RequestMapping(KEY_SAVE)
    public AjaxResult save() {
        Notice notice = mapping(PREFIX, Notice.class);
        boolean temp = Blade.create(Notice.class).save(notice);
        if (temp) {
            return success(SAVE_SUCCESS_MSG);
        } else {
            return error(SAVE_FAIL_MSG);
        }
    }

修改

    @ResponseBody
    @RequestMapping(KEY_UPDATE)
    public AjaxResult update() {
        Notice notice = mapping(PREFIX, Notice.class);
        boolean temp = Blade.create(Notice.class).update(notice);
        if (temp) {
            return success(UPDATE_SUCCESS_MSG);
        } else {
            return error(UPDATE_FAIL_MSG);
        }
    }

删除

    @ResponseBody
    @RequestMapping(KEY_REMOVE)
    public AjaxResult remove(@RequestParam String ids) {
        int cnt = Blade.create(Notice.class).deleteByIds(ids);
        if (cnt > 0) {
            return success(DEL_SUCCESS_MSG);
        } else {
            return error(DEL_FAIL_MSG);
        }
    }

自定义sql查询

 List<Map> list = Db.selectList("select * form news where title = #{title}", Paras.create().set("title", "标题测试"));

 String editor = Db.init("otherDb").queryStr("select editor form news where newsId = #{newsId}", Paras.create().set("newsId", 123));

根据md文件执行修改操作

 int cnt = Md.update("news.update", Paras.create().set("title", "标题测试").set("id", "1"));

根据条件修改

 boolean temp = Blade.create(News.class).updateBy("editor = #{editor}", "title = #{title}", Paras.create().set("title", "测试标题").set("editor", "编辑一"));

根据条件删除

    String ids = "1,2,3,4,5";
    String[] idArr = ids.split(",");
    int cnt = Blade.create(News.class).deleteBy("status in (#{join(ids)})", Paras.create().set("ids", idArr));

通用service

   public interface NoticeService extends IService<Notice> {

    }


    @Service
    public class NoticeServiceImpl extends BaseService<Notice> implements NoticeService {

    }


    @Autowired
    NoticeService service;

    @ResponseBody
    @RequestMapping(KEY_SAVE)
    public AjaxResult save() {
        Notice notice = mapping(PREFIX, Notice.class);
        boolean temp = service.save(notice);
        if (temp) {
            return success(SAVE_SUCCESS_MSG);
        } else {
            return error(SAVE_FAIL_MSG);
        }
    }

分页封装

    @ResponseBody
    @RequestMapping(KEY_LIST)
    public Object list() {
        Object grid = paginate(LIST_SOURCE, new IQuery() {

            @Override
            public void queryBefore(AopContext ac) {
                if (ShiroKit.lacksRole(ConstShiro.ADMINISTRATOR)) {
                    String condition = "and creater = #{creater}";
                    ac.setCondition(condition);
                    ac.getParam().put("creater", ShiroKit.getUser().getId());
                }
            }

            @Override
            public void queryAfter(AopContext ac) {
                @SuppressWarnings("unchecked")
                BladePage<Map<String, Object>> page = (BladePage<Map<String, Object>>) ac.getObject();
                List<Map<String, Object>> list = page.getRows();
                for (Map<String, Object> map : list) {
                    map.put("createrName", SysCache.getDictName(102, map.get("creater")));
                }
            }
        });

        return grid;
    }

后台界面

注：前端UI为ACE-ADMIN，如果商用请购买 ACE-ADMIN的授权。

git地址： http://git.oschina.net/smallc/SpringBlade

Google 使用的技术一般都自带光环，吸引程序员的注意，基础设施方面的东西就更是如此，年初 Google 发布了篇论文介绍内部的负载均衡器的实现，让我们有机会一睹可能是全球最好的负载均衡器。

通常情况下的负载均衡要在灵活性和性能之间做权衡，用户态软件层面有 Haproxy 和 Nginx 这样的老牌负载均衡软件，他们一般配置和使用起来都比较容易，但是由于需要数据包从网卡到内核再到软件一层层向上处理，再一层层向下转发，堆栈比较深单机性能通常都比较一般。为了提高单机性能，减少堆栈层级就有了 Linux 里华人之光的 LVS，工作在内核层的负载均衡器，性能有着数量级的提高，然而配置起来相对也比较复杂而且对网络条件要求也有特殊要求。那 Google 有什么秘密的配方来达到高性能呢？

一般来说负载均衡器本身就是后端服务横向扩展的一个接入点，对于一般站点一个负载均衡器就够了，然而应对 Google 这种级别的流量，负载均衡器本身也要能横向扩展，还要处理负载均衡器的高可用，Google 又是如何做到的呢？

以我们访问 www.google.com 为例，第一步 DNS 服务器会根据请求的位置返回一个离请求地理位置最近的 VIP 地址，先在 DNS 这一层做一个横向扩展。接下来请求达到 VIP 对应的路由器，路由器通过 ECMP 协议，可以将请求平均分配到下面对等的多个负载均衡器上，这样在路由器这一层做了个负载均衡，让后面的负载均衡器也实现了横向扩展。再往下是一个类似于 LVS 中 DR 模式的分发，负载均衡器将请求包转发给服务器同时将源地址改为客户请求时的地址，服务器响应时将响应包的源地址改为 VIP 的地址直接打给路由器而不通过负载均衡器来降低负载均衡器压力。流程图如下

对了，Google 的这个负载均衡器叫 Maglev，磁悬浮列车的意思。自然是要做到极致的性能，只看流程似乎和 LVS 中 DR 模式很类似，但内部就完全不一样了。

简单的说虽然 LVS 已经做到 Linux 内核里了，但是在 Google 看来 Linux 是性能的瓶颈，到 LVS 之前还要经过完整的 TCP/IP 协议栈以及内核的一系列 filter 模块，而这些对于转发来说是没有必要的。于是 Google 的做法就是简单粗暴的绕过内核，把 Maglev 直接架在网卡上对接网卡的输入和输出队列，来一个数据包也不需要完整的 TCP/IP 协议栈的解析，进来的包只要分析前几个字节，拿出源地址，源端口，目标地址，目标端口和协议号这个五元组对于转发来说就已经足够了。剩下的诸如 payload，序列号之类的东西统统不关心直接塞到网卡输出口给后面就行了。

前几天听美团的介绍他们的负载均衡器是用的类似的思路用 DPDK 直接在网卡上编写应用，性能相对 LVS 就有数倍的提升。看 Maglev 的实现为了榨干性能是直接写在网卡上的，都没有 DPDK 之类的封装。绕过内核就可以自己分配内存管理内存就可以进一步的压榨性能。论文中可以看到 Maglev 是直接和网卡共享内存的，这样就不需要将数据包再从网卡进行一次复制到负载均衡器中，也不需要把数据包再从负载均衡器复制到网卡，网卡入口队列，负载均衡器，网卡出口队列共享一个数据池空间，三个指针不断的移动处理数据包，可谓是在内存这里做到了极致。

当然诸如 CPU 绑定，每个 CPU 专职处理一个线程来避免 cache miss，memory contention 这种常规优化也是都有的。最终的效果就是处理一个数据包平均需要 350ns，而性能发生抖动的情况一般是由于网卡发数据包是批量的或者要等待一个 timer 的中断，而这个中断的时间是 50us 所以当流量小的时候这个延迟可能会达到 50us。（我觉得 Google 这么写其实是在炫耀自己性能好，瓶颈在网卡刷新速度上，而不在负载均衡器上）

通常的负载均衡器都是一个单点，而 Maglev 是一个集群，集群就会碰到很多的问题。严格来说负载均衡器不能算是一个无状态的服务，因为 TCP 连接本身是有状态的，一组会话内的请求包必须转发到相同的后端服务器，不然服务器端的 TCP 会话就乱套了。对于单点的负载均衡器来说很好解决，记录个转发表里面有每个数据包的五元组和它第一转发到哪台机器，来一个新的数据包查这个表就知道给谁了。而像 Maglev 这样的集群数据包是通过路由器 ECMP 随机分发的，第一个数据包是这个 Maglev node 处理，下一个就不知道去哪个 Maglev node 了。而且集群就会涉及滚动式的更新和随机的故障,这样本机的转发表也就很可能会丢失。

之前听美团的介绍，他们的做法是在多台机器之间做内存的同步每次更新都要进行一次同步来保证所有机器转发表的一致。而 Google 一帮人不愧是搞研究出身的，直接就上了一致性哈希这个大杀器。这样的话可以直接通过五元组散列到后端的一台固定服务器，这样硬生生的把有状态服务做成了无状态,如此一来 Maglev 层面个就可以随意的更新，上线下线了。顺便的一个好处就是后端增加下线服务器都只会影响到当前这台机器所处理的连接不会造成所有连接的 rehash。当然只用一个普通的一致性哈希算法也没啥意思，Google 为了自己的需求专门写了个 Maglev Hashing

论文里还介绍了很多负载均衡器运维方面的经验以及设计的过程和经验，还说了下一些新的发展方向，感兴趣的可以看一下 论文原文，当然你要翻下墙（逃

　　如果只是一个http业务，一般是不需要调试其TCP流的；但是现在我正在处理一个基于TCP长连接的协议，有时候有任何问题，通过TCP流都可以帮助我调试服务。

　　但是这只是本地开发时常见的情况，如果要调试测试服务器乃至生产服务器接受的数据流是否正常呢？当然可以在服务器运行tcpdump，比如 tcpdump -i eth0 tcp port 抓包端口号 -w /tmp/debug.cap，然后将debug.cap从服务器scp到本地来，用wireshark详细研究。

　　但是有时候调试，服务正常与否跟相应时间什么的也有关系，这种事后研究的方式就不方便了，可以直接ssh服务器，通过tcpdump输出到管道，然后管道这边通过wireshark去抓包分析，省去了scp的麻烦，也能实时调试了。

　　可以使用命令 ssh fedSDE "sudo tcpdump -s 0 -U -n -i eth0 port 抓包端口号 -w -" | wireshark -k -i -来轻松做到这点。

　　不过有时候会有异常，“sudo：抱歉，您必须拥有一个终端来执行 sudo”，则需要使用管理员修改/etc/sudoers，把 Defaults requiretty这一行注释掉就可以了。

从此妈妈再也不用担心我调试服务器上的流量啦！

在安装MariaDB的时候了解到代替InnoDB的TokuDB，看简介非常的棒，这里对ToduDB做一个初步的整理，使用后再做更多的分享。

什么是TokuDB？

在MySQL最流行的支持全事务的引擎为INNODB。其特点是数据本身是用B-TREE来组织，数据本身即是庞大的根据主键聚簇的B-TREE索引。 所以在这点上，写入速度就会有些降低，因为要每次写入要用一次IO来做索引树的重排。特别是当数据量本身比内存大很多的情况下，CPU本身被磁盘IO纠缠的做不了其他事情了。这时我们要考虑如何减少对磁盘的IO来排解CPU的处境，常见的方法有：

• 把INNODB 个PAGE增大（默认16KB），但增大也就带来了一些缺陷。 比如，对磁盘进行CHECKPOINT的时间将延后。
• 把日志文件放到更快速的磁盘上，比如SSD。

TokuDB 是一个支持事务的“新”引擎，有着出色的数据压缩功能，由美国 TokuTek 公司（现在已经被 Percona 公司收购）研发。拥有出色的数据压缩功能，如果您的数据写多读少，而且数据量比较大，强烈建议您使用TokuDB，以节省空间成本，并大幅度降低存储使用量和IOPS开销，不过相应的会增加 CPU 的压力。

TokuDB 的特性

1.丰富的索引类型以及索引的快速创建

TokuDB 除了支持现有的索引类型外， 还增加了(第二)集合索引, 以满足多样性的覆盖索引的查询, 在快速创建索引方面提高了查询的效率

2.(第二)集合索引

也可以称作非主键的集合索引, 这类索引也包含了表中的所有列, 可以用于覆盖索引的查询需要, 比如以下示例, 在where 条件中直接命中 index_b 索引, 避免了从主键中再查找一次.

CREATE TABLE table (
column_a INT,
column_b INT,
column_c INT,
PRIMARY KEY index_a (column_a),
CLUSTERING KEY index_b (column_b)) ENGINE = TokuDB;

SELECT column_c
FROM table
WHERE column_b BETWEEN 10 AND 100;

见:  http://tokutek.com/2009/05/introducing_multiple_clustering_indexes/

3.索引在线创建(Hot Index Creation)

TokuDB 允许直接给表增加索引而不影响更新语句(insert, update 等)的执行。可以通过变量 tokudb_create_index_online 来控制是否开启该特性, 不过遗憾的是目前还只能通过 CREATE INDEX 语法实现在线创建, 不能通过 ALTER TABLE 实现. 这种方式比通常的创建方式慢了许多, 创建的过程可以通过 show processlist 查看。不过 tokudb 不支持在线删除索引, 删除索引的时候会对标加全局锁。

> SET tokudb_create_index_online=ON;
Query OK, 0 rows affected (0.00 sec)> CREATE INDEX index ON table (field_name);

4.在线更改列(Add, Delete, Expand, Rename)

TokuDB 可以在轻微阻塞更新或查询语句的情况下， 允许实现以下操作：

• 增加或删除表中的列
• 扩充字段: char, varchar, varbinary 和 int 类型的列
• 重命名列, 不支持字段类型: TIME, ENUM, BLOB, TINYBLOB, MEDIUMBLOB, LONGBLOB

这些操作通常是以表锁级别阻塞(几秒钟时间)其他查询的执行, 当表记录下次从磁盘加载到内存的时候, 系统就会随之对记录进行修改操作(add, delete 或 expand)， 如果是 rename 操作, 则会在几秒钟的停机时间内完成所有操作。

TokuDB的这些操作不同于 InnoDB, 对表进行更新后可以看到 rows affected 为 0, 即更改操作会放到后台执行, 比较快速的原因可能是由于 Fractal-tree 索引的特性, 将随机的 IO 操作替换为顺序 IO 操作， Fractal-tree的特性中， 会将这些操作广播到所有行, 不像 InnoDB, 需要 open table 并创建临时表来完成.

看看官方对该特性的一些指导说明:

• 所有的这些操作不是立即执行， 而是放到后台中由 Fractal Tree 完成, 操作包括主键和非主键索引。也可以手工强制执行这些操作, 使用 OPTIMIZE TABLE X 命令即可, TokuDB 从1.0 开始OPTIMIZE TABLE命令也支持在线完成, 但是不会重建索引
• 不要一次更新多列, 分开对每列进行操作
• 避免同时对一列进行 add, delete, expand 或 drop 操作
• 表锁的时间主要由缓存中的脏页(dirty page)决定, 脏页越多 flush 的时间就越长. 每做一次更新, MySQL 都会关闭一次表的连接以释放之前的资源
• 避免删除的列是索引的一部分, 这类操作会特别慢, 非要删除的话可以去掉索引和该列的关联再进行删除操作
• 扩充类的操作只支持 char, varchar, varbinary 和 int 类型的字段
• 一次只 rename 一列, 操作多列会降级为标准的 MySQL 行为, 语法中列的属性必须要指定上, 如下:

  • ALTER TABLE table
    CHANGE column_old column_new
    DATA_TYPE REQUIRED_NESS DEFAULT

• rename 操作还不支持字段: TIME, ENUM, BLOB, TINYBLOB, MEDIUMBLOB, LONGBLOB.
• 不支持更新临时表;

5.数据压缩

TokuDB中所有的压缩操作都在后台执行, 高级别的压缩会降低系统的性能, 有些场景下会需要高级别的压缩. 按照官方的建议: 6核数以下的机器建议标准压缩, 反之可以使用高级别的压缩。

每个表在 create table 或 alter table 的时候通过 ROW_FORMAT 来指定压缩的算法：

CREATE TABLE table (
column_a INT NOT NULL PRIMARY KEY,
column_b INT NOT NULL) ENGINE=TokuDB
ROW_FORMAT=row_format;

ROW_FORMAT默认由变量 tokudb_row_format 控制, 默认为 tokudb_zlib, 可以的值包括:

• tokudb_zlib: 使用 zlib 库的压缩模式，提供了中等级别的压缩比和中等级别的CPU消耗。
• tokudb_quicklz: 使用 quicklz 库的压缩模式， 提供了轻量级的压缩比和较低基本的CPU消耗。
• tokudb_lzma: 使用lzma库压缩模式，提供了高压缩比和高CPU消耗。
• tokudb_uncompressed: 不使用压缩模式。

6.Read free 复制特性

得益于 Fracal Tree 索引的特性, TokuDB 的 slave 端能够以低于读IO的消耗来应用 master 端的变化, 其主要依赖 Fractal Tree 索引的特性，可以在配置里启用特性

• insert/delete/update操作部分可以直接插入到合适的 Fractal Tree 索引中, 避免 read-modify-write 行为的开销;
• delete/update 操作可以忽略唯一性检查带来的 IO 方面的开销

不好的是, 如果启用了 Read Free Replication 功能, Server 端需要做如下设置:

• master：复制格式必须为 ROW， 因为 tokudb 还没有实现对 auto-increment函数进行加锁处理, 所以多个并发的插入语句可能会引起不确定的 auto-increment值, 由此造成主从两边的数据不一致.
• slave：开启 read-only; 关闭唯一性检查(set tokudb_rpl_unique_checks=0);关闭查找(read-modify-write)功能(set tokudb_rpl_lookup_rows=0);

slave 端的设置可以在一台或多台 slave 中设置：MySQL5.5 和 MariaDB5.5中只有定义了主键的表才能使用该功能, MySQL 5.6, Percona 5.6 和 MariaDB 10.X 没有此限制

7.事务, ACID 和恢复

• 默认情况下, TokuDB 定期检查所有打开的表, 并记录 checkpoint 期间所有的更新, 所以在系统崩溃的时候, 可以恢复表到之前的状态(ACID-compliant), 所有的已提交的事务会更新到表里,未提交的事务则进行回滚. 默认的检查周期每60s一次, 是从当前检查点的开始时间到下次检查点的开始时间, 如果 checkpoint 需要更多的信息, 下次的checkpoint 检查会立即开始, 不过这和 log 文件的频繁刷新有关. 用户也可以在任何时候手工执行 flush logs 命令来引起一次 checkpoint 检查; 在数据库正常关闭的时候, 所有开启的事务都会被忽略.
• 管理日志的大小: TokuDB 一直保存最近的checkpoing到日志文件中, 当日志达到100M的时候, 会起一个新的日志文件; 每次checkpoint的时候, 日志中旧于当前检查点的都会被忽略, 如果检查的周期设置非常大, 日志的清理频率也会减少。 TokuDB也会为每个打开的事务维护回滚日志, 日志的大小和事务量有关， 被压缩保存到磁盘中, 当事务结束后，回滚日志会被相应清理.
• 恢复: TokuDB自动进行恢复操作, 在崩溃后使用日志和回滚日志进行恢复, 恢复时间由日志大小(包括未压缩的回滚日志)决定.
• 禁用写缓存: 如果要保证事务安全, 就得考虑到硬件方面的写缓存. TokuDB 在 MySQL 里也支持事务安全特性(transaction safe), 对系统而言, 数据库更新的数据不一样真的写到磁盘里, 而是缓存起来, 在系统崩溃的时候还是会出现丢数据的现象, 比如TokuDB不能保证挂载的NFS卷可以正常恢复, 所以如果要保证安全,最好关闭写缓存, 但是可能会造成性能的降低.通常情况下需要关闭磁盘的写缓存, 不过考虑到性能原因, XFS文件系统的缓存可以开启, 不过穿线错误”Disabling barriers”后，就需要关闭缓存. 一些场景下需要关闭文件系统(ext3)缓存, LVM, 软RAID 和带有 BBU(battery-backed-up) 特性的RAID卡

8.过程追踪

TokuDB 提供了追踪长时间运行语句的机制. 对 LOAD DATA 命令来说，SHOW PROCESSLIST 可以显示过程信息, 第一个是类似 “Inserted about 1000000 rows” 的状态信息, 下一个是完成百分比的信息, 比如 “Loading of data about 45% done”; 增加索引的时候, SHOW PROCESSLIST 可以显示 CREATE INDEX 和 ALTER TABLE 的过程信息, 其会显示行数的估算值, 也会显示完成的百分比; SHOW PROCESSLIST 也会显示事务的执行情况, 比如 committing 或 aborting 状态.

9.迁移到 TokuDB

可以使用传统的方式更改表的存储引擎, 比如 “ALTER TABLE … ENGINE = TokuDB” 或 mysqldump 导出再倒入, INTO OUTFILE 和 LOAD DATA INFILE 的方式也可以。

10.热备

Percona Xtrabackup 还未支持 TokuDB 的热备功能, percona 也为表示有支持的打算  http://www.percona.com/blog/2014/07/15/tokudb-tips-mysql-backups/ ;对于大表可以使用 LVM 特性进行备份,  https://launchpad.net/mylvmbackup , 或 mysdumper 进行备份。TokuDB 官方提供了一个热备插件 tokudb_backup.so, 可以进行在线备份, 详见  https://github.com/Tokutek/tokudb-backup-plugin， 不过其依赖 backup-enterprise, 无法编译出 so 动态库, 是个商业的收费版本, 见  https://www.percona.com/doc/percona-server/5.6/tokudb/tokudb_installation.html

总结

TokuDB的优点:

• 高压缩比，默认使用zlib进行压缩，尤其是对字符串(varchar,text等)类型有非常高的压缩比，比较适合存储日志、原始数据等。官方宣称可以达到1：12。
• 在线添加索引，不影响读写操作
• HCADER 特性，支持在线字段增加、删除、扩展、重命名操作，（瞬间或秒级完成）
• 支持完整的ACID特性和事务机制
• 非常快的写入性能， Fractal-tree在事务实现上有优势,无undo log，官方称至少比innodb高9倍。
• 支持show processlist 进度查看
• 数据量可以扩展到几个TB；
• 不会产生索引碎片；
• 支持hot column addition,hot indexing,mvcc

TokuDB缺点：

• 不支持外键(foreign key)功能，如果您的表有外键，切换到 TokuDB引擎后，此约束将被忽略。
• TokuDB 不适大量读取的场景，因为压缩解压缩的原因。CPU占用会高2-3倍，但由于压缩后空间小，IO开销低，平均响应时间大概是2倍左右。
• online ddl 对text,blob等类型的字段不适用
• 没有完善的热备工具，只能通过mysqldump进行逻辑备份

适用场景：

• 访问频率不高的数据或历史数据归档
• 数据表非常大并且时不时还需要进行DDL操作

TokuDB的索引结构–分形树的实现

TokuDB和InnoDB最大的不同在于TokuDB采用了一种叫做Fractal Tree的索引结构，使其在随机写数据的处理上有很大提升。目前无论是SQL Server，还是MySQL的innodb，都是用的B+Tree（SQL Server用的是标准的B-Tree）的索引结构。InnoDB是以主键组织的B+Tree结构，数据按照主键顺序排列。对于顺序的自增主键有很好的性能，但是不适合随机写入，大量的随机I/O会使数据页分裂产生碎片，索引维护开销很多大。TokuDB解决随机写入的问题得益于其索引结构，Fractal Tree 和 B-Tree的差别主要在于索引树的内部节点上，B-Tree索引的内部结构只有指向父节点和子节点的指针，而Fractal Tree的内部节点不仅有指向父节点和子节点的指针，还有一块Buffer区。当数据写入时会先落到这个Buffer区上，该区是一个FIFO结构，写是一个顺序的过程，和其他缓冲区一样，满了就一次性刷写数据。所以TokuDB上插入数据基本上变成了一个顺序添加的过程。

BTree和Fractal tree的比较：

Fractal tree(分形树)简介

分形树是一种写优化的磁盘索引数据结构。 在一般情况下， 分形树的写操作（Insert/Update/Delete）性能比较好，同时它还能保证读操作近似于B+树的读性能。据Percona公司测试结果显示, TokuDB分形树的写性能优于InnoDB的B+树)， 读性能略低于B+树。

ft-index的磁盘存储结构

ft-index采用更大的索引页和数据页（ft-index默认为4M, InnoDB默认为16K）， 这使得ft-index的数据页和索引页的压缩比更高。也就是说，在打开索引页和数据页压缩的情况下，插入等量的数据， ft-index占用的存储空间更少。ft-index支持在线修改DDL (Hot Schema Change)。 简单来讲，就是在做DDL操作的同时(例如添加索引)，用户依然可以执行写入操作， 这个特点是ft-index树形结构天然支持的。 此外， ft-index还支持事务(ACID)以及事务的MVCC(Multiple Version Cocurrency Control 多版本并发控制)， 支持崩溃恢复。正因为上述特点， Percona公司宣称TokuDB一方面带给客户极大的性能提升， 另一方面还降低了客户的存储使用成本。

ft-index的索引结构图如下：

灰色区域表示ft-index分形树的一个页，绿色区域表示一个键值，两格绿色区域之间表示一个儿子指针。 BlockNum表示儿子指针指向的页的偏移量。Fanout表示分形树的扇出，也就是儿子指针的个数。 NodeSize表示一个页占用的字节数。NonLeafNode表示当前页是一个非叶子节点，LeafNode表示当前页是一个叶子节点，叶子节点是最底层的存放Key-value键值对的节点， 非叶子节点不存放value。 Heigth表示树的高度， 根节点的高度为3， 根节点下一层节点的高度为2， 最底层叶子节点的高度为1。Depth表示树的深度，根节点的深度为0， 根节点的下一层节点深度为1。

分形树的树形结构非常类似于B+树, 它的树形结构由若干个节点组成（我们称之为Node或者Block，在InnoDB中，我们称之为Page或者页）。 每个节点由一组有序的键值组成。假设一个节点的键值序列为[3, 8], 那么这个键值将(-00, +00)整个区间划分为(-00, 3), [3, 8), [8, +00) 这样3个区间， 每一个区间就对应着一个儿子指针（Child指针）。 在B+树中， Child指针一般指向一个页， 而在分形树中，每一个Child指针除了需要指向一个Node的地址(BlockNum)之外，还会带有一个Message Buffer (msg_buffer)， 这个Message Buffer 是一个先进先出(FIFO)的队列，用来存放Insert/Delete/Update/HotSchemaChange这样的更新操作。

按照ft-index源代码的实现， 对ft-index中分形树更为严谨的说法：

• 节点(block或者node, 在InnoDB中我们称之为Page或者页)是由一组有序的键值组成， 第一个键值设置为null键值， 表示负无穷大。
• 节点分为两种类型，一种是叶子节点， 一种是非叶子节点。 叶子节点的儿子指针指向的是BasementNode, 非叶子节点指向的是正常的Node 。 这里的BasementNode节点存放的是多个K-V键值对， 也就是说最后所有的查找操作都需要定位到BasementNode才能成功获取到数据(Value)。这一点也和B+树的LeafPage类似， 数据(Value)都是存放在叶子节点， 非叶子节点用来存放键值(Key)做索引。 当叶子节点加载到内存后，为了快速查找到BasementNode中的数据(Value)， ft-index会把整个BasementNode中的key-value都转换为一棵弱平衡二叉树， 这棵平衡二叉树有一个很逗逼的名字，叫做 替罪羊树。
• 每个节点的键值区间对应着一个儿子指针(Child Pointer)。 非叶子节点的儿子指针携带着一个 MessageBuffer， MessageBuffer是一个FIFO队列。用来存放Insert/Delete/Update/HotSchemaChange这样的更新操作。儿子指针以及MessageBuffer都会序列化存放在Node的磁盘文件中。
• 每个非叶子节点(Non Leaf Node)儿子指针的个数必须在[fantout/4, fantout]这个区间之内。 这里fantout是分形树（B+树也有这个概念）的一个参数，这个参数主要用来维持树的高度。当一个非叶子节点的儿子指针个数小于fantout/4 ， 那么我们认为这个节点的太空虚了，需要和其他节点合并为一个节点(Node Merge)， 这样能减少整个树的高度。当一个非叶子节点的儿子指针个数超过fantout， 那么我们认为这个节点太饱满了， 需要将一个节点一拆为二(Node Split)。 通过这种约束控制，理论上就能将磁盘数据维持在一个正常的相对平衡的树形结构，这样可以控制插入和查询复杂度上限。
• 注意： 在ft-index实现中，控制树平衡的条件更加复杂， 例如除了考虑fantout之外，还要保证节点总字节数在[NodeSize/4, NodeSize]这个区间， NodeSize一般为4M ，当不在这个区间时， 需要做对应的合并(Merge)或者分裂(Split)操作。

分形树的Insert/Delete/Update实现

我们说到分形树是一种写优化的数据结构， 它的写操作性能要优于B+树的写操作性能。 那么它究竟如何做到更优的写操作性能呢？首先， 这里说的写操作性能，指的是随机写操作。 举个简单例子，假设我们在MySQL的InnoDB表中不断执行这个SQL语句： insert into sbtest set x = uuid()， 其中sbtest表中有一个唯一索引字段为x。 由于uuid()的随机性，将导致插入到sbtest表中的数据散落在各个不同的叶子节点(Leaf Node)中。 在B+树中， 大量的这种随机写操作将导致LRU-Cache中大量的热点数据页落在B+树的上层(如下图所示）。这样底层的叶子节点命中Cache的概率降低，从而造成大量的磁盘IO操作， 也就导致B+树的随机写性能瓶颈。但B+树的顺序写操作很快，因为顺序写操作充分利用了局部热点数据， 磁盘IO次数大大降低。

下面来说说分形树插入操作的流程。 为了方便后面描述，约定如下：

• 以Insert操作为例， 假定插入的数据为(Key, Value)
• 加载节点(Load Page)，都是先判断该节点是否命中LRU-Cache。仅当缓存不命中时， ft-index才会通过seed定位到偏移量读取数据页到内存
• 暂时不考虑崩溃日志和事务处理。

详细流程如下：

1. 加载Root节点；
2. 判断Root节点是否需要分裂(或合并)，如果满足分裂(或者合并)条件，则分裂(或者合并)Root节点。 具体分裂Root节点的流程，感兴趣的同学可以开开脑洞。
3. 当Root节点height>0, 也就是Root是非叶子节点时， 通过二分搜索找到Key所在的键值区间Range，将(Key, Value)包装成一条消息(Insert, Key, Value) ， 放入到键值区间Range对应的Child指针的Message Buffer中。
4. 当Root节点height=0时，即Root是叶子节点时， 将消息(Insert, Key, Value) 应用(Apply)到BasementNode上， 也就是插入(Key, Value)到BasementNode中。

这里有一个非常诡异的地方，在大量的插入（包括随机和顺序插入）情况下， Root节点会经常性的被撑饱满，这将会导致Root节点做大量的分裂操作。然后，Root节点做了大量的分裂操作之后，产生大量的height=1的节点， 然后height=1的节点被撑爆满之后，又会产生大量height=2的节点， 最终树的高度越来越高。 这个诡异的之处就隐藏了分形树写操作性能比B+树高的秘诀： 每一次插入操作都落在Root节点就马上返回了， 每次写操作并不需要搜索树形结构最底层的BasementNode， 这样会导致大量的热点数据集中落在在Root节点的上层(此时的热点数据分布图类似于上图)， 从而充分利用热点数据的局部性，大大减少了磁盘IO操作。

Update/Delete操作的情况和Insert操作的情况类似， 但是需要特别注意的地方在于，由于分形树随机读性能并不如InnoDB的B+树。因此，Update/Delete操作需要细分为两种情况考虑，这两种情况测试性能可能差距巨大：

• 覆盖式的Update/Delete (overwrite)。 也就是当key存在时， 执行Update/Delete； 当key不存在时，不做任何操作，也不需要报错。
• 严格匹配的Update/Delete。 当key存在时， 执行update/delete ; 当key不存在时， 需要报错给上层应用方。 在这种情况下，我们需要先查询key是否存在于ft-index的basementnode中，于是Point-Query默默的拖了Update/Delete操作的性能后退。

此外，ft-index为了提升顺序写的性能，对顺序插入操作做了一些优化，例如 顺序写加速。

分形树的Point-Query实现

在ft-index中， 类似select from table where id = ? （其中id是索引）的查询操作称之为Point-Query； 类似select from table where id >= ? and id <= ? （其中id是索引）的查询操作称之为Range-Query。 上文已经提到， Point-Query读操作性能并不如InnoDB的B+树， 这里详细描述Point-Query的相关流程。 （这里假设要查询的键值为Key）

1. 加载Root节点，通过二分搜索确定Key落在Root节点的键值区间Range, 找到对应的Range的Child指针。
2. 加载Child指针对应的的节点。 若该节点为非叶子节点，则继续沿着分形树一直往下查找，一直到叶子节点停止。 若当前节点为叶子节点，则停止查找。

查找到叶子节点后，我们并不能直接返回叶子节点中的BasementNode的Value给用户。 因为分形树的插入操作是通过消息(Message)的方式插入的， 此时需要把从Root节点到叶子节点这条路径上的所有消息依次apply到叶子节点的BasementNode。 待apply所有的消息完成之后，查找BasementNode中的key对应的value，就是用户需要查找的值。

分形树的查找流程基本和 InnoDB的B+树的查找流程类似， 区别在于分形树需要将从Root节点到叶子节点这条路径上的messge buffer都往下推，并将消息apply到BasementNode节点上。注意查找流程需要下推消息， 这可能会造成路径上的部分节点被撑饱满，但是ft-index在查询过程中并不会对叶子节点做分裂和合并操作， 因为ft-index的设计原则是： Insert/Update/Delete操作负责节点的Split和Merge, Select操作负责消息的延迟下推(Lazy Push)。 这样，分形树就将Insert/Delete/Update这类更新操作通过未来的Select操作应用到具体的数据节点，从而完成更新。

分形树的Range-Query实现

下面来介绍Range-Query的查询实现。简单来讲， 分形树的Range-Query基本等价于进行N次Point-Query操作，操作的代价也基本等价于N次Point-Query操作的代价。 由于分形树在非叶子节点的msg_buffer中存放着BasementNode的更新操作，因此我们在查找每一个Key的Value时，都需要从根节点查找到叶子节点， 然后将这条路径上的消息apply到basenmentNode的Value上。 这个流程可以用下图来表示。

但是在B+树中， 由于底层的各个叶子节点都通过指针组织成一个双向链表， 结构如下图所示。 因此，我们只需要从跟节点到叶子节点定位到第一个满足条件的Key, 然后不断在叶子节点迭代next指针，即可获取到Range-Query的所有Key-Value键值。因此，对于B+树的Range-Query操作来说，除了第一次需要从root节点遍历到叶子节点做随机写操作，后继数据读取基本可以看做是顺序IO。

通过比较分形树和B+树的Range-Query实现可以发现， 分形树的Range-Query查询代价明显比B+树代价高，因为分型树需要遍历Root节点的覆盖Range的整颗子树，而B+树只需要一次Seed到Range的起始Key，后续迭代基本等价于顺序IO。

总结

总体来说，分形树是一种写优化的数据结构，它的核心思想是利用节点的MessageBuffer缓存更新操作，充分利用数据局部性原理， 将随机写转换为顺序写，这样极大的提高了随机写的效率。Tokutek研发团队的iiBench测试结果显示： TokuDB的insert操作(随机写)的性能比InnoDB快很多，而Select操作(随机读)的性能低于InnoDB的性能，但是差距较小，同时由于TokuDB采用有4M的大页存储，使得压缩比较高。这也是Percona公司宣称TokuDB更高性能，更低成本的原因。

另外，在线更新表结构(Hot Schema Change)实现也是基于MessageBuffer来实现的， 但和Insert/Delete/Update操作不同的是， 前者的消息下推方式是广播式下推（父节点的一条消息，应用到所有的儿子节点）， 后者的消息下推方式单播式下推（父节点的一条消息，应用到对应键值区间的儿子节点)， 由于实现类似于Insert操作，所以不再展开描述。

TokuDB的多版本并发控制(MVCC)

在传统的关系型数据库（例如Oracle, MySQL, SQLServer）中，事务可以说是研发和讨论最核心内容。而事务最核心的性质就是ACID。

• A表示原子性，也就是组成事务的所有子任务只有两种结果：要么随着事务的提交，所有子任务都成功执行；要么随着事务的回滚，所有子任务都撤销。
• C表示一致性，也就是无论事务提交或者回滚，都不能破坏数据的一致性约束，这些一致性约束包括键值唯一约束、键值关联关系约束等。
• I表示隔离性，隔离性一般是针对多个并发事务而言的，也就是在同一个时间点，t1事务和t2事务读取的数据应该是隔离的，这两个事务就好像进了同一酒店的两间房间一样，各自在各自的房间里面活动，他们相互之间并不能看到各自在干嘛。
• D表示持久性，这个性质保证了一个事务一旦承诺用户成功提交，那么即便是后继数据库进程crash或者操作系统crash，只要磁盘数据没坏，那么下次启动数据库后，这个事务的执行结果仍然可以读取到。

TokuDB目前完全支持事务的ACID。 从实现上看， 由于TokuDB采用的 分形树作为索引，而InnoDB采用B+树作为索引结构，因而TokuDB在事务的实现上和InnoDB有很大不同。

在InnoDB中， 设计了redo和undo两种日志，redo存放页的物理修改日志，用来保证事务的持久性； undo存放事务的逻辑修改日志，它实际存放了一条记录在多个并发事务下的多个版本，用来实现事务的隔离性(MVCC)和回滚操作。由于TokuDB的分形树采用消息传递的方式来做增删改更新操作，一条消息就是事务对该记录修改的一个版本，因此，在TokuDB源码实现中，并没有额外的undo-log的概念和实现，取而代之的是一条记录多条消息的管理机制。虽然一条记录多条消息的方式可以实现事务的MVCC，却无法解决事务回滚的问题，因此TokuDB额外设计了tokudb.rollback这个日志文件来做帮助实现事务回滚。

这里主要分析TokuDB的事务隔离性的实现，也就是常提到的多版本并发控制(MVCC)。

TokuDB的事务表示

在tokudb中， 在用户执行的一个事务，具体到存储引擎层面会被拆开成许多个小事务(这种小事务记为txn)。 例如用户执行这样一个事务：

begin;
insert into hello set id = 1, value = '1'; 
commit;

对应到TokuDB存储引擎的redo-log中的记录为：

xbegin          'b': lsn=236599 xid=15,0 parentxid=0,0 crc=29e4d0a1 len=53
xbegin          'b': lsn=236600 xid=15,1 parentxid=15,0 crc=282cb1a1 len=53
enq_insert      'I': lsn=236601 filenum=13 xid=15,1 key={...} value={...} crc=a42128e5 len=58
xcommit         'C': lsn=236602 xid=15,1 crc=ec9bba3d len=37
xprepare        'P': lsn=236603 xid=15,0 xa_xid={...} crc=db091de4 len=67
xcommit         'C': lsn=236604 xid=15,0 crc=ec997b3d len=37

对应的事务树如下图所示：

对一个较为复杂一点，带有savepoint的事务例子：

begin;
insert into hello set id = 2, value = '2' ;
savepoint mark1;
insert into hello set id = 3, value = '3' ;
savepoint mark2;
commit;

对应的redo-log的记录为：

xbegin           'b': lsn=236669 xid=17,0 parentxid=0,0 crc=c01888a6 len=53
xbegin           'b': lsn=236670 xid=17,1 parentxid=17,0 crc=cf400ba6 len=53
enq_insert       'I': lsn=236671 filenum=13 xid=17,1 key={...} value={...} crc=8ce371e3 len=58
xcommit          'C': lsn=236672 xid=17,1 crc=ec4a923d len=37
xbegin           'b': lsn=236673 xid=17,2 parentxid=17,0 crc=cb7c6fa6 len=53
xbegin           'b': lsn=236674 xid=17,3 parentxid=17,2 crc=c9a4c3a6 len=53
enq_insert       'I': lsn=236675 filenum=13 xid=17,3 key={...} value={...} crc=641148e2 len=58
xcommit          'C': lsn=236676 xid=17,3 crc=ec4e143d len=37
xcommit          'C': lsn=236677 xid=17,2 crc=ec4cf43d len=37
xprepare         'P': lsn=236678 xid=17,0 xa_xid={...} crc=76e302b4 len=67
xcommit          'C': lsn=236679 xid=17,0 crc=ec42b43d len=37

这个事务组成的一棵事务树如下：

在tokudb中，使用{parent_id, child_id}这样一个二元组来记录一个txn和其他txn的依赖关系。这样从根事务到叶子几点的一组标号就可以唯一标示一个txn， 这一组标号列表称之为xids， xids我认为也可以称为事务号。 例如txn3的xids = {17, 2, 3 } , txn2的xids = {17, 2}, txn1的xids= {17, 1}, txn0的xids = {17, 0}。

于是对于事务中的每一个操作(xbegin/xcommit/enq_insert/xprepare)，都有一个xids来标识这个操作所在的事务号。 TokuDB中的每一条消息（insert/delete/update消息）都会携带这样一个xids事务号。这个xids事务号，在TokuDB的实现中扮演这非常重要的角色，与之相关的功能也特别复杂。

事务管理器

事务管理器用来管理TokuDB存储引擎所有事务集合， 它主要维护着这几个信息：

• 活跃事务列表。活跃事务列表只会记录root事务，因为根据root事务其实可以找到整棵事务树的所有child事务。 这个事务列表保存这当前时间点已经开始，但是尚未结束的所有root事务。
• 镜像读事务列表（snapshot read transaction）。
• 活跃事务的引用列表(referenced_xids)。这个概念有点不好理解，假设一个活跃事务开始(xbegin)时间点为begin_id, 提交(xcommit)的时间点为end_id。那么referenced_xids就是维护(begin_id, end_id)这样一个二元组，这个二元组的用处就是可以找到一个事务的整个生命周期的所有活跃事务，用处主要是用来做后文说到的full gc操作。

分形树LeafEntry

上文分形树的树形结构中说到，在做insert/delete/update这样的操作时，会把从root到leaf的所有消息都apply到LeafNode节点中。 为了后面详细描述apply的过程，先介绍下LeafNode的存储结构。

leafNode简单来说，就是由多个leafEntry组成，每个leafEntry就是一个{k, v1, v2, … }这样的键值对， 其中v1, v2 .. 表示一个key对应的值的多个版本。具体到一个key对应得leafEntry的结构详细如下图所示。

由上图看出，一个leafEntry其实就是一个栈， 这个栈底部[0~5]这一段表示已经提交(commited transaction)的事务的Value值。栈的顶部[6~9]这一段表示当前尚未提交的活跃事务(uncommited transaction)。 栈中存放的单个元素为(txid, type, len, data)这样一个四元组，表明了这个事务对应的value取值。更通用一点讲，[0, cxrs-1]这一段栈表示已经提交的事务，本来已经提交的事务不应存在于栈中，但之所以存在，就是因为有其他事务通过snapshot read的方式引用了这些事务，因此，除非所有引用[0, cxrs-1]这段事务的所有事务都提交，否则[0, cxrs-1]这段栈的事务就不会被回收。[cxrs, cxrs+pxrs-1]这一段栈表示当前活跃的尚未提交的事务列表，当这部分事务提交时，cxrs会往后移动，最终到栈顶。

MVCC实现

1）写入操作

这里我们认为写入操作包括三种，分别为insert / delete / commit 三种类型。对于insert和delete这两种类型的写入操作，只需要在LeafEntry的栈顶放置一个元素即可。 如下图所示：

对于commit操作，只需把LeafEntry的栈顶元素放到cxrs这个指针处，然后收缩栈顶指针即可。如下图所示：

2）读取操作

对读取操作而言， 数据库一般支持多个隔离级别。MySQL的InnoDB支持Read UnCommitted(RU)、Read REPEATABLE(RR)、Read Commited(RC)、SERIALIZABLE(S)。其中RU存在脏读的情况(脏读指读取到未提交的事务)， RC/RR/RU存在幻读的情况（幻读一般指一个事务在更新时可能会更新到其他事务已经提交的记录）。

TokuDB同样支持上述4中隔离级别， 在源码实现时, ft-index将事务的读取操作按照事务隔离级别分成3类:

• TXN_SNAPSHOT_NONE : 这类不需要snapshot read， SERIALIZABLE和Read Uncommited两个隔离级别属于这一类。
• TXN_SNAPSHOT_ROOT : Read REPEATABLE隔离级别属于这类。在这种其情况下， 说明事务只需要读取到root事务对应的xid之前已经提交的记录即可。
• TXN_SNAPSHOT_CHILD: READ COMMITTED属于这类。在这种情况下，儿子事务A需要根据自己事务的xid来找到snapshot读的版本，因为在这个事务A开启时，可能有其他事务B做了更新，并提交，那么事务A必须读取B更新之后的结果。

多版本记录回收

随着时间的推移，越来越多的老事务被提交，新事务开始执行。 在分形树中的LeafNode中commited的事务数量会越来越多，假设不想方设法把这些过期的事务记录清理掉的话，会造成BasementNode节点占用大量空间，也会造成TokuDB的数据文件存放大量无用的数据。 在TokuDB中， 清理这些过期事务的操作称之为垃圾回收（Garbage Collection）。 其实InnoDB也存在过期事务回收这么一个过程，InnoDB的同一个Key的多个版本的Value存放在undo log 页上， 当事务过期时， 后台有一个purge线程专门来复杂清理这些过期的事务，从而腾出undo log页给后面的事务使用， 这样可以控制undo log无限增长。

TokuDB存储引擎中没有类似于InnoDB的purge线程来负责清理过期事务，因为过期事务的清理都是在执行更新操作是顺便GC的。 也就是在Insert/Delete/Update这些操作执行时，都会判断以下当前的LeafEntry是否满足GC的条件， 若满足GC条件时，就删除LeafEntry中过期的事务， 重新整理LeafEntry 的内存空间。按照TokuDB源码的实现，GC分为两种类型：

• Simple GC：在每次apply 消息到leafentry 时， 都会携带一个gc_info， 这个gc_info 中包含了oldest_referenced_xid这个字段。 那么simple_gc的意思是什么呢？ simple_gc就是做一次简单的GC， 直接把commited的事务列表清理掉（记住要剩下一个commit事务的记录， 否则下次查找这条commited的记录怎么找的到？ ）。这就是simple_gc， 简单暴力高效。
• Full GC：full gc的触发条件和gc流程都比较复杂， 根本意图都是要清理掉过期的已经提交的事务。这里不再展开。

总结

本文大致介绍了TokuDB事务的隔离性实现原理， 包括TokuDB的事务表示、分形树的LeafEntry的结构、MVCC的实现流程、多版本记录回收方式这些方面的内容。 TokuDB之所有没有undo log，就是因为分形树中的更新消息本身就记录了事务的记录版本。另外， TokuDB的过期事务回收也不需要像InnoDB那样专门开启一个后台线程异步回收，而是才用在更新操作执行的过程中分摊回收。总之，由于TokuDB基于分形树之上实现事务，因而各方面的思路都有大的差异，这也是TokuDB团队的创新吧。

参考资料：

• http://docs.tokutek.com/tokudb/tokudb-index-using-tokudb.html
• http://openinx.github.io/2015/12/13/ft-mvcc/
• http://openinx.github.io/2015/11/25/ft-index-implement/
• https://highdb.com/tokudb-%E7%89%B9%E6%80%A7%E6%A6%82%E8%A7%88/

The post MySQL 高性能存储引擎：TokuDB初探 appeared first on 标点符.

SILY系列文章第52期：MVP 必须向用户提供价值，换句话说，也就是验证问题是否真的存在，解决方案是否真的带来了改善。

精益创业中强调要使用 MVP 来验证问题确实存在，而 MVP 其实是最多被误解的一个定义。究竟什么是 MVP？MVP 和 高保真原型的区别是什么？

@jopas，画了一张非常棒的图表，让 MVP 的概念瞬间清晰：

MVP 在创业过程中的作用，可以通过 Henrik Kniberg 画的滑板车形象的理解：

MVP 是最小可用的产品，它必须向用户提供价值，换句话说，也就是验证问题是否真的存在，解决方案是否真的带来了改善。它不是一个粗糙的demo，也不是漂亮的原型，它必须直面问题给一个基本可用的解答。

正如滑板车的例子，用户必须真实的在使用你的产品，并给予反馈。每一次迭代针对一个具体真实的问题，每一次迭代都是寻找问题的最小代价解的过程。

最近好多原型设计工具得到运用，甚至有人可以制作复杂的以假乱真的原型，通过原型来做设计迭代。这里的坑是，原型无论如何的逼真，并不是真实可工作的产品，它在运行中缺少真实的数据和功能，把玩原型的过程也缺少真实使用的上下文，无法给予方案足够客观的评价。

不定期聊一些产品设计，以及有趣话题，分享我的所见所想，欢迎关注。

• 微信公共号 - 「明学的白板」
• 我的个人Blog - http://ksmx.me
• Medium - https://medium.com/@wxiluo
• Twitter - https://twitter.com/wxiluo@gmail.com
• 新浪微博 - http://weibo.com/wxiluo

Stuff I Learned Yesterday系列文章话题包括科技、产品、设计、商业和创业有关的事。