微博CacheService架构浅析

　　微博作为海内最大的社交媒体网站之一，天天承载着亿万用户的服务请求，这些请求的背后，需要消耗着庞大的盘算、内存、网络、I/O等资源。而且由于微博的产物特征，节沐日、热门事务等可能带来突发数倍甚至十几倍的会见峰值，这些都对于支持微博的底层基础架构提出了比力严苛的要求，需要知足：

每秒数十万的用户请求数据更新的实时性服务请求的低响应时间99. 99%以上的服务可用性

　　为了知足营业的生长需要，微博平台开发了一套高性能高可用的CacheService架构用于支持现有线上的营业系统的运转。但“冰动三尺非一日之寒”，微博的Cache架构也是履历了从无到有，不停的演进历程。

　　基于MySQL的Web架构

　　最初的微博系统，系统的会见量都比力小，简朴的基于数据库(MySQL)已经能够知足营业需求，开发也比力简朴，简朴的架构示意图如下：

　　随着微博的推广和名人用户入驻微博，动员了用户量的快速增加，会见量也与日俱增，这个时间，简朴基于MySQL的架构已经略感吃力，系统响应也比力缓慢。由于MySQL是一个持久化存储的解决方案，数据的读写都市经由磁盘，虽然MySQL也有buffer pool，可是无法凭据营业的特征做到很细粒度的控制。而在微博这种营业场景下，设置了SAS盘的MySQL服务单机只能支持几千的请求量，远小于微博的营业请求量。

　　基于单层Cache+MySQL的Web架构

　　针对请求量增大的问题，一样平常有几种解决方案：

营业架构革新，可是在这种场景下，这种方案的可行性不高。MySQL举行从库扩容，虽然能够解决问题，可是带来的成本也会比力高，而且纵然能够抗住请求量，可是资源的响应时间照旧无法知足期望的效果，由于磁盘的读取的响应时间要相对比力慢，通俗的15000转/分钟的SAS盘的读取延迟平均要到达2ms以上。在MySQL之上架构一层缓存，把热门请求数据缓存到Cache，基于Cache+MySQL的架构来提供服务请求。

　　思量到整体的改动和成本的因素，基于方案3)比力适合微博的营业场景。而应该使用什么类型的Cache比力合适呢?

　　比力常见的Cache解决方案有：

Local Cache，通过在Web应用端内嵌一个当地的Cache，这种的优势是会见比力快，可是存在的问题也比力显着，数据更新的一致性比力难保证，因此使用的规模会有一定的限制。单机版的远程Cache，通过部署一套远程的Cache服务，然后应用端请求通过网络请求与Cache交互，为相识决应用的水平扩展和容灾问题，往往通过在client层面来实现数据的路由等。漫衍式的Cache，Cache服务自己是一个大集群，能够提供应种种营业应用使用，并提供了一些基本的漫衍式特征：水平扩展、容灾、数据一致性等等。

　　从系统的简朴性思量和微博场景的适用问题，最终选择了2)的方式，基于开源的Memcached来作为微博的Cache方案。

　　Memcached是一个漫衍式Cache Server，提供了key-value型数据的缓存，支持LRU、数据逾期镌汰，基于Slab的方式治理内存块，提供简朴的set/get/delete等操作协议，自己具备了稳固、高性能等优点，并在业界已经获得普遍的验证。它的server端自己是一个单机版，而漫衍式特征是基于client端的实现来知足，通过部署多个Memcached节点，在client端基于一致性hash(或者其他hash计谋)举行数据的疏散路由，定位到详细的memcached节点再举行数据的交互。当某个节点挂掉后，对该节点举行摘除，并把该节点的请求疏散到其他的节点。通过client来实现一定水平的容灾和伸缩的能力。

　　这种架构经由一段时间的蜜月期后，也逐步遇到了一些问题。

节点挂掉导致的瞬间的峰值问题

好比部署有5个Memcached节点，对key做一致性hash将key散落漫衍到5个节点上，那么若是其中有1个节点挂掉，那么这个时间会有20%原本Cache hit的请求穿透到后端资源(好比DB)。对于微博而言，多数焦点资源的Cache hit的比例是99%，单组资源的QPS可能就到达100W以上的级别，若是这个时间有20%的穿透，那么相当于后端资源需要抗住20W以上的请求，这对于后端资源来说，显着压力过大。

 1/3    1 2 3 下一页 尾页