第7章分布式架构设计【流程在1000万以上如何架构设计】

本文链接：https://blog.csdn.net/wyz191/article/details/120300542

3、流程在1000万以上如何架构设计？

答：1000万以上的流量，除了负载均衡、应用集群，更大的性能瓶颈在于数据库。

（1）数据库瓶颈与数据库集群

基于Oracle RAC的数据库集群，是将数据库的计算分配到多个节点上，从而起到提升系统性能的目的。此外，为了保障数据一致性，需要在集群的每个节点与每个节点之间架设数据同步线。数据库集群不具备无限扩展的能力。这样的数据库架构没有办法满足不断拓展的用户流量需求。

（2）数据操作分析

用户访问系统的所有操作都可归纳为三种类型：业务操作、随机查询与统计分析。

业务操作：就是大量用户在系统中进行的短事务、高并发的写操作。最好的优化措施就是降低数据库索引的使用，以提高写入速度。

随机查询：就是大量的用户在少量的明细数据上进行的查询，这时，更多地使用数据库索引成为最佳优化措施。

统计分析：就是少量的管理人员对海量的数据进行大范围的分析统计，展现宏观的分析数据。将数据通过预处理提前统计，存放到数据仓库中，每次查询在数据仓库中进行，可以获得一个非常好的性能。同时，在索引使用上更多地采用位图索引而不是B树索引（通常在随机查询中建立的索引都是B树索引）

解决高并发、大数据问题的核心思想就是一个字：拆。将原有的一个数据库拆分成为多个数据库。拆的思路有两个：读写分离与数据分库。

（3）具体方案

1）读写分离的数据库设计

读写分离：就是将一个数据库拆分成多个数据库，一些数据库专门负责写，一些数据库专门负责读。然而，读写分离数据库设计的关键，在于如何实现从写库到读库的数据同步。

采用MySQL主从机的方式，写库与读库的同步是靠MySQL固有的实时热备功能实现，因此比较简单。正因为实时热备是一种备份的文字发，因此不能对从机做任何优化，只能被动地与主机保持一致。这种方案决定了不能对写库减少索引、对读库增加索引，只能分别对它们进行优化，有较大的局限。

真正的读写分离数据库设计方案，如下图：

将数据库分为生产机与查询机，生产机专门负责写，查询机专门负责读。生产机负责写入和实时性较高的当前数据查询。生产机只保留近期的数据就可以，从而有效地提高写入的性能。

查询机存储了所有数据，所以如何将生产机的数据实时同步到查询机中成为设计的关键。将需要实时查询的应用场景改为对生产机的查询，而将其他的查询交给查询机，并告知用户这些查询有一定的延时。也可以采用定时同步，错时查询、定时统计等方法。

如何实现从生产机到查询机的数据同步呢？如何生产机与查询机都采用Oracle数据库，则可以采用类似Oracle Golden Gate的数据同步方案。未来越来越多的采用异构的方案，即生产机采用关系型数据库，而查询机采用NoSQL数据库。

2）数据分库设计

对生产机最重要的优化之一就是数据分库，即将写入的数据分散存储在多个数据库节点中，从而突破数据库的I/O瓶颈，实现性能的提升。

当今数据库设计有两大核心思想：Shared Disk与Shared Nothing，Oracle RAC集群是基于Shared Disk的思想设计的，它将计算节点拆分到多个节点进行分布式计算，然而最终的磁盘读写却采用了集中式存储。

注：数据库构架设计中主要有Shared Everthting、Shared Nothing、和Shared Disk：

(1)Shared Everthting：一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer。

(2)Shared Disk：将计算节点拆分到多个节点进行分布式计算，最终的磁盘读写采用集中式存储；各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac，它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能。可以很好的满足数据一致性要求，集中式存储成为了数据库的瓶颈，无法承载更大的系统吞吐量。

(3)Shared Nothing：将数据分布式存储在多个计算节点，每个节点只访问本地磁盘，相互不共享；各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和hadoop ，各节点相互独立（避免各节点之间的通信），各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。虽然获得了系统性能与吞吐量，但损失了数据一致性。

我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。

3）纵向切分

数据库的纵向切分就是按照业务模块将一个数据库切分成多个数据库，每个模块对应一个数据库。纵向切分会带来跨库的事务处理及跨库的关联查询问题，处理不好会带来系统的性能问题。

4）微服务

纵向切分就是按照业务模块将一具庞大的业务系统进行拆分，实现分而治之的目的。从这个角度进一步扩展，从数据库扩展到整个系统，那就是微服务的设计思想。微服务架构就是按照业务模块纵向地切分整个系统。它不仅切分了业务还切分了数据库，使得每个微服务都有自己独立的数据库，彼此独立运行。微服务的裂变带动着数据库的裂变，数据库被拆分得越来越细。这时，跨库的事务处理与跨库的关联查询，就成了微服务永远绕不开的设计难题。

5）横向切分与分布式数据库

解决20%的功能有80%的用户使用的问题。

横向切分，在应用层面，就是为某个功能模块的微服务部署多个节点，以此来应对系统的高并发。同时，在数据库层面，就是将数据库中的某些表（数据量与并发压力大的表）按照某个字段或者算法进行分区，将该表的数据有序地存储在多个数据库节点中。

横向切分按照切分的方式又分为范围存储与分片存储。

范围存储，就是根据某个字段的分区将数据存储在不同的数据库节点中，如按照地域切分、按照时间切分等。范围存储虽然比较容易理解，但数据的分布依然不够均匀。

分片存储，就是对某个key值进行hash算法；分片存储的优势是数据分布会非常均匀，每个数据库的数据量都差不多。但分片存储会带来查询困难的问题，如果每次都根据标识符进行单用户查询，运用hash算法可以快速定位该数据在哪个节点上，查询速度非常快。该设计主要应用在生产机上，主要进行写入与单用户查询。将所有的数据同步到查询机上，在查询机上进行综合检索查询。