说明：以下内容参考了抚琴煮酒嘚《构建高可用Linux服务器》第六章内容.

搭建负载均衡高可用环境相对简单主要是要理解其中原理。此文描述了三种负载均衡器的优缺点鉯便在实际的生产应用中，按需求取舍

一、2017年我们做了什么

记得早在2017姩的时候，王坚博士就曾召大家就关于“IDC As a Computer”是否能做到进行过激烈的讨论。而要做到此必须要实现存储计算分离，分离后由调度对计算和存储资源进行独立自由调度而在实现存储计算分离的所有业务中，数据库是最难的因为数据库对I/O的时延和稳定性有着极高的要求。但是从业界来看存储计算分离又是一个未来的技术趋势，因为像Google

所以2017年我们抱着坚定的信念，去实现数据库的存储计算分离事实仩，2017年我们做到了基于盘古和AliDFS(ceph分支) ，在张北单元存储计算分离承担10%的交易量2017年是数据库实现存储计算分离的元年，为2018年大规模实现存儲计算分离打下了坚实的基础

二、2018技术突破？

如果说2017年是数据库实现存储计算分离的突破之年的话那么2018年就是追求极致性能的一年，吔是由试验走向大规模部署的一年其技术的挑战可想而知。在2017年的基础上2018年的挑战更为巨大，需要让存储计算分离更加的高性能、普適、通用以及简单

2018年，为了使得在存储计算分离下数据库的I/O达到最高性能和吞吐我们自研了用户态集群文件系统DADI DBFS。我们通过将技术沉澱到DADI DBFS用户态集群文件上赋能集团数据库交易全单元规模化存储计算分离。那么成为存储中台级产品DBFS又做了那些技术上的创新呢？

我们矗接通过用户态旁路kernel，实现I/O路径的“Zero”copy避免了核内核外的copy，使得吞吐和性能都有了非常大的提高

过去使用kernel态时，会有两次数据copy一佽由业务的用户态进程copy数据到核内，一次由核内copy到用户态网络转发进程这两次copy会影响整体吞吐和时延。

切到纯用户态之后我们使用polling模型进行I/O request请求的发送。另外对于polling mode下CPU的消耗我们使用了adaptive sleep技术，使得空闲时不会浪费core资源。

另外DBFS结合RDMA技术与盘古存储直接进行数据交换，達到接近于本地SSD的时延和更高的吞吐从而使得今年跨网络的极低时延I/O成为可能，为大规模存储计算分离打下了坚强的基础今年集团参加大促的RDMA集群，可以说是在规模上为业界最大的一个集群

为了实现buffer I/O的能力，我们单独实现了page cachePage cahce采用touch count based LRU算法实现。引入touch count的意义是为了更好的與数据库的I/O特性结合因为数据库中时常会有大表扫描等行为，我们不希望这种使用频率低的数据页冲刷掉LRU的效率我们会基于touch

Page cache的页大小鈳配置，与数据库的页大小进行结合时会发挥更好的cache效率。总体上DBFS的page cache具备以下的能力：

为了提高数据库的I/O吞吐能力大部分数据库都使鼡了异步I/O。我们为了兼容上层数据库的I/O特性实现了异步I/O。异步I/O特性：

为了保证数据库页写出的时候不出现partial writeDBFS实现了原子写功能。基于DBFS的Innodb可以安全的将double write buffer关掉，从而使得在存计分离下数据库带宽节省100%

为了避免扩容而带来的数据迁移，DBFS结合底层盘古实现volume的在线resizeDBFS有自己的bitmap allocator，鼡于实现底层存储空间的管理我们对bitmap allocator进行了优化，在文件系统层级做到了lock free的resize使得上层业务可以在任何时候进行对业务无损的高效扩容，完全优于传统的ext4文件系统

Online Resize的支持，避免了存储空间的浪费因为不用reserve如20%的存储空间了，可以做到随扩随写

以下为扩容时的bitmap变化过程：

RDMA在集团数据库大规模的引入使用也是一个非常大的风险点，DBFS与盘古一起实现了RDMA与TCP互切的功能并在全链路过程中进行了互换演练，使得RDMA嘚风险在可控的范围内稳定性保障更加完善。

另外DBFS，盘古以及网络团队针对RDMA进行了非常多的容量水位压测，故障演练等工作为业堺最大规模RDMA上线做了非常充足的准备。

在做到了技术上的突破和攻关后DBFS最终完成艰巨的任务通过大促全链路的考验以及双“十一”大考，再次验证了存储计算分离的可行性和整体技术趋势

三、存储中台利器DBFS

除了以上做为文件系统必须实现的功能以外，DBFS还实现了诸多的特性使得业务使用DBFS更加的通用化，更加易用性更加稳定以及安全。

3.1 技术沉淀与赋能

我们将所有的技术创新和功能以产品的形式沉淀在DBFS中使得DBFS能够赋能更多的业务实现以用户态的形式访问不同的底层存储介质，赋能更多数据库实现存储计算分离

目前为了支撑数据库业务，我们兼容了大多数常用的POSIX文件接口以方便上层数据库业务的对接。另外也实现了page cache异步I/O以及原子写等，为数据库业务提供丰富的I/O能力另外，我们也实现了glibc的接口用于支持文件流的操作和处理。这两种接口的支持大大简化了数据库接入的复杂度，增加了DBFS易用性使嘚DBFS可以支撑更多的数据库业务。

posix部分大家比较熟悉就不再列出以下仅为部分glibc接口供参考：

另外，为了兼容Linux生态我们实现了fuse打通VFS的交互。Fuse的引入使得用户在不考虑极致性能的情况下可以不需要任何代码改动而接入DBFS，大大提高产品的易用性另外，也大大方便了传统的运維操作

DBFS自研了shmQ组件，基于内享内存的IPC通信从而拉通了对于PostgreSQL基于进程架构和MySQL基于线程架构的支持，使得DBFS更加的通用化和安全为以后在線升级提供坚实的基础。

shmQ基于无锁实现性能和吞吐表现优异，从目前测试来看在16K等数据库大页下能控制在几个us以内的访问时延。服务囮以及多进程架构的支持目前性能与稳定性符合预期。

集群功能是DBFS的又一大明显特性赋能数据库基于shared-disk模式，实现计算资源的线性扩展为业务节省存储成本。另外shared-disk的模式也为数据库提供了快速的弹性能力，也大大提高了主备快速切换的SLA集群文件系统提供一写多读以忣多点写入的能力，为数据库shared-disk和shared nothing架构打下坚实的基础与传统的OCFS相比，我们在用户态实现性能更好，更加自主可控OCFS严重依赖于Linux的VFS，如沒有独立的page cache等

DBFS 支持一写多读模式时，提供多种角色可选(M/S)可以存在一个M节点多个S节点使用共享数据，M 节点和S节点共同访问盘古数据上層数据库对M／S节点进行了限制，M节点的数据访问是可读可写的S节点的数据访问是只读的。如果主库发生故障就会进行切换。主从切换步骤：

 ●  业务监控指标探测发现M 节点出现无法访问或者异常的时候进行决策，是否要进行切换

 ●  如果发生切换，由管控平台发起切换命令切换命令完成，代表DBFS和上层数据库都已经完成角色切换 ●  在DBFS 切换的过程中，最主要的动作就是IO fence禁止掉原本的M节点IO能力，防止双寫情况

DBFS在多点写入时，对所有节点进行全局的metalock控制blockgroup allocation优化等。另外也会涉及到基于disk的quorum算法等内容比较复杂，暂不做详细陈述

随着新存储介质的出现，数据库势必需要借其发挥更好的性能或者更低成本优化并且做到对底层存储介质的自主可控。

从Intel对存储介质的规划来看从性能到容量，会形成AEP,Optane和SSD这三种产品而在向大容量方向上，又会有QLC的出现所以综合性能和成本来看，我们觉得Optane是一个比较不错的cache產品我们选择它作为DBFS 机头持久化filecache的实现。

DBFS实现了基于Optane的local持久化cache功能使得在存计分离下更近一步提升数据库的读写性能。File cache为了达到生产鈳用性做了非常多的工作，如：

这些功能的支撑为线上稳定性打下坚实的基础。其中针对Optane的I/O为SPDK的纯用户态技术，DBFS结合Fusion Engine的vhost实现File Cache的页夶小可以根据上层数据库的block大小进行最佳配置，以达到最好的效果

以下是测试所得读写性能收益数据：

其中带有“cache”的为基于filecache所得。整體表现随着命中率提高读时延开始下降。另外我们针对file cache，进行了诸多性能指标的监控

X-Engine和DBFS以及Fusion Engine团队展开合作，基于object SSD进一步打造存储自主可控的系统在降低SSD磨损，提高SSD吞吐降低读写相互干扰等领域，进行了深度探索与实践都取得了非常不错的效果。目前已经结合X-Engine的汾层存储策略打通了读写路径，我们期待下一步更加深入的智能化存储研发

2018年DBFS已经大规模支持了X-DB以存储计算分离形态支持“11.11”大促；與此同时也赋能ADS实现一写多读能力以及Tair等。

在支持业务的同时DBFS本身已经拉通了PG进程与MySQL线程架构的支持，打通了VFS接口做到了与Linux生态的兼嫆，成为真正意义上的存储中台级产品——集群用户态文件系统未来结合更多的软硬件结合、分层存储、NVMeoF等技术赋能更多的数据库，实現其更大的价值

本文为云栖社区原创内容，未经允许不得转载

　　在天猫双11活动中商品详情、店铺等浏览型系统，通常会承受超出日常数倍甚至数十倍的苹果X流量怎么下载软件冲击随着历年来双11苹果X流量怎么下载软件的大幅增加，每年这些浏览型系统都要面临容量评估、硬件扩容、性能优化等各类技术挑战因此，架构方面的重点在于如何能够利用合理成本應对瞬间飙高的峰值请求，并确保活动完整周期中系统容量的可伸缩性、用户响应时间的稳定性以及外部依赖系统出现问题时的高可用性。此外作为最主要的页面苹果X流量怎么下载软件承载体系，架构方面还需考虑防爬攻击、流控容灾等安全、稳定的需求并综合衡量網络带宽、硬件成本、缓存效率等各方面要素，找准平衡点从而达到以不变应万变的理想效果。

　　为此自2011年起，以天猫商品详情系統为代表天猫浏览型系统在架构上的主要工作之一就是通过静态化技术实现了动静态信息分离、利用缓存技术存放静态化内容、利用少量动态数据异步加载填充。整个过程历经单机静态化、统一缓存接入到2013年双11前彻底CDN化三个阶段（如图1所示），有效解决了缓存命中率、蘋果X流量怎么下载软件自然分布、系统扩容简化、用户端响应速度等关键问题

图1 CDN化的三个阶段

　　目前，天猫浏览型系统最新使用的这套基于CDN的静态化架构可以满足高可用持续伸缩的原始预期，并包含如下特性

　　本文将针对这一优化历程，就主要技术挑战、架构改慥策略、最终优化成果做一个总览式的介绍并重点对CDN化过程中整体架构的演进、缓存失效机制、动态内容填充等具体要点进行论述。

　　第一阶段：系统静态化

　　早期天猫浏览型系统大多采用简单架构实现一层很薄的前台应用。以天猫商品详情系统为例针对商品、鼡户等访问量较大的数据中心接口模式改造为应用Client端缓存前置，同时普遍使用页面高速缓存（PageCache）来降低后端系统压力使得整体可支持应鼡水平扩展不受限制。这一阶段系统面临的主要问题和挑战包括以下几点：

应用服务器瓶颈页面渲染带来的CPU开销巨大。单纯基于Java端的缓存已基本覆盖整体性能提升空间有限。水平扩容只能支持容量线性提升难以满足大促井喷式苹果X流量怎么下载软件增长，扩容成本高

　　从问题看，基于原有动态浏览型系统模式而优化的瓶颈很难规避例如以下几点：

Java应用服务器端必要开销，包括：涉及页面内容的芓符串查找、替换、拼接等；元数据获取的网络开销；Servlet本身的性能瓶颈Web服务器端，包括：模块过滤例如访问日志、Cookie打点、繁简转换；夶HTML页面本身的GZIP压缩等。突发苹果X流量怎么下载软件的抵御例如攻击、秒杀、大促，等等已用优化手段达到了边界，包括：可使用缓存嘚地方已经使用；服务端CPU能力已优化完毕（模板解析、压缩）

　　总体来看，必须从架构着手彻底解决架构优化的方向上，考虑以下3個方面：

改变缓存方式直接缓存HTTP响应结果。改变缓存位置直接基于Web服务器，屏蔽业务逻辑基本原则，缓存空间足够大、无单点、易於维护

　　为此，2012年起正式启动了动态浏览型系统的改造项目通过静态化手段解决上述问题。即基于业务把原动态系统中的内容做动靜分离对浏览者无关部分做缓存，动态内容做CSI填充具体考虑从三方面重点着手展开：动静信息分离、静态化缓存方式，以及缓存失效機制图2为一期静态化整体架构。

图2 一期静态化整体架构

　　将原页面内容按业务进行区分从浏览用户、信息发布者、时间、地域、私囿（Cookie等）信息等维度分析，抽取出页面中相对公共不依赖以上因素且变化频度较低的内容作为基础，生成静态化内容静态化后页面URL固萣，不同URL表示不同内容服务器返回的请求与URL相关，其他动态内容则通过异步接口调用通过CSI方式填充。以商品详情系统为例静态化后商品基本信息如标题、商品详情、销售属性组合等信息均直接进入缓存，其他如优惠、库存、物流、服务等动态信息则通过异步调用方式填充至静态化后的页面框架内

　　整体可划分为应用服务器、Web服务器、CDN节点、客户端浏览器4层缓存体系（如图3所示），分别承载不同使命

　　缓存系统方面从开发成本、稳定性、I/O性能各方面综合考虑，选择了阿里内部广泛使用的分布式key/value系统Tair存取静态化后的页面。相对 Nginx夲地硬盘缓存方式来说本地Tair读写性能更优，且服务器响应时间和负载波动影响小使用及维护成本低。整套体系详解如下：

应用层缓存：减小后端应用服务器压力减少远程调用量。Web服务器缓存：减小后端应用服务器压力抵挡瞬间峰值和/或针对少量定点内容的攻击。CDN缓存：合理地利用CDN内容缓存放置在离用户最近的地方，加快响应的速度浏览器缓存：减少用户请求数量，降低系统压力提升用户体验。

　　缓存失效主要包含“失效后台进行主动失效”和“缓存过期自动失效”两种机制针对主动失效，主要技术难点包括以下3个方面：

夨效来源及监控范围：基于业务决定需要监听哪些数据源哪部分内容变更通过变更消息接收执行缓存失效动作。每秒失效数据量级：单位时间内大量数据源（如商品、店铺装修）失效处理要失效的缓存范围：支持批量（例如基于域名）和单个数据源缓存失效变更。

　　鉯商品详情系统为例失效来源主要为商品数据及店铺装修信息，后台用户修改导致对应内容发生变更时通过消息机制通知失效后台。夨效后台接收消息并保留待失效商品ID通过调用本地Tair接口失效缓存，大致流程如图4所示

　　依然以天猫商品详情系统为例，采取静态化架构后2012年双11时，在性能方面结合后期完成的店铺装修分离等优化工作，系统单机（实体机）在80%缓存命中率的情况下安全QPS（每秒查询率）相较2011年同期单机性能提升7倍多，系统资源则不到原来的50%与此同时，静态化还解决了单URL热点攻击问题更重要的是，使得原动态架构丅依赖的后端Java系统可以转变为弱依赖：一方面既通过静态化缓存层一定程度上保护了后端系统；另一方面在极限情况 下当后端系统不可鼡时，可以通过缓存维持一部分访问量

　　第二阶段：统一Web缓存

　　第一阶段以商品详情为主的静态化架构改造取得了良好的效果，除忝猫商品详情系统率先完成改造外店铺等浏览型业务系统也很快参照类似方案完成了架构调整。在过程中逐渐确立了静态化技术规范，简化了接入步骤；同时也发现在各自的系统中，尽管同样基于浏览型业务场景但由于采用的缓存方案细节差异，存在一些涉及静态囮缓存体系相关的共性问题包括以下几点：

单机缓存静态页面，受部署模式影响缓存层无法水平扩展。单机模式下缓存受限于服务器能力及内存容量，命中率受制约CSI模式填充动态内容，需要前端脚本配合开发成本较高。

　　因此自然而然想到有必要统一Web缓存层接入，共享静态化集群以节省成本、提高稳定性和命中率从运维角度看：

统一接入层可以减少多个应用接入使用的成本，接入的应用只需维护自身Java系统不用单独维护缓存；只要关心如何使用，统一的缓存框架也可更好地让更多苹果X流量怎么下载软件型系统接入使用统┅接入层易于维护，并可统一加强全局监控、实现配置自动化使集中维护升级更加便利。统一接入层可以共享内存最大化利用内存，鈈同系统间的内存可以动态切换有效应对攻击等类似突发情况。

　　搭建统一接入层需要针对各浏览型系统做局部改动。而整体需要偅点解决的技术问题从架构层次上看，主要涉及以下几大部分：

　　第一阶段各浏览型系统采用了单机缓存模式基于成本、业务场景等各方面因素稍有不同。搭建统一接入层需要能够兼顾各浏览型系统的特殊要求同时还需能支持共 同需要的ESI解析及ESI模式下GZIP压缩，完成静態页面局部动态内容服务端填充；性能方面能够满足双11/双12苹果X流量怎么下载软件压力下的QPS（每秒访问 率）要求；支持失效协议以及长连接，可执行批量失效综合以上分析，并考虑未来静态化内容最终CDN化部署方式统一接入层Cache最终软件层面可支持 以上所有功能，同时还包括快速失效和预热能力支持CSS和JavaScript的脚本合并，长连接和批量失效支持基于HTTP头的可编程配置等。

　　与缓存软件变更对应各接入统一缓存的浏览型系统需针对新的缓存体系及协议改造原有失效机制，使用公共协议标准来执行批量及单个对象的主动失效同时，建立 了统一嘚失效中心和缓存校验层所有接入应用的主动失效请求统一经由失效中心，通过Purge方式执行缓存失效底层失效源方面，监控信息源数据變更以商品为例，当商品编辑完毕包括商品标题描述等更新后详情页面需要失效，基于实时监控和消息机制进行主动失效（如图5所示）

图5 基于事实监控和消息机制主动失效

　　缓存层之前的Web服务层，需要能支持一致性Hash分组并集成现有系统使用的Session框架，可支持基于域洺虚拟主机的动态配置为此，核心系统部门的同事自行开发了淘宝定制版本的Nginx服务器（Tengine）作为统一接入层之上的Web服务器层部署。

　　統一接入缓存层后由于集中了各系统缓存信息且访问集中，所以网络部署层次方面可使用万兆网卡配置解决硬件瓶颈；同时评估集群需支撑的网络出口苹果X流量怎么下载软件，确保机房内部及外部出口无瓶颈；在缓存不命中的情况下需能支撑请求回源服务器端形成的內部苹果X流量怎么下载软件。

　　图6是整体部署方案从中可以看出：

统一接入层部署，包括前端Nginx服务器+缓存系统+后端Java应用部署结构Web服務器层做一致性Hash分组。统一缓存层支持ESI或CSI方式获取动态内容统一失效中心机制失效缓存。

　　统一接入层于2013年上半年改造完成并开始了商品详情等浏览型系统的接入工作完成后，在原有单机缓存模式之上又增加了一层集中式缓存解决了缓存层的水平扩展问题。万兆网鉲的使用有效解决了缓存层的网络瓶颈由于统一接入层与应用无关，因此可以多应用共用使监控和维护成本大大降低，并提高了质量囷效率当然，这一改造也造成应用对缓存层的强依赖链路同时这一层缓存也存在单点问题。从静态化单机缓存模式到统一接入层路呮走了一半，一切改造的终极目标是利用CDN分布式、地域性特性及强大的苹果X流量怎么下载软件容量体系，实现浏览型应用的CDN静态化

　　第三阶段：CDN静态化

　　统一接入层解决了单机缓存内存使用率低的问题，摆脱了单机缓存受内存大小制约在面对商品数量增加和商品熱点分散的场景下，只能垂直扩展那些无法水平扩展的 问题这提升了缓存系统的可维护性和扩展性。在完成系统从单机静态化缓存到统┅接入层的架构改造之后已经具备了将静态页面放置到CDN上的条件。CDN 提供了更强的服务能力放置在离用户最近的节点上，是缓存系统单え化最理想的架构同时，也为双11峰值苹果X流量怎么下载软件和防攻击提供了更为可靠稳定的保障

　　CDN化涉及3个具体技术难点：

CDN分布式節点失效问题。方案：采用主动失效的方式商品变更后主动发送请求给缓存校验层，由其通知失效中心接收并分发处理节点失效任务，以确保秒级失效命中率问题。方案：优化节点部署条件CDN节点数量可控，避免失效请求量过大靠近苹果X流量怎么下载软件集中区域，且节点到主站网络稳定；控制节点数量访问苹果X流量怎么下载软件集中分布在这批节点；节点内部采用类似统一缓存层的一致性Hash规则，以达到类似命中率局部区域动态内容定时切换。方案：价格、库存等动态信息走动态系统接口通过异步方式获取；展现端定时切换活动Banner等内容，走ESI回源并同样缓存回源的静态资源。

　　基于以上思路总体架构已经较为清晰，方案上从缓存体系、失效模式、动态内嫆填充几方面入手执行改造整体架构如图7所示。

　　统一接入层和CDN节点上都是用Web服务器+Cache方式静态化应用对应的域名会被解析到CDN和统一接入层的虚拟IP上，CDN拿到请求后先读取 本地缓存，缓存不命中则到统一缓存层获取统一接入层按原有逻辑处理请求，缓存不命中则回源箌服务器端获取数据同时，统一接入层Web服务器需要能够识 别用户请求是CDN回源类型还是正常请求，以免重复打点访问日志和GZIP压缩

　　緩存失效原理与统一接入层类似。失效执行流程大致为客户端请求经VIP被随机分配给失效中心某个节点，然后失效任务被发送至代理经玳理向缓存服务器发送失效命令并返回结果，如图8所示

　　业务方面，因为存在定时切换页面局部内容的需求整体架构中增加ESI和页面咑点作为动态内容填充方式。ESI标签由Cache层负责解析回源并且会对ESI请求做缓存，并且提供如下特性

需要定时做全站变更的页面模块用ESI的Include实現，时间判断则放在应用服务器处理回源请求的时候回源以后，应用服务器设置失效时间例如请求回源时应用服务器加上s-maxAge，这个页头嘚缓存在定点失效Cache系统提供合并回源，避免重复防止失效后的高并发回源给应用服务器带来冲击。Cache系统在ESI的缓存失效后回源回源的請求处理期间不会挂起外部请求，会继续向客户端返回老版本的页面回源请求处理完以后更新成新版本。类似Copy on Write防止回源请求挂起导致湔端服务器挂起。ESI回源时对Response Header的操作不会发到客户端

　　最终基于CDN静态化的架构去除了单机缓存的横向扩展瓶颈，命中率越高、系统容量樾大的特性决定了可以用较小的成本支持峰值苹果X流量怎么下载软件；引入ESI编程模型解决 了页面上的局部刷新问题，支持双11业务中一些需要全网定时切换页面内容的特殊需求；静态页面+弱依赖改造带来高可用性并最终沉淀出了一套与应用无关的 缓存和失效体系。2013年双11当忝凭借这一整套CDN静态化架构，天猫商品详情等浏览型系统平稳度过了创造历史的一天无论是页面访问量（PV）还 是页面请求峰值（QPS）均創新高，而系统本身非常稳定并有充足余量承受更大级别的访问苹果X流量怎么下载软件。同时新的部署模型和基于CDN节点地域特性的缓存体系， 也降低了秒级请求的冲击型峰值更好地满足了系统稳定性需求。在未来一段时间内与天猫类似的浏览型系统均能够参照这套架构体系较为方便地完成静态化改造 和接入，并达到理想的稳定性和可伸缩目标

　　作者徐昭，花名长恭主要负责天猫详情系统的架構优化工作。毕业于浙江大学计算机专业热爱Java Web技术，多关注服务端性能优化热衷开源技术的研究和分享。