tair内存服务器_tair缓存

文章目录：

• 1、如何用硬件加速技术为CPU减负
• 2、.Net的Cache和Memcached有什么优缺点？
• 3、分布式站点怎么解决session
• 4、怎么搭建一个tair缓存服务器
• 5、delphi 分布式架构怎么学
• 6、淘宝tair 为什么不用redis

如何用硬件加速技术为CPU减负

如何用硬件加速技术为CPU减负

一、背景介绍

通用处理器（CPU）的摩尔定律已入暮年，而机器学习和Web服务的规模却在指数级增长。伴随着当今硬件技术的成熟发展，普通CPU无论是在计算能力，还是资源成本上相对于一些专用硬件已经没有绝对优势，这也促使硬件加速技术得到各大公司的青睐，譬如三大互联网巨头百度、阿里、腾讯内部的接入层采用类似KeyLess方案来加速HTTPS的卸载，不仅提高了用户体验，还节省了机器成本。根据当前调研结果发现：目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白，阿里接入层首次结合硬件加速技术卸载Gzip不仅带来了性能提升，而且对业界在此领域的发展也有重大影响意义。

接入层Tengine当前性能瓶颈是CPU，譬如Gzip模块在Tengine中CPU占比高达15%-20%左右，相比于其它模块CPU消耗高、占比呈增长趋势（后端应用压缩逻辑后续统一前置接入层）、且集中，所以Gzip模块使用硬件卸载对于性能提升、成本优化是不可或缺。

二、分析与调研

分析前先简单介绍下什么是硬件加速： 硬件加速（HardwareAcceleration）就是利用硬件模块来替代软件算法以充分利用硬件所固有的快速特性（硬件加速通常比软件算法的效率要高），从而达到性能提升、成本优化目的，当前主要是如下两大加速方式：

FPGA 现场可编程门阵列，可针对某个具体的软件算法进行定制化编程，譬如业内的智能网卡；

ASIC 专用集成电路，它是面向专门用途的电路、专门为一个用户设计和制造的，譬如Intel的QAT卡仅支持特定加减密、压缩算法；

FPGA与ASIC的对比如下表格所示：

2.1、接入层Tengine CPU消耗分析

主站接入层承载集团90%以上的入口流量，看似只是作为一个七层流量转发网关，但是却做了非常之多的事情，譬如https卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等，这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多，所以这就导致Tengine的CPU消耗比较分散，其主流程处理如下图所示：

各模块CPU消耗占比Top 5如下表格所示：

就当前接入层流量模型分析来看，Gzip单个模块CPU消耗占比达到15%-20%左右（注：主要是压缩消耗）且占比呈上升趋势，所以对Gzip使用硬件卸载迫在眉睫。

2.2、加速方案调研

2.2.1、Intel QAT卡

QAT(Quick Assist Technology)是Intel公司推出的一种专用硬件加速卡，不仅对SSL非对称加解密算法（RSA、ECDH、ECDSA、DH、DSA等）具有加速，而且对数据的压缩与解压也具有加速效果；

QAT加速卡提供zlib压缩算法、且zlib shim对其原生zlib与QAT之间做了适配，调用方式和zlib库方式基本一致，需在上层业务中开启zlib QAT模式、相对来说对上层业务改造较少。

2.2.2、智能网卡

INIC（Intelligent Network Interface Card）是网络研发事业部自研产品，以网络处理器为核心的高性能网络接入卡，对于网络报文数据的处理非常合适，针对Tengine的gzip卸载有如下两种方案：

a. 提供压缩API给host，把压缩数据返回host，由host封包发送；

b. host和网卡约定压缩flag，host发送未压缩报文，智能网卡收到后进行压缩，并且重新封包发送；

2.2.3、FPGA卡

FPGA（Field-Programmable Gate Array）现场可编程门阵列，需要对接入层使用的zlib算法使用硬件语言重新开发、进行电路烧写，且上层交互驱动也需要从零开发；

方案对比

智能网卡的方案1相比于QAT对zlib处理没有性能上的优势，智能网卡只是对zlib进行软件卸载、相对于QAT并不具有加速作用；其方案2需要把Tengine一部分业务逻辑抽取到网卡中做：如spdy、http2、chunked、ssl对称加密、响应body限速等逻辑，其成本及风险高，方案3的FPGA方式相对来说开发成本较高、且相关资源匮乏。

综上所述最终采用QAT加速卡对接入层Tengine的Gzip进行卸载、加速。

三、方案实施

QAT驱动采用UIO（UserspaceI/O）技术，其大部分处于用户态、只有少部分处理硬件中断应答等逻辑处于内核态，这样不仅方便用户调试，而且还解决了内核不支持浮点数运算的问题。当然QAT加速卡也顺应了Docker虚拟化的潮流，其采用SRIOV技术，可以在虚拟机之间高效共享PCIe（Peripheral Component Interconnect Express）设备，当前DH895XCC系列芯片最高可支持32个虚拟机共享QAT，从而达到充分利用硬件资源。其次QAT属于ASIC模式相比于FPGA具有更好的加速效果，主要原因是由于FPGA为了可重构，导致其逻辑查找表、触发器众多以及相同逻辑电路在布线上延时变大。

接入层Tengine目前采用的是下图左边的实线加速链路，其中Zlib Shim、QAT User Space Api、QAT Driver作为Tengine Gzip与底层硬件QAT的通信适配层，此方式对上层业务入侵较小、其软件架构如下图所示：

虽然该方案看起来比较简单，但是真正线上实施的时候还是遇到了非常多的问题（功能、性能方面），譬如：

3.1、架构不合理

a. 使用的第一版驱动Intel-Qat2.6.0-60，当QPS为1k左右时CPU很快打满（注：正常情况下QPS为1k时，CPU消耗6%左右），且CPU消耗中90%以上都是消耗在内核态，如下图所示：

使用strace进行相关系统热点函数统计发现，其CPU主要消耗在ioctl系统函数上，如下所示：

通过perf查看ioctl主要是执行内存分配命令，由于Zlib Shim需要开辟连续的物理内存、所以出现频繁调用 compact_zone进行内碎片整理，其调用热的高达88.096%，如下图所示（注：热度表示该函数该函数自身的热度、调出： 表示被调用函数的热度总和、总体： 热度 + 调出）：

同Intel研发联调讨论后发现是由于当前Intel QAT的Zlib Shim的模型不合理所导致，通过推动其改造采用OOT的内存管理模块USDM（内部维护一个HugePage内存池）方案解决。

b. 使用上述问题解决后的驱动intel-qatOOT31092，测试后发现CPU节省效果不佳（用户态CPU减少、但是增加了内核态的CPU），经分析、发现使用QAT加速后，部分系统函数CPU占比变高，如 open、ioctl、futex，如下图所示（注：左边的是使用QAT后各系统热点函数），使用QAT后open、ioctl、futex执行时间占比高达8.95（注：3.91 + 2.68 + 2.36），而未使用版本对应占比时间才0.44（注：0.24 + 0.14 + 0.06）；

分析其Tengine的worker进程堆栈信息发现open、ioctl都是成对出现（即一次http请求出现4次该系统调用），该现象反馈给Intel的研发同学后得知是由于新驱动的Zlib Shim导致，通过优化改造后open、ioctl调用频率明显减少。但是其futex系统调用频度却没有减少，还是导致内核态的CPU占比较高，通过strace跟踪发现一个http压缩请求后会多次调用futex、如下图所示，同Intel研发同学了解到Zlib Shim采用多线程方式，其futex操作来自zlib shim等待QAT压缩或解压缩数据返回的逻辑。

由于Tengine是多进程单线程、采用epoll异步IO事件模式，联调Intel的研发同学对Zlib Shim进行改造（去线程），最终futex系统调用也明显减少。

通过分析并推动Intel对QAT进行多次架构上的改造，才使得QAT的加速特性更好的发挥。

3.2、功能不完善

a. 使用QAT后执行reload，可能导致请求响应异常，如下所示：

由于每个worker进程都需要分配一个QAT Instance用于数据解压缩，Tengine在reload的瞬间worker进程数可能会翻倍、而QAT Instance初始版本只有64个、所以新启动的worker进程可能分配不到Instance、导致请求失败。

针对此问题Intel提供的新版本QAT，其Instance数量从64提高到256个避免此问题的发生，同时我们提出容灾保护方案：当Instance无法分配了需要自动降级为软件压缩，提高其可用性。

b. Zlib Shim huge page内存泄漏，导致QAT驱动core dump：

Tengine使用内存池模式进行内存的管理，即调用(In)DeflateInit分配的空间无需调用(In)DeflateEnd处理、在请求结束的时候会调用请求r相关的释放操作，进行内存的归还，但是由于Zlib Shim使用的huge page必须调用(In)DeflateEnd才释放给USDM，通过改造Tengine Gzip相关代码后，该问题得以解决，而QAT驱动的core dump也是由于hugepage的泄漏导致无法成功分配导致。

c. Zlib Shim状态机不完善导致特定场景下的压缩、解压缩请求异常，等众多问题就不一一介绍。

一路走来，通过无数次的性能优化、功能测试，多次同Intel研发同学一起探讨之后，才使得QAT在功能、性能、架构方面等众多问题得以快速解决，下面就准备上线前期准备工作。

3.3、运维梳理

部署发布

采用单rpm软件包、双二进制模式，从而降低软件版与硬件加速版之间的耦合度，自动识别部署机器是否开启QAT，并选择正确的二进制执行；

容灾保护

运行过程中由于某种资源的缺乏导致硬件加速版本Gzip执行失败，将会自动切换为软件版本、待资源可用时自动切换到硬件加速版本；

可维护与监控

虽然上线前做过一系列压测、稳定性并未出现异常，但对硬件加速的相关资源指标进行实时监控还是必不可少；

四、加速效果

测试机器

cpu型号：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 32核 内核：2.6.32 Zlib版本：zlib-1.2.8 QAT驱动版本：intel-qatOOT40052

数据对比

同等条件下，开启QAT加速后CPU平均值为41%左右，未开启QAT加速的CPU平均值为48%左右，如下图所示：

相同条件下，开启QAT加速后系统load平均值为12.09，关闭QAT加速时系统load平均值为14.22，如下图所示：

相同条件下，开启与关闭QAT加速后，响应RT波动不相上下，如下所示：

同等条件下，各模块热点函数图对比如下所示，其中红色圈中的是Gzip相关函数

（注：左侧是开启QAT加速）：

同比条件下Tengine Gzip使用QAT加速卡后，CPU消耗从48%下降到41%，系统负载load下降2个，且根据模块热点函数图对比发现Gzip基本上已经完全卸载。

结论

综上数据对比，当qps为10k左右时Tengine Gzip使用QAT加速后CPU节省15%左右，且Gzip基本上完全卸载、随着其占比变高，优化效果将越好。

五、总结

接入层Tengine Gzip硬件加速项目是阿里存储技术TairTengine团队及服务器研发计算团队与英特尔数据中心网络平台团队齐心协力下的产物，不仅带来了性能提升，而且使得接入层在硬件加速领域再次打下了坚实的基础、为明年SSL+Gzip架构上整合做好了沉淀，同时也填充了业内接入层对Gzip采用硬件加速的空白，对此领域的发展具有一定的影响意义

.Net的Cache和Memcached有什么优缺点？

如果你的服务器只有一台，且数据库读写压力不大，就没必要使用Memcached。HttpRuntime.Cache是本地缓存，Memcached是分布式缓存，两者的区别在于：

本地缓存

本地缓存可能是大家用的最多的一种缓存方式了，不管是本地内存还是磁盘，其速度快，成本低，在有些场合非常有效。

但是对于web系统的集群负载均衡结构来说，本地缓存使用起来就比较受限制，因为当数据库数据发生变化时，你没有一个简单有效的方法去更新本地缓存；然而，你如果在不同的服务器之间去同步本地缓存信息，由于缓存的低时效性和高访问量的影响，其成本和性能恐怕都是难以接受的。

分布式缓存

前面提到过，本地缓存的使用很容易让你的应用服务器带上“状态”，这种情况下，数据同步的开销09会比较大；尤其是在集群环境中更是如此！

分布式缓存这种东西存在的目的就是为了提供比RDB更高的TPS和扩展性，同时有帮你承担了数据同步的痛苦；优秀的分布式缓存系统有大家所熟知的Memcached、Redis（当然也许你把它看成是NoSQL，但是我个人更愿意把分布式缓存也看成是NoSQL），还有淘宝自主开发的Tair等。

对比关系型数据库和缓存存储，其在读和写性能上的差距可谓天壤之别；就拿淘宝的Tair来说，mdb引擎的单机QPS已在10w以上，ldb的也达到了5w~7w，而集群的性能会更高（目前uic所用的Tair集群QPS高达数十万！）。

所以，在技术和业务都可以接受的情况下，我们可以尽量把读写压力从数据库转移到缓存上，以保护看似强大，其实却很脆弱的关系型数据库。

分布式站点怎么解决session

在分布式集群环境下，session的获取就不能采用request.setSession了。那么如何解决分布式session的问题呢，有以下几个方案：

1.tomcat容器自动同步session。

详见

2.其它方案：alibaba b2b采用的cookie的方案，这里面要关心的是信息的安全，如何防止信息的伪造并提交，这个以后可以研究。至于tair的方案，就是淘宝系现在采用的方案，是有通用代表性的方案

web集群时session同步的3种方法[转]

在做了web集群后，你肯定会首先考虑session同步问题，因为通过负载均衡后，同一个IP访问同一个页面会被分配到不同的服务器上，如果session不同步的话，一个登录用户，一会是登录状态，一会又不是登录状态。所以本文就根据这种情况给出三种不同的方法来解决这个问题：

一，利用数据库同步session

1，用一个低端电脑建个数据库专门存放web服务器的session，或者，把这个专门的数据库建在文件服务器上，用户访问web服务器时，会去这个专门的数据库check一下session的情况，以达到session同步的目的。

2，这种方法是把存放session的表和其他数据库表放在一起，如果mysql也做了集群了话，每个mysql节点都要有这张表，并且这张session表的数据表要实时同步。

说明：用数据库来同步session，会加大数据库的负担，数据库本来就是容易产生瓶颈的地方，如果把session还放到数据库里面，无疑是雪上加霜。上面的二种方法，第一点方法较好，把放session的表独立开来，减轻了真正数据库的负担

二，利用cookie同步session

session是存放在服务器端的，cookie是存放在客户端的，怎么实现同步呢？方法很简单，就是把用户访问页面产生的session放到cookie里面，就是以cookie为中转站。你访问web服务器A，产生了session把它放到cookie里面了，你访问被分配到web服务器B，这个时候，web服务器B先判断服务器有没有这个session，如果没有，在去看看客户端的cookie里面有没有这个session，如果也没有，说明session真的不存，如果cookie里面有，就把cookie里面的sessoin同步到web服务器B，这样就可以实现session的同步了。

说明：这种方法实现起来简单，方便，也不会加大数据库的负担，但是如果客户端把cookie禁掉了的话，那么session就无从同步了，这样会给网站带来损失；cookie的安全性不高，虽然它已经加了密，但是还是可以伪造的。

三，利用memcache同步session

memcache可以做分布式，如果没有这功能，他也不能用来做session同步。他可以把web服务器中的内存组合起来，成为一个”内存池”，不管是哪个服务器产生的sessoin都可以放到这个”内存池”中，其他的都可以使用。

优点：以这种方式来同步session，不会加大数据库的负担，并且安全性比用cookie大大的提高，把session放到内存里面，比从文件中读取要快很多。

缺点：memcache把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定了，memcache不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢出。

四，总结

上面三种方法都是可行的

第一种方法，最影响系统速度的那种，不推荐使用；

第二种方法，效果不错，不过安全隐患一样的存在；

第三种方法，个人觉得第三种方法是最好的，推荐大家使用

怎么搭建一个tair缓存服务器

能啊，不过不知你要怎么做。

一般来说，对企业级用户才需要这些功能。主要就是避开上网高峰期，利用夜间来把网页等内容缓存下来，到了白天再用，再打开时可以看到网页是前一天或当天凌晨的。不过，不要紧，一点“刷新”就好了，因为大部分内容都下来了，改动也就很少，浏览网页的速度也就很快了。

方法我知道有两种，都是基于系统服务器的：1 WINDOWS系统下可以装一个ISA2000之类的软件，它可以提供防火墙、NAT、缓存三大功能。这个软件一时半会说不清楚，你可以自己下一个下来慢慢来，并不是很难。2 LINUX系统下也可以实现，在安装了一个叫squid的服务后，这个功能就可以再通过配置来实现，不过配置全是用命令，有点困难了。

最后，建议用ISA来做，或者找些专用的小软件之类的。顺便问一下，你该不是在开网吧，自学吧。

delphi 分布式架构怎么学

由于分布式系统所涉及到的领域众多，知识庞杂，很多新人在最初往往找不到头绪，不知道从何处下手来一步步学习分布式架构。

本文试图通过一个最简单的、常用的分布式系统，来阐述分布式系统中的一些基本问题。

负载均衡

分布式缓存

分布式文件系统/CDN

分布式RPC

分布式数据库/Nosql

分布式消息中间件

分布式session问题 

-总结

下图为一个中大型网站/App的基本架构： 

在这个架构中，涉及到以上所列的基本问题：

负载均衡

负载均衡是分布式系统中的一个最最基本的问题。在上图中：

网关需要把请求分发给不同的Tomcat； 

Tomcat需要把收到的请求，分发给不同的Service；

这都需要负载均衡。一句话：凡是请求从一个入口进来，需要分发给后端不同的机器时，就需要负载均衡。

局域网负载均衡

在上图中，负载均衡发生在局域网内部。在这里，常用的网关软件有Nginx/HAProxy/F5/LVS/各种云上的SLB等。

广域网负载均衡

在上图之外，还有广域网负载均衡。这通常发生在域名服务器上，而不是局域网内部。 

同1个域名，映射到不同的局域网集群。

负载均衡算法

常用的负载均衡算法：随机，轮询（Round Robin)，最小资源数，hash。

分布式缓存

在上图中，当DB负载过高，我需要为Service机器加缓存时，就遇到一个基本问题： 

如果使用local的内存做缓存，则其他Service机器就没办法共用此缓存。 

因次，我需要一个可以让所有Service机器共享的缓存，这就是分布式缓存。

常用的分布式缓存组件：Memcached/Redis/Tair等

分布式文件系统

在上图中，当我要存储客户端上传的图片文件时，就会遇到另一个基本问题：我不能把图片存在每个Tomcat的本地文件系统里面，这样的话，其他机器就没办法访问了。我需要一个让所有机器可以共享的文件系统，这就是分布式文件系统。

常用的分布式文件系统：MogileFS/TFS/HDFS/Amazon S3/OpenStack Swift等

当使用了分布式文件系统，对外提供图片url访问服务时，就会遇到另一个基本问题：如果每次文件的访问，都要到分布式文件系统里面去取，效率和负载就可能成为问题。 

为此，就需要引入CDN。

常用的CDN厂商，比如ChinCache。当然，现在的各种云存储，比如七牛云，阿里云，腾讯云，已经自带了CDN。

分布式RPC

分布式系统的一个基本问题就是：机器与机器之间如何通信？ 我们都知道底层原理是TCP/IP，Socket。

但一般很少有人会去裸写Socket，实现机器之间的通信。这里，最常用的组件就是RPC。

最简单的实现RPC的方式就是使用http。当然，业界有很多成熟的开源RPC框架，如Facebook的Thrift, 阿里的Dubbo，点评的Pigeon。。

在RPC内部，一般都自己实现了负载均衡。还有更复杂的，如多版本，服务降级等。

补充一句：虽然底层原理都是Socket，但使用不同框架/组件时，通常都有其自己的跨机器通信方式，比如Mysql JDBC，RPC， 消息中间件等。

分布式数据库

在上图中，DB是单一节点。当访问量达到一定程度，就会涉及到Mysql的分库分表问题。

分库/分表之后，就会涉及到join的问题，分布式事务的问题。

关于分库分表，业界也早有成熟方案。对上层屏蔽分库分表，sql的执行，像是在单库一样。

还有像MongoDB这种Nosql数据库，天生是分布式的。但同样会面对Mysql分库分表所要面对的问题。

还有像阿里的OceanBase，有Mysql的强一致性保证，又是分布式的，还可以支持分布式事务。

分布式消息中间件

在上图中，没有提及到消息中间件。相对其他基本问题，这个需要一个更适合的业务场景来谈，在以后的章节中，会再详述。

常用的消息中间件，比如老一辈的ActiveMQ/RabbitMQ， 新一点的，阿里的RocketMQ，LinkedIn的Kafka等。

消息中间件的一个典型场景就是：通过最终一致性，解决上面的分布式事务问题。

分布式session问题

在传统的单机版应用中，我们经常使用session。而当单机扩展到多机，单机的session就没办法被其他机器所访问。

此时就需要使用分布式session，把session存放在一个所有Tomcat都可以访问的地方。

关于分布式session，业界早有成熟方案，在此不再详述。

总结

本文罗列了分布式系统的各种基本问题和业界常用的技术，希望建立起分布式系统的一个宏观图谱。

淘宝tair 为什么不用redis

redis很好用，提供缓存服务。相比memcached多了N多新数据结构和主从模式增加可用性。不过redis有一点不能满足一些互联网公司开发者需求。

redis集群中，想借用缓存资源必须得指明redis服务器地址去要。这就增加了程序的维护复杂度。因为redis服务器很可能是需要频繁变动的。

所以人家淘宝就想啊，为什么不能像操作分布式数据库或者hadoop那样。增加一个中央节点，让他去代理所有事情。

所以人家就开发了这个tair。程序只要跟tair中心节点交互就OK了。甚至人家还弄了个配置服务器这种概念。免去了像操作hadoop那样，还得每台hadoop一套一模一样配置文件。改配置文件得整个集群都跟着改。

tair使用了google在bigtable里面的merge-dump模型。

底层存储可以用redis或者google的levelDB.而且人家淘宝已经把他开源了。

未来，如果你用redis不弄个中央节点。你还好意思说你会redis吗？