经验分享：如何构建亿级前端读服务

视频汇总首页：http://edu.51cto.com/lecturer/index/user_id-4626073.html

======================================

一些设计原则

• 无状态

• 数据闭环

• 缓存银弹

• 并发化

• 降级开关

• 限流

• 切流量

• 其余

无状态

若是设计的应用是无状态的，那么应用就能够水平扩展，固然实际生产环境多是这样子的： 应用无状态，配置文件有状态。好比不一样的机房须要读取不一样的数据源，此时就须要经过配置文件指定。

数据闭环

若是依赖的数据来源特别多，此时就能够考虑使用数据闭环，基本步骤：

一、数据异构：经过如MQ机制接收数据变动，而后原子化存储到合适的存储引擎，如redis或持久化KV存储；

二、数据聚合：这步是可选的，数据异构的目的是把数据从多个数据源拿过来，数据聚合目的是把这些数据作个聚合，这样前端就能够一个调用拿到全部数据，此步骤通常存储到KV存储中；

三、前端展现：前端经过一次或少许几回调用拿到所须要的数据。

这种方式的好处就是数据的闭环，任何依赖系统出问题了，仍是能正常工做，只是更新会有积压，可是不影响前端展现。

另外此处若是一次须要多个数据，能够考虑使用Hash Tag机制将相关的数据聚合到一个实例，如在展现商品详情页时须要：商品基本信息：p:123:， 商品规格参数：d:123:，此时就可使用冒号中间的123做为数据分片key，这样相同id的商品相关数据就在一个实例。

缓存银弹

缓存对于读服务来讲可谓抗流量的银弹。

浏览器端缓存

设置请求的过时时间，如响应头Expires、Cache-control进行控制。这种机制适用于如对实时性不太敏感的数据，如商品详情页框架、商家评分、评价、广告词等；但对于如价格、库存等实时要求比较高的，就不能作浏览器端缓存。

CDN缓存

有些页面/活动页/图片等服务能够考虑将页面/活动页/图片推送到离用户最近的CDN节点让用户能在离他最近的节点找到想要的数据。通常有两种机制：推送机制（当内容变动后主动推送到CDN边缘节点），拉取机制（先访问边缘节点，当没有内容时回源到源服务器拿到内容并存储到节点上），两种方式各有利弊。 使用CDN时要考虑URL的设计，好比URL中不能有随机数，不然每次都穿透CDN，回源到源服务器，至关于CDN没有任何效果。对于爬虫能够返回过时数据而选择不回源。

接入层缓存

对于没有CDN缓存的应用来讲，能够考虑使用如Nginx搭建一层接入层，该接入层能够考虑以下机制实现：

一、URL重写：将URL按照指定的顺序或者格式重写，去除随机数；

二、一致性哈希：按照指定的参数（如分类/商品编号）作一致性Hash，从而保证相同数据落到一台服务器上；

三、proxy_cache：使用内存级/SSD级代理缓存来缓存内容；

四、proxy_cache_lock：使用lock机制，将多个回源合并为一个，减小回源量，并设置相应的lock超时时间；

五、shared_dict：此处若是架构使用了nginx+lua实现，能够考虑使用lua shared_dict进行cache，最大的好处就是reload缓存不丢失。

此处要注意，对于托底/异常数据不该该让其缓存，不然用户会在很长一段时间看到这些数据。

应用层缓存

如咱们使用Tomcat时可使用堆内缓存/堆外缓存，堆内缓存的最大问题就是重启时内存中的缓存丢失，若是此时流量风暴来临可能冲垮应用；还能够考虑使用local redis cache来代替堆外内存；或者在接入层使用shared_dict来将缓存前置，减小风暴。

分布式缓存

一种机制就是废弃分布式缓存，改为应用local redis cache，即在应用所在服务器中部署一个redis，而后使用主从机制同步数据。若是数据量不大这种架构是最优的；若是数据量太大，单服务器存储不了，还能够考虑分片机制将流量分散到多台；或者直接就是分布式缓存实现。常见的分片规则就是一致性哈希了。

如上图就是咱们一个应用的架构：

一、首先接入层读取本地proxy cache / local cache；

二、若是不命中，会读取分布式redis集群；

三、若是还不命中，会回源到tomcat，而后读取堆内cache；若是没有，则直接调用依赖业务获取数据；而后异步化写到redis集群；

由于咱们使用了nginx+lua，第2、三步可使用lua-resty-lock非阻塞锁减小峰值时的回源量；若是你的服务是用户维度的，这种非阻塞锁不会有什么大做用。

并发化

假设一个读服务是须要以下数据：

一、数据A 10ms

二、数据B 15ms

三、数据C 20ms

四、数据D 5ms

五、数据E 10ms

那么若是串行获取那么须要：60ms；

而若是数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C；那么咱们能够这样子来获取数据：

那么若是并发化获取那么须要：30ms；能提高一倍的性能。

假设数据E还依赖数据F(5ms)，而数据F是在数据E服务中获取的，此时就能够考虑在此服务中在取数据A/B/D时预取数据F，那么总体性能就变为了：25ms。

降级开关

对于一个读服务，很重要的一个设计就是降级开关，在设计降级开关时主要以下思路：

一、开关集中化管理：经过推送机制把开关推送到各个应用；

二、可降级的多级读服务：好比只读本地缓存、只读分布式缓存、或者只读一个默认的降级数据；

三、开关前置化：如架构是nginx—>tomcat，能够将开关前置到nginx接入层，在nginx层作开关，请求不打到后端应用。

限流

目的是防止恶意流量，恶意***，能够考虑以下思路：

一、恶意流量只访问cache；

二、对于穿透到后端应用的能够考虑使用nginx的limit模块处理；

三、对于恶意ip可使用如nginx deny进行屏蔽。

大部分时候是不进行接入层限流的，而是限制流量穿透到后端薄弱的应用层。

切流量

对于一个大型应用，切流量是很是重要的，好比多机房有机房挂了、或者有机架挂了、或者有服务器挂了等都须要切流量，可使用以下手段进行切换：

一、DNS：切换机房入口；

二、LVS/HaProxy：切换故障的nginx接入层；

三、Nginx：切换故障的应用层；

另外咱们有些应用为了更方便切换，还能够在nginx接入层作切换，经过nginx进行一些流量切换，而没有经过如LVS/HaProxy作切换。

其余

不须要cookie的应用使用无状态域名，如3.cn；

接入层请求头过滤，只转发有用的请求头到后端应用；

数据过滤逻辑前置，好比在接入层进行请求参数的合法性过滤；

内网设置合理的链接、读、写超时时间；

根据须要开启gzip压缩减小流量；

使用unix domain socket减小本机链接数；

内网考虑使用http长链接；

响应请求时，考虑响应头加上服务器ip等信息，方便调试。

咱们处理的读服务大部分都是KV的，所以抗流量的思路就是大量缓存；并且怎么让缓存怎么更接近用户，离用户越近速度就越快。再一个点就是要考虑好降级方案，在异常状况下应用不被拖垮拖死。咱们系统大量使用了如nginx+lua+redis技术，使用这些技术解决了咱们不少读服务问题。

 微信订阅号