反复发生您当前的网络存在链路层劫持_您当前的网络存在链路层劫持_网络 双链路(2)

微博使用了 双 层缓 存，上面是L1，每个L1上都是一组（包含4-6台机器），左边的框相当于一个机房，右边又是一个机房。在这个平台中L1缓存所起的作用是哪个？ 首先，L1 缓 存增加整个系 统 的 QPS， 其次 以低成本灵活扩容的方法 增加 系统 的 带宽 。想象一个极端场景，只有一篇博文，但是它的访问量无限增长，其实我们不需要影响L2缓存，因为它的内容存储的量小，但它就是访问量大。这种画面下，你就必须使用L1来扩容提升QPS和带宽瓶颈。另外一个场景，就是L2级缓存出现作用，比如我有一千万个用户，去访问的是一百万个用户的微博 ，这个之后，他不仅仅说你的吞吐量和访问码流，就是你要缓存的博文的内容也好多了，这个之后你要考量缓存的容量， 第二 级缓 存更多的是从容量上来 规划，保证请求以较小的比重 穿透到 后端的 数据 库 中 ，根据你的客户模型你可以估出来，到底有百分之多少的请求不能穿透到DB， 评估这个容量后来，才能更好的评估DB需要多少库，需要担负很大的访问的压力。另外，我们看双机房的话，左边一个，右边一个。 两个机房是互 为 主 备 ， 或者互 为热备 。如果两个用户在不同地域，他们访问两个不同机房的之后，假设用户从IDC1过来，因为就近原理，他会访问L1，没有的话就会回到Master，当在IDC1没找到的之后才能回到IDC2来找。

同时有用户从IDC2访问，也会有请求从L1和Master返回以及至IDC1去查找。 IDC1 和 IDC2 ，两个机房都有全量的，同时提供服务，但是缓存查询又遵循最近访问原理。还有什么多级缓存的举例呢？CDN是典型的多级缓存。CDN在中国各个地区做了这些节点，比如在杭州市部署一个节点时反复出现您当前的网络存在链路层劫持，在机房里显然不止一台机器，那么针对一个地区来说，只有几台服务器到源站回源，其他节点都到这几台服务器回源即可，这么看CDN至少还有两级。Local Cache+ 分布式 缓 存，这只是常见的一种策略。有一种场景，分布式缓存并不适用， 比如 单 点 资 源 的爆发性峰值流量，这个之后使用Local Cache + 分布式缓存，Local Cache 在 应用 服 务 器 上用更小的 内存资源 挡住少量的 极端峰值流量，长尾的流量一直访问分布式缓存，这样的Hybrid缓存架构通过复用众多的应用服务器节点，降低了平台的整体利润。 我们来看一下 Feed 的存 储 架构，微博的博文主要存在MySQL中。首先来看内容表，这个非常简洁反复出现您当前的网络存在链路层劫持，每条内容一个索引，每天建一张表，其次看索引表，一共建了两级索引。首先想象一下用户场景，大部分用户刷微博的之后，看的是他关注所有人的微博，然后按时间来顺序。

仔细探讨发现在这个画面下， 跟一个用户的自己的相关性很小了。所以在一级索引的之后会先按照关注的客户，取它们的前条微博ID，然后聚合排序。我们在做哈希（分库分表）的之后，同时考虑了根据UID哈希和依据时间维度。很业务和时间相关性很高的，今天的热点新闻，明天就没热度了，数据的冷热非常显著，这种画面就必须根据时间维度做分表，首先冷热数据做了分离（可以对冷热数据运用不同的储存方案来增加费用），其次， 很容止控制我表的爆炸。像微博如果只根据客户维度区分，那么这个客户所有数据都在一张表里，这张表就是无限增长的，时间长了查询会越来越慢。二级索引，是我们上面一个比较特殊的画面，就是我要迅速找到这个人所应公布的某一时段的微博时，通过二级索引快速定位。 分布式服务追踪平台 分布式追踪服务系统，当平台到千万级以后的之后，越来越庞杂，所缓解的弊端很倾向稳定性，性能跟监控。刚才说顾客只要有一个请求过来，你可以依赖你的服务RPC1、RPC2，你会看到RPC2又依赖RPC3、RP。分布式服务的之后一个痛点，就是说一个请求从用户过来以后，在后台不同的机器之间不停的调用并返回。 当你发现一个问题的之后，这些日志落在不同的机器上，你也不知道问题究竟出在那里，各个服务之间相互隔离，互相之间没有建立关联。

所以造成排查问题基本没有任何形式，就是出了问题没法儿解决。 我们要解决的难题，我们今天说日志互相隔离，我们还要把它建立联系。建立联系我们就有一个请求ID，然后结合RPC框架， 服务治理功能。假设请求从客户端过来，其中包括一个ID 101，到服务A时依然带有ID 101，然后调用RPC1的之后也会标志这是101 ，所以必须 一个唯一的 请求 ID 标识 递归迭代的释放到每一个 相关 节点。第二个，你做的之后，你不能说每个地方都加，对业务平台来说需要一个框架来完成这个工作， 这 个框架应 对业务 系 统 是最低侵入原 则 ， 用 JAVA 的 话 就可以用 AOP，要做到零侵入的方法，就是对所有相关的中间件打点，从接口层模块（HTTP Client、HTTP Server）至到服务层模块（RPC Client、RPC Server），还有数据访问中间件的，这样业务平台只应该少量的配置信息就可以推动全链路监控 。为什么要用日志？服务化以后，每个服务可以用不同的研发语言， 考虑多种开发语言的兼容性 ， 内部定 义标 准化的日志 是惟一且有效的方法。最后，如何建立基于GPS导航的路况监控？我们今天讲分布式服务追踪。

分布式服务追踪可缓解的弊端， 如果 单一用 户发现问题 后 ， 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在哪个，但是并没有解决如何看到问题。我们看现实中非常容易理解的公路监控，每辆车有GPS定位，我想看北京哪儿拥堵的之后，怎么做？ 第一个 ， 你必定要知道每个 车 在哪个位置，它跑到哪儿了。其实可以说每个车上只要有一个标识，加上每一次流动的信息，就可以看见每个车流的位置跟方向。 其次如何做 监 控和 报 警，我们如何可知道道路的流量情况跟负载，并迅速报警。我们应定义这条街道多宽多高，单位时间可以通行多少辆车，这就是道路的容量。有了道路容量，再有道路的即时流量，我们就可以基于实习路况做预警？ 对应于 分布式系 统 的话怎么构建？ 第一 ， 你要 定义 每个服 务节 点它的 SLA A 是多少 ？SLA可以从平台的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义，相当于定义系统的容量。 第二个 ， 统计 线 上 动态 的流量，你要知道服务的平均QPS、最低QPS和最大QPS，有了流量和容量，就可以对平台做全面的监控和报警。 刚才讲的是理论，实际状况必定比这个复杂。

微博在新年的之后做许多活动，必须保障系统稳定，理论上你即便定义容量和流量就可以。但实际远远不行，为什么？有技术的原因，有人为的诱因，因为不同的研发定义的流量和容量指标有主观性，很难全局量化标准，所以真正流量来了以后，你预先评估的平台瓶颈通常不恰当。实际中我们在春节前主要实行了三个措施：第一，最简单的就是有降 级 的 预 案，流量达到平台容量后，先把这些功能砍掉，需要有确立的优先级 。第二个， 线上全链路压测，就是把这次的流量放大到我们平时流量的五倍甚至十倍（比如下线一半的服务器，缩容而不是扩容），看看系统瓶颈最先发生在那里。我们之前有一些实例，推测系统会先发生弊端，但是实测发现是前端的程序先碰到难题。第三，搭建 Docker 集群 ， 所有业务共享备用的 Docker集群资源，这样可以极大的防止每个业务都预留资源，但是实际上流量没有增长导致的耽误。 总结 接下来说的是怎样不停的学习跟提升，这里以Java语言为例，首先， 一定要 理解 JAVA；第二步，JAVA完了之后，一定要 理 解 JVM；其次，还要 理解 操作系统；再次还是应知道一下 Design Pattern，这将告诉你怎么把过去的心得抽象沉淀供日后借鉴；还要学习 TCP/IP、 分布式系 统、数据结构和算法。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-137523-2.html