后端面试38讲_28_25_数据存储架构如何改善系统的数据存储能力
你好，我是李智慧。
在整个互联网系统架构中呢，承受着最大处理压力。
最难易被伸缩的就是数据重储。
部分。
原因主要有两个方面，一方面数据重储需要使用硬盘，而硬盘的处理速度比其他移动计算资源，比如CPU内存、网卡都要慢一些。
另一方面呢，数据是公司最主要的资产，公司需要保证数据的高可用以及一致性，非功能性约束更多一些。
因此，数据重储通常都是互联网应用的瓶颈，在高并发的情况下，最容易出现性能问题的就是数据重储。
目前用来改善数据存储能力的主要手段，包括数据库主重复制、数据库、分片和mysql数据库。
我们以mysql为例，看一下数据库主重复制的实现技术以及应用场景mysq l主重复制制的时义。
这是将mysql主数据库库中的数据复制到从数据库中。
从主要的复制原理是当应用程序客户端发送一条更新命令到主数据库服务器的时候，数据库就会把这条更新命令同步记录到bin NGG.然后由另外一个线程从b in log中读取这条日志，通过远程通信的方式，将它复制到从服务器上面去。
从服务器获取到这条更新日志以后，将其将入入到自己的rel log中，然后由另外一个sql执行线程从来relog中读取这条新的日志，并把它在本地的数据库中重新执行一遍。
这样当客户端应用程序执行一个update命令的时候呢，这个命令会同时在主数据库和从数据库上执行，从而实现了主数据库向从数据库的复制，让主数据库和从数据库保持一样的数据。
通过数据库主重复制的方式呢，我们可以实现数据库读写分离，有操作访问主数据库、读操作访问主数据库，使数据库具有更强大的访问负载能力，支撑更多的用户库离。
在实践中通常会使用一组多重的数据复制方案。
也就是说，一个主数据库将数据复制到多个重数据库上去，多个重数据库承担更多的读操作方力以及不同的角色。
比如有的从数据库用来做实时数据分析。
有的从数据库用来做批任务报表计算。
有的呢单重做数据备份，采用一组多重的方案。
当某个从数据库宕机的时候呢，还可以将读操作迁移到其他重数据库上，保证读操作的高可用。
但是如果主数据库宕机了，系统就没办法使用了。
因此在现实中也会采用mysql主组复制的方案。
也就是说呢，两台服务器互相备份，任何一台服务器都会将自己的bein log复制到另外一台服务器的rel. Log中保持两台服务器的数据一致，使使持主组务器需数据意库主组组复制，仅仅用来提升据据写操作可可用性不能用来来升写写操作的性能。
任何时候系统中都只能有一个数据库作为主数据库。
也就是说啊所有的应用程序都须连接到同一个主数据库进行写操作。
只有当该数据库当机失效的时候候，才才会将写操作切换到另一台主数据库上，使样才够保证数据库数据的一致性，不会出现数据冲突。
此外，不管是主重复制还是主主复制，都无法提升数据库的重储能力。
也就是说，不管增加多少服务器，这些服务器重储的数据都是一样的。
如果数据量太大，数据库无法重下这么多的数据，通过数据库复制是无法解决问题的。
我上面说到数据库主重复制，无法解决数据库的重储问题，但是数据库分片技术可以解决，也就是说将一张表的数据先分成若干片，每一片都包含了数据表中的一部分记录，然后每一片存储在不同的服务器上，这样一张表就存储在多台服务器上了。
最简单的数据库分片重储可以采用硬编码的方式，在代码中直接指定一条数据库记录，要存放到哪个服务器上。
比如将用户表分配成两片存储在两台服务器上，那么就可以在程序代码中根据用户ID进行分片计算，ID为偶数的用户记录存储到服务器一，ID为基数的用户记录存储到服务器二。
但是硬编码的方式缺点也比较明显。
首先，如果要增加服务器，那么就必须要修改分片逻辑代码，这样程序代码就会因为非业务需求而产生不必要的变更。
其次，分片逻辑耦合。
在处理业务逻辑的程序代码中，其改分片逻辑后，再修改业务代辑，都可能会使另一部分代码因为不小心的改动而出现bug.因此呢我们通常通过使用分布式关系数据库中间件来解决这个问题。
将数据的分片逻辑在中间件完成，对应用程序透明。
比如说my cat应用程序，像使用mysql数据库一样连接mirct,提交circle命令。
My cat在收到circle命令以后，查找配置的分片逻辑规则。
比如上图例子中，根据地区进行数据，分片不同地区的订单存储在不同的数据库上。
那么my cket就可以解析出csql中的地区字段。
Pro根据这个字段连接相对应的数据库，比如mysql中的地区，字段是武汉。
而在my cat中，配置武汉，对应的数据库是DB一用户提交的这条circle,最终会被发送给DB一数据库进行处理。
实践中更常见的数据分片算法，是我们所熟悉的语数哈希算法，根据组件ID和服务器的数目进行取模复算。
根据语数连接相对应的服务器，我在上面提到了关系数据库的主重复制，逐组复制数据库分片这几种改善数据读写以及重储能力的技术方案。
事实上这几种案可以根据应用场景的需要混合部署。
也就是说啊可以在一个系统中混合应用以上多种技术方案，对于数据库访问和重组压力不太大对可用性要求也不太高的系统。
也许部署在单一服务器上的数据库就可以解决了。
所有的应用服务器都连接访问这一台数据库服务器，如果访问量比较大，同时对数据可用性要求也比较高，那么就需要使用数据库主从复制技术将数据库部署在多台服务器上。
随着业务复杂度以及数据重储和访问压力的增加，这时候可以选择业务分库，也就是说将不同的业务相关的数据库表部署在不同的服务器上。
比如类目数据和用户数据相对关联，关系不太大，服务的应用也不一样。
那么就可以将这两类数据库部署在不同的服务器上。
而每一类数据库还可以继续选择主从复制或者主主复制不同的业务数据库及数据库。
重储的数据和访问压力也是不同的。
比如用户数据库的数据量和访问量，就可能是类目数据库的几十倍甚至上百倍。
那么这个时候就可以针对用户数据库进行数据分片，而每片数据库还可以继续进行主从复制或者主主复制。
Nosql数据库呢是改善数据存储能力的一个重要手段。
N cyq l数据库和传统的关系型数据库不同，它主要的问问式式不是使用circle进行产品，那是使用k value的方式进行数据访问，所以被称为cyql数据库。
Nosql数据库主要用来解决大规模分布式数据的存储问题。
常用的NOSQL据库库HBAEECECEREDIS虽然是一个分布式缓存技术产品，但有时候也被归类为no sql数据库。
E sql数据库面临的挑战之一就是数据一致性问题。
如果数据分布存储在多台服务器组成的集群上，那么当由服务器节点失效的时候，或者服务器之间网络通信故障的时候，不同用户读取的数据就可能会不一样。
比如用户一连接到服务器节点，i用户二连接到服务器节点b当这两个用户同时修改某个数据的时候，如果正好服务器a和服务器b之间的网络通信失败，那么这两个节点上的数据也就不一致了。
其他用户访问这个数据的时候，就可能会得到不一样的结果。
关于分布式存储系统有一个著名的CAP原理。
Cap原理是说，一个提供数据服务的分布式系统，无法同时满足数据一致性、可用性和分区耐受性。
这三个条件一致性是说每次读取的数据都应该是最近写入的数据，或者是返回一个错误，而不是一个过期数据。
也就是说，数据是一致的，可用性是说每次请求都应该得到一个响应，而不是返回一个错误或者失去响应。
不过这个响应不需要保证写入数据是最近写入的。
也就是说，系统需要一直都是可以正常使用的，不会引起调用者的异常。
但是并不保证响应的数据是最新的分区耐受性。
是说，即使因为网络原因，网络分区失效的时候，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的。
Cap原理说的就是当网络分区失效发生的时候，我们要么取消操作，保证数据是一致的。
但是系统却不可用，要么继续写入数据，但是数据的一致性就得不到保证了。
对于一个分布式系统而言，网络失效是一定会发生的。
也就是说，分区耐受性是必须要保证的。
而对于互联网应用来说，可用性也是必须要保证的。
分布式重储系统通常需要在一致性上做一些妥协和增强看三卷。
解决数据一致性的方案是在用户写入数据的时候，将一个数据写入到集群中的三个服务器节点，至少等待两个节点响应写入成功。
而在用户读取数据的时候，从三个节点尝试读取之上，至少等到两个节点返回数。
这并根据数据数据的时间戳选取最新版本的数据。
这样即使服务器中的数据不一致，但是呢最终用户还是能够得到一个一致的数据，这种方案也被称为是最终一致性。
至人说啊，架构是一门关于权衡的艺术，这一点在数据重储架构上表现的最为明显。
由于数据重储的挑战性、复杂性，无论你选择何种技术方案，都会带来一些新的问题和挑战。
而据重储架构没有隐淡，没有一劳永逸的解决方案，唯有在深刻理解自己的业务场景和各种分布式存储技术特点的基础之上，进行各种权衡，考虑选择最合适的解决方案，并想办法弥补其缺陷，才能够真正的解决问题。
我在架构模块第一篇就讨论了垂直伸缩和水平伸缩这两种不同的架构思路。
因为各种原因，互联网应用主要采用的是水平伸缩。
也就是说各种分布式技术。
事实上，在数据存储方面，有时候采用垂直伸缩，也就是使用更好的硬件服务器部署数据库，也是一种不错的改善数据存储能力的手段。
分布式架构的最大一个特点就是可以动态伸缩，可以随着需求变化动态增加或者减少服务器。
对于支持分片的分布式关系数据库而言，比如我们使用my cat进行数据分片。
那么随着数据量逐渐增大，如何增加服务器以存储更多的数据呢？那么增加一台服务器如何调整数据，分片使部分数据迁移到新的服务器上，如何保证整个迁移的过程快速安全呢？欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友，或者同事一起交流一下。