[Redis#1] 前言 | 再谈服务端高并发分布式结构的演进

运用：我们采用的解决办法是这样的，保留一个主要的数据库作为写入数据库，其他的数据库作为从属数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据。
优点：然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。由于大部分的系统中，读写请求都是不成比例的，例如++100次读1次写，所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了。++
问题：当然这个过程不是无代价的，主库到从库的数据同步其实是有时间成本的，但这个问题我们暂时不做进一步探讨。
解决方案：保留一个主数据库用于写入，其他从数据库用于读取，通过数据同步保持一致性。
相关软件 ：数据库中间件（MyCat、TDDL、Amoeba、Cobar等）。

5 引入缓存 - 冷热分离架构

随着访问量继续增加，发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率。我们把这部分数据称为热点数据，与之相对应的是冷数据。
适用场景：读取频率高的热点数据增加。读取频率高的热点数据增加。

解决方案 ：使用本地缓存和分布式缓存（Memcached、Redis）减少数据库压力。
面临问题：缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等。

6 垂直分库

随着业务的数据量增大，大量数据存储在同一个库中已经显得有些力不从心了，所以可以按照业务，将数据分别存储。

例如针对评论数据 ，可按照商品ID进行hash，路由到对应的表中存储；
针对支付记录 ，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。

只要实时操作的表数据量足够小，请求能够均匀地分发到多台服务器上的小表，数据库就能通过水平扩展的方式来提高性能。

其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。
这种做法显著增加了数据库运维的难度，对DBA的要求较高。
数据库设计到这种结构时，已经可以称为分布式数据库。

但是这只是⼀个逻辑的数据库整体，数据库⾥不同的组成部分是由不同的组件单独来实现的

如分库分表的管理和请求分发，由Mycat实现
SQL的解析由单机的数据库实现
读写分离可能由⽹关和消息队列来实现
查询结果的汇总可能由数据库接口层来实现等等

这种架构其实是MPP （⼤规模并行处理）架构的⼀类实现。

适用场景：数据量增大，单库难以支撑。

解决方案：按业务将数据分库存储，使用Mycat等工具管理分库分表。
相关软件 ：分布式数据库（Greenplum、TiDB、Postgresql XC、HAWQ等）。

7 业务拆分 - 微服务

随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务，然后互相之间对数据的直接访问进⾏隔离

适用场景：业务复杂度增加，团队扩大。

解决方案 ：将业务拆分为独立的微服务，通过Gateway、消息总线等技术实现服务间的调用。

公共服务：安全中心、监控预警中心等。

总结

架构演进顺序：实际场景中可能同时存在多个问题，需根据具体情况灵活解决。
扩展接口：预留扩展接口以应对未来需求。
大数据架构 ：涉及数据采集、存储、分析、服务等多个环节，提供分布式存储、计算等能力。

突然回忆到了，博主之间对结构的一篇文章：【Linux详解】冯诺依曼架构 | 操作系统设计 | 斯坦福经典项目Pintos，重点摘要如下：

• 底层硬件：遵顼冯诺依曼体系系结构，通过内存为枢纽的数据数据交换，实现了降本增效，使得计算机走入百姓家中

• 驱动程序：操作系统管理系统管理硬键的重要手段，操作系统通过驱动程序获取硬件的信息，进而而实行管理

• 操作系统：计算机体系中的管理者，管理各种各样的软硬件资源，遵循先描述，再组织的重要思想，使得操作系统可以批量管理众多软硬件

• 系统调用接口：为了保证操作系统提供的服务是安全可靠的，通过系统调用接口来帮助用户访问问计算机，同时保护了操作系统内部的数据

• 用户操作接口：直接通过系统调用接口访问计算机会比较麻烦，于是通过用户操作接口以更加便捷的方式提供服务，并且提供了跨平台的特性，使得计算机的访问方便快捷

总结

应用（Application）/ 系统（System）

一个应用, 就是一个/组服务器程序

模块（Module）/ 组件（Component）

一个应用, 里面有很多个功能。每个独立的功能, 就可以称为是一个模块/组件

分布式（Distributed）

引入多个主机/服务器, 协同配合完成一系列的工作。（物理上

集群（Cluster）

引入多个主机/服务器, 协同配合完成一系列的工作。（逻辑上

主（Master）/ 从（Slave）

分布式系统中一种比较典型的结构~ ~
多个服务器节点, 其中一个是主, 另外的是从。从节点的数据要从主节点这里同步过来~ ~

中间件（Middleware）

和业务无关的服务(功能更通用的服务)

数据库
缓存
消息队列
...

可用性（Availability）

系统整体可用的时间 / 总的时间
360 / 365 => 可用性~ ~
4 个9即系统可以提供99.99% 的可用性，5 个9 是99.999%

响应时长（Response Time RT）

衡量服务器的性能
越小越好~ ~

吞吐（Throughput）vs 并发（Concurrent）

衡量系统的处理请求的能力。衡量性能的一种方式

分布式系统小结

1.单机架构 (应用程序 + 数据库服务器)

2.数据库和应用分离

应用程序和数据库服务器分别放到不同主机上部署了.

3.引入负载均衡, 应用服务器 => 集群

通过负载均衡器, 把请求比较均匀的分发给集群中的每个应用服务器.
当集群中的某个主机挂了, 其他的主机仍然可以承担服务.
提高了整个系统的可用性~ ~

4.引入读写分离, 数据库主从结构

一个数据库节点作为主节点, 其他N个数据库节点作为从节点.
主节点负责写数据, 从节点负责读数据.
主节点需要把修改过的数据同步给从节点~

上述四点，都是为了高效的处理更多的数据

5.引入缓存, 冷热数据分离

Redis 在一个分布式系统中, 通常就扮演着缓存这样的角色~ ~
引入的问题: 数据库和缓存的数据一致性问题~ ~

6.引入分库分表, 数据库能够进一步扩展存储空间

7.引入微服务, 从业务上进一步拆分应用服务器

从业务功能的角度, 把应用服务器, 拆分成更多的功能更单一, 更简单, 更小的服务器.

上述这样的几个演化的步骤, 只是一个粗略的过程.

实际上一个商业项目, 真实的演化过程, 都是和他的业务发展密切相关的.
业务是更重要的, 技术是给业务提供支持的.

所谓的分布式系统, 就是想办法引入更多的硬件资源!!