架构师师傅在训练营第 5 周感想



一晃来到第5周，不停赶工的我也在抽时间复习课程、看PPT、想着作业怎么做。

为什么这周的标题这么有特点呢？我们在称呼别人的职业的时候，你想想是不是这么叫的：司机师傅、工人师傅，那咱们就……架构师师傅，或者架构师傅也可以。



本周作业还是有难度滴：实现一致性hash算法。不过除了单纯实现算法，我觉得还可以实现一个实际的缓存处理队列。待我慢慢实现，没有要求实现一个实际队列真是良心作业了，要是上学时候这非得让实现一个分布式服务集群不可。估计真是课堂作业的话，那就得学生分组，然后抄抄抄……几个小组的主要程序员串通一下分别编程。如果没有这么有难度的作业，怎么会出现清华大学C语言门这样的案例呢？对不对……百度上还没有删除，如果看官不了解，可以自行百度。

脑中浮现了多年以前，大家啃那些晦涩、没有注释、都是英文参考文献的C或者C++程序的日子。这种开源，跟没开其实相差不是太大，没几个人通读程序；通读的没几个人能读懂；读懂的没几个人改得了；改得了的没几个人想改——要不自己再写一个？每次读起来源代码都有一种“破除封建迷信，我是菜鸟白痴”的感觉。

一、先聊作业。本次课程需要复习一下标准差公式，如果计算总体偏差，标准差公式除数是N；如果计算样本偏差，标准差公式除以N-1。

并且有另一个形式的标准差公式。

这是母体标准差。如果是样本标准差，则将N改为N-1。

要以样本的一小部分来估算整体的时候，存在估算（不确定）这个概念的时候，应使用样本方差公式，而我们对每一组数据都是已知的情况，再算方差时，就是母体方差，应使用母体方差公式。母体方差和样本方差，分别体现了对同一个事物的期望。

在概率论和统计学中，数学期望(mean)（或均值，亦简称期望）是试验中每次可能结果的概率乘以其结果的总和。最常用的几个统计数据就是均值、方差（Variance）、标准差（Standard deviation）。这里的“差”，是差别、偏离值的含义，虽然公式里面有减号，但是用偏离程度理解就更好理解一些。

标准差越大说明所有数据偏离均值程度越大。

以上各种前菜知识可以证明：

一致性哈希队列的发明使得缓存有了很大的性能改善，从而应用更加广泛。

二、这周课程主要讲了缓存架构和负载均衡架构。

缓存的架构让我想起一个案例。缓存使用，比较重要的几件事：

1、缓存的复用性要高，这样性价比就高。如果缓存里面存的基本都是只访问几次的数据，浪费的程度也是惊人的。因此就带来一个操作方案：缓存的时间设置。复用性不高的缓存，普遍设置的过期时间都比较短。

2、缓存设计时，希望尽量少写而多读，减少I/O中写操作，努力应对读操作。而较短的时间设置又引起一件事：缓存的刷新率比较高，操作频繁，缓存服务器或者缓存数据库因此比较忙。

3、缓存数据库持久化。要考虑对某些数据进行持久化操作，一方面便于灾难恢复，一方面便于事后分析。毕竟缓存启用时，很多平台并没有很好的规划和监控，基本只知道忙不忙，至于究竟怎么忙的，靠缓存自己的日志还不够，还得加别的平台数据，然后……来猜。这样出事了就比较无头苍蝇，因为靠经验处理是不可能次次命中的。

下面的案例体现了这样几个特性，并且阐述了一个定义“缓存击穿”。



要说的案例是这样的：

前奏：

考虑这样一个场景：多人访问的视频平台，有几个数据经常被频繁访问：最近一天看了哪些视频、上次看到哪个视频的哪里。那么就想对这部分数据按照账号关键字做一个json的缓存。事情来了。当人少的时候，缓存工作得还好。

起因：

某一天做了个活动，给网站的几十万特定用户布置了每人必须看完一百来个视频的任务。视频长的可以达到1小时以上。用户开始狂刷视频网页。原来每天每用户20条以内的视频观看量变为每天每用户50个以上，并且由于需要查看自己有没有看完，对访问记录的查询几乎每用户每5分钟就要看一次。粗估起来每分钟也就是多了十几万访问量，但是这个流量是持续的，每小时多个几百万访问量。突然激增的访问量，导致缓存数据库很快存储负荷高起来。而访问缓存的连接突然增多，因为有人在不停查看自己的观看记录。

经过：

缓存逐渐变忙，并且由于视频记录是不停刷新的，json组装完写一次也要时间好不好？缓存的写也很繁忙，这就又有点和缓存“多读少写”的想法有冲突。每一个人的记录又不一样，不存在你看完的记录我可以复用的问题。于是缓存数据库读写都忙，I/O上升很快，不一会儿就被挂起……饶是缓存，一两台数据库也架不住峰值每秒几千个点击、平均每分钟几万次不停刷着读好不好。就算你读起来很快，网络连接不是无上限的。刷到一定程度，做缓存的Redis真的不响应了。这时动态扩容也来不及。

于是缓存里面没有响应了，响应超时，前台应用开始改道去数据库查询结果。这就是缓存击穿。大量的本应去缓存的请求，因为缓存没有数据或超时查询不到返回都去数据库查。数据库马上就亮红灯了，数据库管理员马上来处理故障，但是当然他管不了这么多访问量。赶紧联系应用维护，把网页先下线吧哥们，你不下线我们后面根本缓解不了。

前台一咬牙，下线就下线，降级服务。不过查了一下，有几百个视频都是访问热区……都下了。调视频时直接页面返回空的结果。

接下来，缓存数据库重启，数据全没了。重写，也没持久化什么数据，等着压力小了再说吧……

应用维护、后台维护开始跟开发聊，怎么办，撑不住啊哥们？开发说我搞个版本，5天开发完成测试上线。

维护们傻了……我去，5天，5天活动都快过去了……我们还得折腾5天啊？开发说：不是，你们再降级就快了，有经验了嘛。（5天的版本我也不能保证一定能解决问题啊）——好那就继续降级。用户能不能用已经不重要了，不能把整个平台拖死。

最后一看运营结果，访问量还达到了历史最高值。因为不明真相的群众，为了看完名下被安排必须看完的视频，不停的在刷新页面……

结果：

事后解决建议：对和用户ID+访问记录相关的缓存，应予以独立，单独采用内存数据库提供服务，隔离出缓存热区。应使用能够快速动态扩容的集群，应对短时间巨量访问压力，并可在闲时将集群缩容减少成本。同时要设法提高每数据库服务器的网络连接数量，这个牵扯到的事情就比较多。

那么有没有更好点的招数呢？有更神奇的招数……别让用户访问自己的观看记录。这在降级时也用了，用户一直看到的都是本地浏览器缓存的一个记录，没有刷新……

5天的版本有没有解决问题呢？没有，继续在应对巨量的时候降级，只不过这次降级更快了，前后端把降级的功能跟不降级的功能进一步解耦了，做了一个版本。

有人要质疑是不是水平太差了？4个月前团队的几个人还在培训班背题呢……

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

• 用你熟悉的编程语言实现一致性 hash 算法。

• 编写测试用例测试这个算法，测试 100 万 KV 数据，10 个服务器节点的情况下，计算这些 KV 数据在服务器上分布数量的标准差，以评估算法的存储负载不均衡性。