极客时间已完结课程限时免费阅读

答疑丨互联网需要解决的技术问题是什么？

答疑丨互联网需要解决的技术问题是什么？-极客时间

答疑丨互联网需要解决的技术问题是什么？

2020-02-10 李智慧 来自北京
《后端技术面试 38 讲》
课程介绍

讲述：李智慧

时长12:30大小10.03M

目前互联网软件应用可以说是最主流的软件应用了，相应的，互联网分布式架构也成为最主要的系统架构方案。这个模块主要讲的就是互联网架构的一些知识内容，互联网架构技术关键点有很多，我在专栏中也试图在有限的篇幅内尽量多地覆盖这些技术关键点，但是依然有很多关键技术点未能展开讲述，文章中很多思考题其实也都是分布式系统的关键技术点，我在这里再进行一些回顾和补充。

专栏 22 篇分布式缓存架构的思考题

我们讲 Memcached 路由算法讲到余数 Hash 算法，但是，这种算法在 Memcached 服务器集群扩容，也就是增加服务器的时候，会遇到较大的问题，问题是什么呢？应该如何解决？
分布式缓存将多台服务器构建成一个集群，共同对外提供缓存服务，那么应用程序在读写缓存数据的时候，如何知道自己应该访问哪一台服务器呢？答案就是缓存路由算法，通过缓存路由算法计算得到缓存服务器的编号，进而和该服务器通信，读写缓存数据。
比较简单的路由算法就是余数 Hash 算法，利用 key 的 Hash 值对服务器列表长度取模，根据余数就可以确定服务器列表的下标。
比如说，缓存服务器集群中有 3 台服务器，根据 Key 的 Hash 值对 3 取模得到的余数一定在 0、1、2 三个数字之间，每一个数字都对应着一台服务器，根据这个数字查找对应的服务器 IP 地址就可以了。
使用余数取模这种方式进行路由计算非常简单，但这种算法有一个问题，就是当服务器进行扩容的时候会出现缓存无法命中的情况。比如说我们当前的服务器集群有 3 台服务器，当增加 1 台服务器的时候，对 3 取膜就会变成对 4 去取模，导致的后果就是以前对 3 取模的时候写入的缓存数据，对 4 取模的时候可能就查找不到了。
我们添加服务器的主要目的是提高缓存集群的处理能力，但是不正确的路由算法可能会导致整个集群都失效，大部分缓存数据都查找不到。
解决这个问题的主要手段是使用一致性 Hash 算法。一致性 Hash 首先是构建一个一致性 Hash 环的结构。一致性 Hash 环的大小是 0 到 2^32-1，实际上就是我们计算机中无符号整型的取值范围，这个取值范围 0 和最后一个值 2^32-1 首尾相连，构成了一个一致性 Hash 环。
然后我们将每个服务器的节点的 Hash 值放到环上，每一次进行服务器查找路由计算的时候，都是根据 Key 的 Hash 值顺时针查找距离它最近的服务器的节点。通过这种方式，Key 不变的情况下找到的总是相同的服务器。这种一致性 Hash 算法除了可以实现像余数 Hash 一样的路由效果以外，对服务器的集群扩容效果同样也非常好。
扩容的时候，只需要将新节点的 Hash 值放到环上。比如图中的的 NODE3 放入环上以后，只影响到 NODE1 节点，原来需要到 NODE1 上查找的一部分数据改为到 NODE3 上查找，其余大部分数据还能正常访问。
但是一致性 Hash 算法有一个致命的缺陷。Hash 值是一个随机值，把一个随机值放到一个环上以后，可能是不均衡的，也就是说某两个服务器节点在环上的可能距离很近，而和其它的服务器距离很远，这个时候就会导致有些服务器的负载压力特别大，有些服务器的负载压力非常小。而且在进行扩容的时候，比如说加入一个 NODE3，影响的只是 NODE1，而实际上加入一个服务器节点的时候，是希望它能够分摊其他所有服务器的一部分负载压力。
实践中，我们需要使用虚拟节点对算法进行改进。也就是说当把一个服务器节点放入到一致性 Hash 环上的时候，并不是把真实的服务器的 Hash 值放到环上，而是将一个服务器节点虚拟成若干个虚拟节点，把这些虚拟节点的 Hash 值放到环上去。在实践中通常是把一个服务器节点虚拟成 200 个虚拟节点，然后把 200 个虚拟节点放到环上。Key 依然是顺时针的查找距离它最近的虚拟节点，找到虚拟节点以后，根据映射关系找到真正的物理节点。
通过使用虚拟节点的方式，物理节点之间的负载压力相对比较均衡。加入新节点的时候，实际上是加入了 200 个虚拟节点，这些虚拟节点随机落在环上，会对当前环上的每个节点都有影响，原来的每个节点都会有一小部分数据访问落到新节点上。这样，既保证大部分缓存能够命中，保持缓存服务的有效性，又分摊了所有缓存服务器的负载压力，达到了集群处理能力动态伸缩的目的。

第 25 篇数据存储架构思考题

分布式架构的一个最大特点是可以动态伸缩，可以随着需求变化，动态增加或者减少服务器。对于支持分片的分布式关系数据库而言，比如我们使用 MYCAT 进行数据分片，那么随着数据量逐渐增大，如何增加服务器以存储更多的数据呢？如果增加一台服务器，如何调整数据库分片，使部分数据迁移到新的服务器上？如何保证整个迁移过程快速、安全？
上面我们讨论了缓存集群增加服务器的解决方案，对于分布式关系数据库而言，也需要增加服务器以增强集群负载处理能力。
和缓存的情况不同，缓存如果有部分数据不能通过缓存获得，还可以到数据库查找。上述的一致性 Hash 算法也确实会导致小部分缓存服务器中的数据无法被找到，但是大部分缓存数据能够找到，这样是不影响缓存服务正常使用的。
但如果分布式关系数据库中有数据无法找到，可能会导致系统严重故障。因此分布式关系数据库集群扩容，增加服务器的时候，要求扩容以后，所有数据必须正常访问，不能有数据丢失。所以数据库扩容通常要进行数据迁移，即将原来服务器的部分数据迁移到新服务器上。
那么哪些数据需要迁移呢？迁移过程中如何保证数据一致呢？
实践中，分布式关系数据库采用逻辑数据库进行分片，而不是用物理服务器进行分片。
比如 MySQL 可以在一个数据库实例上创建多个 Schema，每个 Schema 对应自己的文件目录。数据分片的时候就可以以 Schema 为单位进行分片，每个数据库实例启动多个 Schema。进行服务器扩容的时候，只需要将部分 Schema 迁移到新服务器上就可以了。路由算法完全不需要修改，因为分片不变，但是集群的服务器却增加了。
而且因为 MySQL 有主从复制的能力，事实上，在迁移的时候，只需要将这些 Schema 的从库配置到新服务器上，数据就开始复制了，等数据同步完成，再将新服务器的 Schema 设置为主服务器，就完成的集群的扩容。

第 21 篇分布式架构的思考题

互联网应用系统和传统 IT 系统面对的挑战，除了高并发，还有哪些不同？
这个问题其实是分布式架构知识点的总结，互联网需要解决的技术问题是什么，解决方案是什么，带来的价值是什么，都在其中了。
互联网应用因为要处理大规模、高并发的用户访问，所以需要消耗巨大的计算资源，因此采用分布式技术，用很多台服务器构成一个分布式系统，共同提供计算服务，完成高并发的用户请求处理。
除了高并发的挑战，互联网应用还有着高可用的要求。传统的企业 IT 系统是给企业内部员工开发的。即使是服务外部用户的，但是只要企业员工下班了，系统就可以停机了。银行的柜员会下班，超市的收银员会下班，员工下班了，系统就可以停机维护，升级软件，更换硬件。
但是互联网应用要求 7*24 小时可用，永不停机，即使在软件系统升级的时候，系统也要对外提供服务。而且一般用户对互联网高可用的期望又特别高，如果支付宝几个小时不能使用，即使是深夜，也可能会引起很大的恐慌。
而一个由数十万台服务器组成，为数亿用户提供服务的互联网系统，造成停机的可能性又非常大，所以需要在架构设计的时候，专门，甚至重点考虑系统的高可用。关于高可用的架构，我主要在第 29 篇高可用架构一篇进行了讨论。
互联网应用，除了高并发的用户访问量大，需要存储的数据量也非常大。淘宝有近十亿用户、近百亿商品，如何存储这些海量的数据，也是传统 IT 企业不会面对的技术挑战。关于海量数据的存储技术，我主要在25 篇数据存储架构进行了讨论。
有了海量的数据，如何在这些数据中快速进行查找，我在26 篇搜索引擎架构进行了讲解。如何更好地利用这些数据，挖掘出数据中的价值，使系统具有智能化的特性，我在31 篇大数据架构中进行了讨论。
传统企业 IT 系统部署在企业的局域网中，接入的电脑都是企业内部电脑，因此网络和安全环境比较简单。而互联网应用需要对全世界提供服务，任何人在任何地方都可以访问，当有人以恶意的方式访问系统的时候，就会带来安全性的问题。
安全性包含两个方面，一个是恶意用户以我们不期望的方式访问系统，比如恶意攻击系统，或者黄牛党、羊毛党通过不当方式获利。另一个是数据泄密，用户密码、银行卡号这些信息如果被泄漏，会对用户和企业都造成巨大的损失。30 篇安全性架构讨论的就是这方面的内容。
传统的 IT 系统一旦部署上线，后面只会做一些小的 bug 修复或者特定的改动，不会持续对系统再进行大规模的开发了。而互联网系统部署上线仅仅意味着开始进行一个新业务的打样，随着业务的不断探索，以及竞争对手的持续压力，系统需要持续不断地进行迭代更新。
如何使新功能的开发更加快速，使功能间的耦合更加少，需要在软件设计的时候进行考虑，这其实是专栏第二个模块软件的设计原理主要讨论的内容。而在架构模块，主要是在第 23 篇异步架构以及27 篇微服务架构进行了探讨。
互联网现在已经进入泛互联网时代，也就是说，不是只有互联网企业才能通过互联网为用户提供服务，各种传统的行业，所有为普通用户提供服务的企业都已经转向互联网了。可以说互联网重构了这个时代的商业模式，而以分布式技术为代表的互联网技术也必然重构软件开发与架构设计的技术模式。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 20

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
33 | 区块链技术架构：区块链到底能做什么？
下一篇
34 | 技术修炼之道：同样工作十几年，为什么有的人成为大厂架构师，有的人失业？
unpreview
 写留言

精选留言(13)

  • 千米完结
    2020-04-02
    理清了老师的思路脉络 学习了 谢谢老师
    7
  • escray
    2020-10-16
    比较喜欢这种答疑的方式，老师重新梳理了这个模块的内容，并且对留言中的一些问题进行了答复。 极客时间的专栏里面，也有只留思考题，不解答的，管杀不管埋…… 一致性 Hash 算法和分布式数据库分片都是可以拿出一篇文章单独讲的，在这里提纲挈领也挺好的。 “互联网需要解决的技术问题”串联起来了这个部分的全部内容，算是一个很好的知识地图，如何按图索骥就看个人了。
    展开
    5
  • 算法成瘾者
    2022-05-28
    终于找到了 简单易懂，深入浅出讲 一致性哈希算法应用于缓存和数据库的情况👍🏻
    1
  • java小霸王
    2022-07-10
    按照总结思路即复习了一遍 ，又串联了起来，这就是需要构建的知识树呀
  • 追梦
    2021-01-20
    非常佩服老师的思路总结
  • Jagger Chen
    2020-07-05
    老师您好，为什么将部分 Schema 迁移到新服务器上就可以了，而不需要修改路由算法？分片不变该如何理解？

    作者回复: 分片数就等于schema数，schema部署在哪里不影响路由算法。

    共 2 条评论
    1
  • 黑山老妖
    2020-06-15
    老师讲的非常清楚
  • 豁豁哒
    2020-04-21
    李老师好，图2所示，key0和key3本来在node1节点，现在加入node3节点，那么key0和key3会迁移到实际的node3节点吗？如果不会，那就是说key0和key3两个数据没了

    作者回复: 是的。 一致性Hash可以极大减少加入节点带来的缓存不命中，但是不能完全避免。

    1
  • LY
    2020-03-28
    感觉要学的东西好多，路漫漫其修远兮。。
  • LY
    2020-03-28
    一致性hash也是面试常考的题
  • Jonathan Chan
    2020-02-19
    感谢老师分享！学了老师的课程后，系统的帮我梳理整体脉络思路，感到非常受用。
  • QQ怪
    2020-02-17
    感谢老师的分享🙏
  • 许童童
    2020-02-11
    老师辛苦了！