wordpress自适应图片主题,企业网站的优化方案,服装设计专业主要学什么,怎么做一个网站送给女朋友摘要#xff1a; 12月13-14日#xff0c;由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束#xff0c;集中为大家分享了2017双11背后的黑科技。本文是《双11万亿流量下的分布式缓存》演讲整理#xff0c;本文主要从Tair发展和应用开始谈起 12月13-14日由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束集中为大家分享了2017双11背后的黑科技。本文是《双11万亿流量下的分布式缓存》演讲整理本文主要从Tair发展和应用开始谈起接着谈及双11面临的挑战重点分享了性能优化方面的实践最后对缓存难题给出了解决方案。
12月13-14日由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束集中为大家分享了2017双11背后的黑科技。本文是《双11万亿流量下的分布式缓存》演讲整理本文主要从Tair发展和应用开始谈起接着谈及双11面临的挑战重点分享了性能优化方面的实践最后对缓存难题给出了解决方案。内容如下。
分享嘉宾宗岱阿里巴巴资深技术专家2008年加入淘宝阿里分布式缓存、NoSQL数据库Tair和Tengine负责人。
Tair概览
Tair发展历程
Tair在阿里巴巴被广泛使用无论是淘宝天猫浏览下单还是打开优酷浏览播放时背后都有Tair的身影默默支撑巨大的流量。Tair的发展历程如下
2010.04 Tair v1.0正式推出淘宝核心系统 2012.06 Tair v2.0推出LDB持久化产品满足持久化存储需求 2012.10 推出RDB缓存产品引入类Redis接口满足复杂数据结构的存储需求 2013.03 在LDB的基础上针对全量导入场景上线Fastdump产品大幅度降低导入时间和访问延时 2014.07 Tair v3.0 正式上线性能X倍提升 2016.11 泰斗智能运维平台上线助力2016双11迈入千亿时代 2017.11 性能飞跃热点散列资源调度支持万亿流量。
Tair是一个高性能、分布式、可扩展、高可靠的key/value结构存储系统Tair特性主要体现在以下几个方面
高性能在高吞吐下保证低延迟是阿里集团内调用量最大系统之一双11达到每秒5亿次峰值的调用量平均访问延迟在1毫秒以下 高可用自动failover 单元化机房内以及机房间容灾确保系统在任何情况下都能正常运行 规模化分布全球各个数据中心阿里集团各个BU都在使用 业务覆盖电商、蚂蚁、合一、阿里妈妈、高德、阿里健康等。
Tair除了普通Key/Value系统提供的功能比如get、put、delete以及批量接口外还有一些附加的实用功能使得其有更广的适用场景。Tair应用场景包括以下四种
MDB 典型应用场景用于缓存降低对后端数据库的访问压力比如淘宝中的商品都是缓存在Tair中用于临时数据存储部分数据丢失不会对业务产生较大影响读多写少读qps达到万级别以上。LDB 典型应用场景通用kv存储、交易快照、安全风控等存储黑白单数据读qps很高计数器功能更新非常频繁且数据不可丢失。RDB 典型应用场景复杂的数据结构的缓存与存储如播放列表直播间等。FastDump 典型应用场景周期性地将离线数据快速地导入到Tair集群中快速使用到新的数据对在线读取要求非常高读取低延迟不能有毛刺。
双 11 挑战怎么办2012-2017年数据如图可以看到2012年GMV小于200亿2017年GMV达到1682亿交易创建峰值从1.4万达到32.5万峰值QPS从1300万达到近5亿。我们可以得出Tair访问峰值增速Tair峰值 交易峰值 总GMV如何确保成本不超过交易峰值增速对于带数据的分布式系统来说缓存问题都是比较难解决的缓存流量特别大2017年双11后我们彻底解决掉了缓存问题。我们现在的交易系统和导入系统都是多地域多单元多机房部署的如何快速部署业务系统呢
多地域多单元多地域多单元首先是中心机房我们做了双机房容灾两侧还有若干个单元。机房内系统图如图从流量接入进统一接入层-应用层-中间件-Tair-DB在数据层我们会做多地域的数据同步。
弹性建站我们需要系统具备弹性建站的能力。Tair是一个复杂的分布式存储系统我们为之建立了一整套运营管控系统泰斗在泰斗里建设弹性建站系统它会经过一系列工作步骤将Tair系统建设起来我们还会从系统层面、集群层面和实例连通层面进行验证以确保系统功能、稳定性万无一失。
Tair的每一个业务集群水位其实是不一样的双11前的每一次全链路压测下由于业务模型的变化所用Tair资源会发生变化造成水位出现变化。在此情况下我们需要每一次压测完在多个集群间调度Tair资源如果水位低就会把某些机器服务器资源往水位高挪达到所有集群水位值接近。
数据同步对于单元化业务我们提供了本单元访问本地Tair的能力对于有些非单元化业务我们也提供了更灵活的访问模型。同步延迟是我们一直在做的事情2017年双11每秒同步数据已经达到了千万级别那么如何更好地解决非单元化业务在多单元写入数据冲突问题这也是我们一直考虑的。
性能优化降成本
服务器成本并不是随着访问量线性增长每年以百分之三四十成本在下降我们主要通过服务器性能优化、客户端性能优化和不同的业务解决方案三方面达到此目的。
内存数据结构图为MDB内存数据结构示意图我们在进程启动之后会申请一大块内存在内存中将格式组织起来。主要有slab分配器、hashmap和内存池内存写满后会经过LRU链进行数据淘汰。随着服务器CPU核数不断增加如果不能很好处理锁竞争很难提升整体性能。参考了各种文献和操作系统的设计我们使用了细粒度锁、无锁数据结构、CPU本地数据结构和读拷贝更新读链表时不需要加锁。左图为未经过优化时锁竞争各个功能模块消耗图可以看到网络部分和数据查找部分消耗最多优化后右图有80%的处理都是在网络和数据查找这是符合我们期望的。
用户态协议栈 锁优化后我们发现很多CPU消耗在内核态上这时我们采用DPDKAlisocket来替换掉原有内核态协议栈Alisocket采用DPDK在用户态进行网卡收包并利用自身协议栈提供socket API对其进行集成。我们与业内类似系统进行了对比如图。
内存合并单机性能提升足够高后带来问题是单位qps对应内存量变少了怎么解决呢我们发现公用集群整体看内存还是有的某些slab没有办法写入 比如64字节slab没有被写满但是72字节slab全部写满了内存池都被申请完了我们把64字节slab空闲页相互合并这样可以释放大量空闲页。其中不可避免加入模式锁在触发合并阈值情况下切换成加锁状态合并都是在访问量低峰期做的对于业务峰值来说没有问题。
客户端优化客户端我们做了两方面优化网络框架替换适配协程从原有的mina替换成netty吞吐量提升40%序列化优化集成 kryo和hessian吞吐量提升16%。
内存网格如何与业务结合来降低整体Tair与业务成本Tair提供了多级存储一体化解决业务问题比如安全风控场景读写量超大、有大量本地计算我们可以在业务机器本地存下该业务机器所要访问的数据大量读会命中在本地而且写在一段时间内是可合并的在一定周期后合并写到远端Tair集群上作为最终存储。我们提供读写穿透包括合并写和原有Tair本身具有多单元复制的能力双11时业务对Tair读取降至27.68%对Tair写入降至55.75%。
热点难题已解决
缓存击穿缓存从开始的单点发展到分布式系统通过数据分片方式组织但对每一个数据分片来说还是作为单点存在的。当有大促活动或热点新闻时数据往往是在某一个分片上的这就会造成单点访问进而缓存中某个节点就会无法承受这么大压力致使大量请求没有办法响应。即便是限流也是有损操作可能也会造成全系统崩溃。我们发现问题根源是访问热点需要彻底解决该问题。
热点散列经过多种方案的探索采用了热点散列方案。我们评估过客户端本地cache方案和二级缓存方案它们可以在一定程度上解决热点问题但各有弊端。而热点散列直接在数据节点上加hotzone区域让hotzone承担热点数据存储。对于整个方案来说最关键有以下几步
智能识别。热点数据总是在变化的或是频率热点或是流量热点。 实时反馈。采用多级LRU的数据结构设定不同权值放到不同层级的LRU上一旦LRU数据写满后会从低级LRU链开始淘汰确保权值高的得到保留。 动态散列。当访问到热点时Appserver和服务端就会联动起来根据预先设定好的访问模型动态散列到其它数据节点hotzone上去访问集群中所有节点都会承担这个功能。 通过这种方式我们将原来单点访问承担的流量通过集群中部分机器来承担。可以看到双11零点的刹那我们吸收了800多万次的热点访问。如果没有做热点散列散列前的指数都会超过死亡水位线。
写热点写热点与读热点有类似的地方也需要把热点实时识别出来然后通过IO线程把有热点key的请求放给合并线程去处理会有定时处理线程提交给存储层。
经过双11考验对读写热点的处理我们现在可以放心的说我们将缓存包括kv存储部分的读写热点彻底解决了。
