如何解决与网络接口层安全性相关的问题(2)

微博使用了两层缓存，其中L1在上面. 每个L1是一个组（包含4到6台计算机）. 左侧的框等效于一个机房，而右侧的框则是另一个机房. L1高速缓存在此系统中的作用是什么？首先，L1高速缓存提高了整个系统的QPS，其次，以经济高效且灵活的方式增加了系统的带宽. 想象一个极端的情况，只有一个博客帖子，但是其流量无限增加. 实际上，我们不需要影响L2缓存，因为它的内容存储很小，但是访问次数却很多. 在这种情况下，您需要使用L1来扩展容量并增加QPS和带宽瓶颈. 另一种情况是L2缓存起作用. 例如反复出现您当前的网络存在链路层劫持，我有1000万用户，而我访问了100万用户的微博. 这时，他不仅说您的吞吐量和访问带宽是您的. 有很多博客文章要缓存. 这时，您需要考虑缓存的容量. 从容量的角度更计划第二级缓存，以确保请求以很小的比例渗透到后端中. 根据您的用户模型，您可以估计有多少百分比的请求无法穿透. 评估此容量之后，您可以更好地评估需要多少个库以及需要承受多少访问压力. 另外，如果我们查看双人间，则左边一间，右边一间. 这两个计算机机房相互处于活动或备用状态，或彼此处于热备用状态. 如果两个用户位于不同的区域并且他们访问两个不同的计算机机房，则假定该用户来自IDC1. 由于接近的原则，他将参观L1. 如果没有，他将奔向主人. 来到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时也将识别该请求，因此需要将唯一的请求ID递归传递给每个相关节点. 其次，当您这样做时，您不必说每个地方都被添加了. 对于业务系统，需要一个框架来完成这项工作. 对于业务系统，此框架必须是最不侵入的原则. 如果使用JAVA，则可以使用AOP. 为了实现零入侵的原理，必须注意所有相关的中间件，从接口层组件（HTTP客户端，HTTP Server）到服务层组件（RPC客户端，RPC Server）以及数据访问中间件. 业务系统仅需要少量配置信息即可实现完整的链接监视. 为什么要使用日志？提供服务后，每种服务都可以使用不同的开发语言. 考虑到多种开发语言的兼容性，内部定义标准化日志是唯一有效的方法. 最后，如何构建基于GPS的路况监控？我们刚刚谈到了分布式服务跟踪.

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

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

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