后端面试38讲_37_答疑丨互联网需要解决的技术问题是什么
你好，我是李智慧。
目前互联网软件应用可以说是最主流的软件应用了。
相应的互联网分布式架构也成为最主要的系统架构方案。
这个模块主要讲的就是互联网架构的一些知识内容。
互联网架构技术关键点有很多，我在专栏中也试图在有限的篇幅内尽量多的覆盖这些关键技术，但是依然有很多关键技术未能够展开。
文章中有很多思考题，其实也都是分布式系统的关键点。
我在这里再进行一些回顾和补充。
我在专栏二十二篇讲分布式缓冲架构。
提到这样一个问题，我们讲MMKHD路由算法的时候，讲到了余速哈希算法。
但是呢这种算法在MMKHD服务器集群扩容，也就是增加服务器的时候会遇到较大的问题，这是为什么呢？应该如何解决分布式缓存？将多台服务器构建成一个集群，共同对为提供缓冲服务。
那么应用程序在读取缓冲数据的时候，如何知道自己应该访问哪一台服务器呢？答案就是缓冲路由算法，通过缓冲路由算法计算得到缓冲服务器的编号，进而和该服务器通信读写。
缓冲数据比较简单的路由算法呢就是余数哈希算法。
利用k的哈希值对服务器列表长度取模，根据余数就可以确定服务器列表的下标。
比如说啊缓冲服务器集群有三台服务器，根据k的哈希值对三取模得到的余数一定在零一二三个数据之间，每个数字都对应着一台服务器。
根据这个数字查找对应的服务器IP地址就可以了。
使用余数取模这种方式进行路由计算非常简单。
但是这种算法有一个问题，那就是当服务器进行扩容的时候，会出现缓冲无法命中的情况。
比如说我们当前的服务器集群有三台服务器，当增加一台服务器的时候，对三取模就会变成对四取模导致的后果。
就是以前对三取模的时候写入的缓冲数据。
对，四取模的时候就可能查找不到了。
我们添加服务器的主要目的是提高缓冲集群的处理能力。
但是呢不正确的路由算法可能会导致整个集群都失效，大部分缓冲数据都查找不到了。
解决这个问题的主要手段是使用一次性哈希算法一致性哈希。
首先我们建一一一性哈希环的结构解决。
我个服器器的小是从零以前的三十二次方减一一际上就是我们计算机中无符符号整的取值范围。
这个取值范围零和最后一个值二的三次二次方减一首尾相连构成那个一致性哈希环。
然后我们将每个服务器的节点的哈希值放到环上，每一次进行服务器查找。
路由计算的时候，都是根据k的哈希值顺时针查找距离它最近的服务器的节点。
通过这种方式，k不变的情况下，找到的总是相同的服务器。
这种一致性哈希算法除了可以实现像榆树哈希一样的路由效果以外，对服务器的集群扩容效果也非常好。
扩容的时候，只需要将新节点的哈希值放到环上。
文章中有一张示意图，图中的node三放到环上以后，只影响到了node一的节点。
原先需要node一上查找的一部分数据改为到node三上进行查找。
大部分的数据还是能够正常的访问。
但是呢一致性哈希算法有一个致命的缺陷，大希值是一个随机值，把一个随机值放到一个环上以后，可能是不均匀的。
也就是说，某两台服务器节点在环上的距离可能很近，而和其他的服务器距离很远。
这个时候就会导致有些服务器的负载压力特别大，有些服务器的负载压力非常小。
而且在进行扩容的时候，比如说加入一个节点，note三影响的只有note一节点。
而实际上加入一个服务器节点的时候，是希望它能够分摊其他所有服务器的一部分负载压力。
实践中呢我们需要使用虚拟节点对算法进行改进。
也就是说，当把一个服务器节点放入到一致性哈希环上的时候，并不是把真实的服务器的哈希值放到环上，而是将一个服务器节点虚拟成若干个虚拟节点，把这些虚拟节点的哈希值放到环上去。
在实践中通常是把一个服务器节点虚拟成两百个虚拟节点，然后把两百个虚拟节点放到环上。
K依然是顺时针的查找距离。
它最近的虚拟节点找到虚拟节点以后，根据映射关系，再找到真正的物理节点。
通过使用虚拟节点的方式，物理节点之间的负载压力相对比较均衡。
加入新节点的时候呢，实际上是加入了两百个虚拟节点。
这些虚拟节点随机的落在环上，会对当前分片的每一个节点都有影响。
原来的每个节点都会有一部分数据访问到新的节点上。
这样既保证大部分缓冲数据，能够命中保持缓冲服务的有效性，又分摊了所有缓冲服务器的负载压力，达到了集群处理能力、动态伸缩的目标。
在第二十五篇中，我提到的分布式架构的最大一个特点是可以动态伸缩，可以随着需求变化动态增加或者减少服务器。
对于支持分片的分布式关系数据库而言，比如我们使用my cat进行数据分片，那么随着数据量逐渐增大，如何增加服务器以存储更多的数据呢？如果增加一台服务器，如何调整数据库的分片，使部分数据迁移到新的服务器上，如何保证整个迁移过程快速安全呢？在上面我们讨论了缓冲集群，增加服务器的解决方案。
对于分布式关系数据库而言，也需要增加服务器，以增强集群负载的处理能力和缓冲的情况不同缓冲。
如果有部分数据不能够通过缓存获得，还可以到数据库上去查找。
上述的一次性哈希算法也确实会导致小部分的缓冲服务器中的数据无法被找到。
但是大部分缓冲数据都能够找到，这样是不影响缓冲服务正常使用的。
但是，如果分布式关系数据库中有数据无法找到，就可能会导致严重的系统故障。
因此，分布式关系数据库集群扩容增加服务器的时候呢，要求扩容以后，所有服数据必须正常访问不能，有数据丢失。
所以数据库扩容通常要进行数据迁移，也就是将原来的服务器上的部分数据迁移到新服务器上。
那么，哪些数据需要迁移呢？迁移过程如何保证数据一致呢？实践中，分布式关系数据库采用逻辑数据库进行分片，而不是用物理服务器进行分片。
比如mysql可以在一个数据库实例上创建多个schema,每个schema对应自己的文件目录数据，分片的时候就可以以schema为单位进行分片。
每个数据库实例启动多个schema,进行服务器扩容的时候，只需要将部schemmer迁移到新的服务丢失就可以了。
路由算法完全不需要修改，因为分片不变，但是集群的服务器却增加了。
而且因为mysql有主从复制的能力，事实上在迁移的时候，只需要将这些schema的重库配置到新的服务器上，数据就开始复制了。
等数据同步完成，再将新服务器的schemle设置为主，服务器就完成了集群的扩容。
在第二十一篇中，我问到互联网应用系统和传统IT系统面对的挑战，除了高并发还有哪些？这个问题呢？其实是分布式架构知识点的总结。
互联网需要解决的技术问题是什么？解决方案是什么？带来的价值是什么？都在其中了。
互联网应用因为要处理大规模高并发的用户访问，所以需要消耗巨大的计算资源。
因此，采用分布式技术，用很多台服务器构成一个分布式系统，共同提供计算服务。
除了高并发的用户请求处理，除了高并发的挑战，互联网应用还有着高可用的要求。
传统的AT系统是给企业内部员工开发的，即使是服务外部用户，但是只要企业员工下班了，系统就可以停机了。
银行的柜员会下班，超市的收银员会下班，员工下班了，系统就可以停机维护，升级软件，更换硬件。
但是互联网应用要求七乘二十四小时可用，永不停机。
因此在软件系统升级的时候呢，系统也要对外提供服务，而且一般用户对互联网高可用的期望又特别高，关果支付宝几个小时不能够使用。
即使是深夜也会引起很大的恐慌，而一个由数十万台服务器组成，为数亿用户提供服务的互联网系统，造成停机的可能性又非常多。
所以需要在架构设计的时候，专门甚至重点考虑系统的高可用。
关于高可用的架构，我主要在第二十九片高可用架构一篇进行了讨论。
互联网应用除了高并发的用户访问量大，需要重储的数据量也非常大。
淘宝有近十亿用户，近百亿商品如何重储？这些海量的数据也是传统IT企业不会面对的技术挑战。
关于海量数据的重储技术，我主要在二十五篇数据重储架构进行了讨论。
有了海量的数据，如何在这些数据中快速进行查找？我在第二十六篇搜索引擎架构进行了讲解。
如何更好的利用这些数据挖掘出数据中的价值，使系统具有智能化的特性？我在第三十一篇大数据架构中进行了讨论。
传统企业IT系统部署在企业的局域网中，接入的电脑都是企业的内部电脑，因此网络和安全环境比较简单，而互联网应用需要对全世界提供服务，任何人在任何地方都可以访问。
当有人以恶意的方式访问系统的时候，就会带来安全性的问题。
安全性包含两个方面，一个是恶意用户，以我们不期望的方式访问系统，比如恶意攻击系统或者黄牛党羊毛党通过不当方式获利。
另一个是数据泄密、用户密码、银行卡。
这些信息如果被泄露，会对用户和企业造成巨大的损失。
三十篇安全架构讨论的就是这方面的内容。
传统的IT系统一旦部署上线，后面只会做一些小的bug修复或者特定的改动，不会持续对系统再进行大规模的开发了。
而互联网系统部署上线，仅仅意味着开始进行一个新业务的打样。
随着业务的不断探索以及竞争对手的持续压力，系统需要持续不断的进行迭代更新。
如何使新功能的开发更加快速，使功能间的耦合更加的少，需要在软件设计的时候进行考虑。
而这其实就是专栏。
第二个模块，软件设计原理讨论的内容。
而在架构模块，主要是在第二十三片异步架构以及二十七片微服务架构进行了探讨。
互联网现在已经进入到泛互联网时代。
也就是说啊不是只有互联网企业才通过互联网为用户提供服务。
各种传统的行业，所有为普通用户提供服务的企业都已经转向互联网了。
可以说互联网重构了这个时代的商业模式。
而以分布式技术为代表的互联网技术呢，也必然重构软件开发与架构设计的技术模式。