有关如何购买分布式信息系统的问题(2)

微博使用双层缓存. 顶部是L1. 每个L1是一个组（包含4到6台计算机）. 左边的框相当于一间计算机室，右边的框是一间计算机室. L1高速缓存在此系统中的作用是什么？首先，L1高速缓存增加了整个系统的QPS，其次，它以低成本和灵活的方式增加了系统带宽. 想象一个极端的情况，即只有一个博客文章，但是访问量却在无限增长. 实际上，我们不需要影响L2缓存，因为它的内容存储很小，但是访问量却很大. 在这种情况下，您需要使用L1来扩展容量以改善QPS和带宽瓶颈. 另一个方案是L2缓存起作用的地方. 例如，我有1000万用户，而我访问了100万用户的微博. 此时，他不仅在谈论您的吞吐量和访问带宽，还包括您. 要缓存的博客文章的内容也很多. 这时，您必须考虑缓存的容量. 根据您的需求，可以从容量上对二级缓存进行更充分的计划，以确保请求可以一小部分渗透到后端中. 最后，无法穿透的请求百分比. 评估此容量之后，您可以更好地评估需要多少个库以及需要承受多少访问压力. 另外，如果我们看一下双机房，左边是一间，右边是一间. 这两个计算机室是相互活动的或备用的. 如果有两个用户位于不同的区域，并且他们访问了两个不同的计算机室，则假设该用户来自IDC1，由于接近原理，他将访问L1，否则，他将访问主服务器，并且仅当IDC1不是找到来IDC2.

同时，某些用户从IDC2访问，并且将有从L1和主服务器返回或返回IDC1的请求. IDC1和IDC2这两个房间都有完整的用户数据，并同时提供服务，但是缓存查询遵循最近访问的原则. 多级缓存还有哪些其他示例？ CDN是典型的多级缓存. CDN已在该国各个地区建立了许多节点. 例如，在杭州部署节点时，计算机机房中必须有多台计算机. 对于一个区域，源站只有几台服务器，其他节点都在这里. 可以将几个服务器返回到源分布式计算实验教程，因此CDN至少具有两个级别. 本地缓存+分布式缓存，这也是一种常见策略. 在某些情况下，分布式缓存不适用，例如单点资源的爆炸性峰值流量. 这时，使用本地缓存+分布式缓存. 本地缓存使用应用程序服务器上的少量内存资源来阻止少量的极端峰值流量. 长尾流量仍然访问分布式缓存. 通过混合多个应用程序服务器节点，这种混合缓存体系结构降低了系统的总体成本. 让我们看一下提要的存储结构. 微博的博客文章主要存在于MySQL中. 首先看一下内容表，这比较简单，每个内容一个索引，每天都会建立一个表，其次是索引表，总共会建立两个级别的索引. 首先想象一下用户场景. 当大多数用户轻扫微博时，他们会查看每个人的微博，然后按时间对其进行排序.

仔细分析表明，在这种情况下，与用户自己的相关性很小. 因此，在第一级索引中，将根据相关用户获取第一个微博ID，然后对其进行汇总和排序. 在进行散列（子和子表）时，我们还考虑通过UID和时间维度进行散列. 业务和时间非常相关，今天的热点新闻，明天将没有热量，冷热数据非常明显，这种情况需要根据时间维度分为表格，首先，冷热数据是（您可以将冷数据和热数据使用不同的存储方案来降低成本）. 其次，控制表的爆炸是非常宽容的. 如果微博仅根据用户维度进行区分，则该用户的所有数据都在表中. 该表无限期地增长，并且查询随着时间的流逝将变得越来越慢. 次要索引在我们中是一个特殊的场景，也就是说，当我想快速找到此人要发布的某个时期的微博时，我会通过次要索引快速定位. 分布式服务跟踪系统当系统达到1000万级别时，分布式跟踪服务系统变得越来越复杂，所解决的问题更倾向于稳定性，性能和监视. 刚刚说过，只要用户有一个请求，就可以依靠您的服务RPC1，RPC2，您会发现RPC2依赖于RPC3，RP. 分布式服务的一个痛点是，在用户提出请求后，它会在后台不断在不同机器之间进行调用和返回. 当您发现问题时，这些日志将放在不同的计算机上，并且您不知道问题出在哪里. 这些服务彼此隔离，并且它们之间没有关系.

因此，基本上没有办法对问题进行调查，但是无法解决问题. 我们要解决的问题，我们只是说日志是相互隔离的，因此我们必须与之建立联系. 建立联系时，我们将有一个请求ID，然后结合RPC框架，服务管理功能. 假设请求来自客户端，该客户端包含一个ID 101，并且到达服务A时仍具有ID 101，然后在调用RPC1为101时将被识别，因此需要唯一的请求ID来识别递归迭代传递到每个相关节点. 其次，当您执行此操作时，您不必说添加了每个位置. 对于业务系统，需要一个框架来完成这项工作. 该框架应该是对业务系统的最少干扰的原则. 如果使用JAVA，则可以使用AOP. 零入侵的原理是管理所有相关的中间件，从接口层组件（HTTP客户端，HTTP Server）到服务层组件（RPC客户端，RPC Server）以及数据访问中间件. 业务系统仅需要少量配置信息即可实现完整的链接监视. 为什么要使用日志？服务化后，考虑到多种开发语言的兼容性，每个服务可以使用不同的开发语言，内部定义标准化日志是唯一有效的方法. 最后，如何构建基于GPS导航的路况监控？我们刚刚谈到了分布式服务跟踪.

分布式服务跟踪可以解决的问题. 如果单个用户发现问题，则可以通过请求ID来快速找出发生问题的位置，但是这并不能解决如何查找问题. 我们将研究在现实中更容易理解的道路监控. 每辆汽车都有GPS定位. 我想看看北京拥挤的地方. 我该怎么办？第一个，您必须知道每辆车在哪里以及去了哪里. 实际上，可以说，每辆车上只要有一个徽标，再加上每条车流的信息，就可以看到每辆车流的位置和方向. 其次，如何进行监控和报警，如何了解路况和道路负荷，并及时报警. 我们需要定义这条街道的宽度和高度，以及每单位时间可以通过多少辆汽车. 这就是道路的通行能力. 有了道路通行能力和道路上的实时交通信息，我们可以根据实习路况做出预警吗？如何构造与分布式系统相对应的系统？首先，您需要定义每个服务节点的SLAA. 可以根据系统的CPU使用率，内存使用率，磁盘使用率，QPS请求等来定义SLA，这等效于定义系统的容量. 第二个是计算线路上的动态流量. 您需要知道服务的平均QPS，最小QPS和最大QPS. 通过流量和容量，您可以对系统进行全面的监视和警报. 我刚才所说的是理论. 实际情况肯定比这更复杂.

微博在春节期间进行了许多活动，必须确保系统的稳定性. 从理论上讲，您只需要定义容量和流量. 但这远非可行，为什么呢？有技术因素和人为因素，因为由不同的发展情况定义的流量和容量指标是主观的，并且难以在全球范围内量化标准. 因此，真正的流程来临时，您预先评估的系统瓶颈通常是不正确的. 实际上，我们在春节前主要采取了三项措施: 首先，最简单的是制定降级计划. 在流量超过系统容量（应首先切断功能）之后，需要明确优先级. 第二项是全链路压力测试，目的是将当前流量放大到正常流量的五倍甚至十倍（例如一半的脱机服务器，缩减而不是扩展），并查看系统瓶颈是否首先出现在哪里？是吗. 之前我们有一些示例，推测系统将首先出现瓶颈，但是实际测量发现前端程序首先遇到了瓶颈. 第三，构建一个Docker集群，所有企业共享闲置的Docker集群资源，可以大大避免为每个企业保留的资源，但实际上并没有因流量增加而造成浪费. 总结接下来所说的是如何继续学习和改进. 这里以Java语言为例，首先，您必须了解Java. 第二步，完成JAVA之后，您必须了解JVM. 仍然必须了解设计模式，它将告诉您如何抽象化过去的经验以供将来参考；还学习TCP / IP，分布式系统，数据结构和算法.

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