拆分

0 Web应用架构概述 ☀️

此处仅概述，详见各详细篇章

案例题内容提要：

• 软件架构风格（见前述） ☀️☀️☀️☀️
• 层次型软件架构风格 ☀️☀️☀️☀️
• 面向服务的软件架构风格 ☀️☀️☀️☀️
• 云原生架构风格 ☀️☀️☀️☀️
• 质量属性与架构评估 ☀️☀️☀️☀️☀️
• Web架构综合考查 ☀️☀️☀️☀️☀️

Redo!

演化方向：高性能、高可用、可维护、应变、安全……

维度	涉及技术内容
从架构来看	MVC、MVP、MVVM、REST、Web Service、微服务
从并发分流来看	集群（负载均衡）、CDN
从缓存来看	MemCache、Redis、Squid
从数据来看	主从库（主从复制）、内存数据库、反规范化技术、NoSQL、分区（分表）技术、视图与物化视图
从持久化来看	Hibernate、Mybatis
从分布存储来看	Hadoop、FastDFS、区块链
从数据编码来看	XML、JSON
从Web应用服务器来看	Apache、WebSphere、WebLogic、Tomcat、JBOSS、IIS
从安全性来看	SQL注入攻击
其他	静态化、有状态与无状态、响应式Web设计、中台

响应式Web设计（Responsive Web Design，RWD）：页面可根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。实现方式有流式布局（Fluid Grid）、弹性布局（Flex布局）（如弹性图片）、媒体查询等。

---

1 第一阶段：单体架构

单体架构（Monolithic Architecture）是软件开发初期的常见形态，整个应用程序被打包成一个单独的部署单元。在这个阶段，所有的业务逻辑、数据库访问、前端展示等都被封装在同一个应用程序中。单体架构开发简单、部署便捷，但随着业务的发展，系统变得庞大复杂，维护和扩展变得困难。

特点：

• 简单快速：初期开发效率高，部署简单。
• 耦合度高：各模块间紧密耦合，难以独立升级和扩展。

---

2 第二阶段：垂直架构

随着业务增长，单体架构逐渐暴露出性能瓶颈和可维护性问题。垂直架构（Vertical Architecture）通过将应用程序拆分为不同的服务（如用户服务、订单服务等），每个服务都运行在自己的进程中，并通过进程间通信（如HTTP REST API）进行交互。这种架构提高了系统的可扩展性和可维护性，但各服务之间仍然共享数据库和缓存等资源。

特点：

• 服务拆分：按业务功能拆分服务，提高可维护性。
• 资源共享：各服务间仍共享数据库等资源，存在瓶颈。

---

3 第三阶段：使用缓存改善网站性能

为了缓解数据库访问压力和提高网站响应速度，可以引入缓存（缓存）机制。缓存可以是本地缓存（Local Cache）（如内存中的数据结构）、分布式缓存（Distributed Cache）（如Redis、MemCache）等。

特点：

• 减少数据库访问：降低数据库压力，提高响应速度。
• 数据一致性挑战：需处理好缓存与数据库间数据一致性问题。

3.1 缓存技术对比

分布式数据库缓存：在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。

常见的缓存技术：

• MemCache：高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。通过在内存里维护一个统一的巨大的Hash表，来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。
• Redis（Remote Dictionary Server）：开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的APl。（使用最为广泛）
• Squid：高性能的代理缓存服务器，支持FTP、gopher、HTTPS和HTTP协议。

Redis与Memcache能力比较（重要）：

工作	MemCache	Redis
数据类型	简单key/value结构	丰富的数据结构
持久性	不支持	支持
分布式存储	客户端哈希分片/一致性哈希	多种方式，主从、Sentinel、Cluster等
多线程支持	支持	支持（Redis5.0及以前版本不支持）
内存管理	私有内存池/内存池	无
事务支持	不支持	有限支持
数据容灾	不支持，不能做数据恢复	支持，可以在灾难发生时，恢复数据（因为具有持久性）

3.2 Redis

3.2.1 分布式存储方案

Redis中常见的分布式存储方案及其核心特点：

1. 主从（Master/Slave）模式：一主多从，故障时手动切换
2. 哨兵（Sentinel）模式：有哨兵的一主多从，主节点故障自动选择新的主节点
3. 集群（Cluster）模式：不同slot的信息存储到不同节点（Node）。

集群切片的常见方式及其核心特点：

1. 客户端切片：【MemCache】在客户端通过key的hash值对应到不同的服务器。
2. 中间件实现切片：在应用软件和Redis中间，如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
3. 客户端服务端协作切片：【Redis的Cluster模式】客户端可采用一致性哈希，服务端提供错误节点的重定向服务slot上。不同的slot对应到不同服务器。

3.2.2 数据分片方案

Redis中常见的数据分片方案：

1. 范围分片：按数据范围值来做分片
   • 例：按用户编号分片，0 ~ 999999映射到实例A，1000000 ~ 1999999映射到实例B。
2. 哈希分片：通过对key进行hash运算分片
   • 把数据分配到不同实例。例如取余操作，余数相同的放在一个实例上。
3. 一致性哈希分片：哈希分片的改进
   • 利于扩展结点，可以有效解决重新分配节点带来的无法命中问题。

3.2.3 Redis数据类型

与MemCache不同，Redis提供了丰富的数据类型：

1. String（字符串）：二进制存储，可存任意类型数据，最大512MB。
   • 例：缓存，计数，共享Session
2. Hash（字典）：无序字典，数组+链表，适合存对象。一个Key对应一个HashMap，针对一组数据。
   • 例：存储、读取、修改用户属性
3. List（列表）：分为Linked List（双向链表，有序，增删快，查询慢）、Array List（数组方式，有序，增删慢，查询快）
   • 例：消息队列，文章列表；记录前N个最新登录的用户ID列表
4. Set（集合）：键值对无序，唯一。增删查复杂度均为O(1)，支持交/并/差集操作。
   • 例：独立IP，共同爱好，标签
5. Sorted Set(Zset，有序集合)：键值对有序，唯一，自带按权重排序效果。
   • 例：排行榜

3.2.4 数据淘汰算法

根据淘汰作用范围划分各种淘汰机制：

• 不淘汰
  1. noeviction：禁止驱逐数据。内存不足以容纳新入数据时，新写入操作会报错。【系统默认】
• 设置了过期时间的键空间
  2. volatile-random：随机移除某个key
  3. volatile-lru：优先移除最近未使用的key
  4. volatile-ttl：ttl值（数据的过期时间）小的key优先移出
• 全键空间
  5. allkeys-random：随机移除某个key
  6. allkeys-lru：优先移除最近未使用的key

3.2.5 持久化

持久性决定了数据库能否容灾，即决定了数据可靠性。（Redis支持事务的所有ACID特性，因此也能保证一致性）

Redis的持久化主要有两种方式：

• RDB（Redis Database Backup file）：传统数据库的快照思想。指定时间间隔对数据进行快照存储。
• AOF（Append Only File）：传统数据库的日志思想。把每条改变数据集的命令追加到AOF文件末尾，使得出问题时可通过重新执行AOF文件的命令来重建数据集。

对比：

对比维度	RDB	AOF
备份量	重量级的全量备份，保存整个数据库	轻量级增量备份，一次只保存一个修改命令
保存间隔时间	保存间隔时间长	保存间隔时间短，默认1秒
还原速度	数据还原速度快	数据还原速度慢
阻塞情况	save会阻塞，但bgsave或者自动不会阻塞	无论是平时还是AOF重写，都不会阻塞
数据体积	同等数据体积：小	同等数据体积：大
安全性	数据安全性低，容易丢数据	数据安全性高，根据策略决定

3.2.6 数据一致性操作

缓存与数据库中的数据可能不一致，解决方法如下。

1. 数据读取：
   • 操作步骤：
     1. 根据key从缓存读取
     2. 若缓存中没有，则根据key在数据库中查找
     3. 读取到“值”之后，更新缓存
   • 代码示例：

data = queryDataRedis(key);
if (data == null) {
    data = queryDataMySQL(key); // 缓存查询不到，从MySQL做查询
}
if (data != null) {
    updateRedis(key, data);     // 查询完数据后更新到Redis
}

2. 数据写入
   • 没有完全统一的做法。常见操作步骤：
     1. 根据key值写数据库
     2. 根据key更新缓存【或删除缓存】
   • 代码示例：

updateMySQL();      // 更新MySQL数据库
updateRedis(key, data); // 更新缓存

3.3 常见的Redis缓存问题及解决方案

3.3.1 缓存雪崩

情形：大部分缓存失效，造成数据库崩溃

解决方案：

1. 使用锁或队列：保证不会有大量线程对数据库一次性进行读写，从而避免失效时大量并发请求落到底层存储系统上。
2. 为key设置不同的缓存失效时间：在固定的缓存时间的基础上追加一个随机时间作缓存失效时间。
3. 二级缓存：设置有时间限制的缓存+无时间限制的缓存，避免大规模访问数据库。

3.3.2 缓存穿透与布隆过滤器

情形：查询无数据返回，直接查数据库

解决方案：

1. 若某次查询结果为空，则直接设置默认值存放到缓存，使得再次到缓冲获取时不再得到空值。设置不超过5分钟的过期时间，以便能正常更新缓存。
2. 设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一定不存在的数据会被其拦截，从而大幅减轻了对底层存储系统的查询压力。

布隆过滤器（Bloom Filter）：用于快速识别1个元素不在一个集合中。为解决传统哈希算法的哈希冲突问题，通过一个长二进制向量（bitmap）和一系列随机映射函数来记录与识别某个数据是否在一个集合中。（如下图所示）

优点：

1. 占用内存小
2. 查询效率高
3. 不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势

缺点：

1. 有一定的误判率，即存在假阳性，不能准确判断元素是否在集合中
2. 一般情况下不能从布隆过滤器中删除元素
3. 不能获取元素本身

3.3.3 其他缓存操作

缓存预热：系统上线后，将相关需要缓存数据直接加到缓存系统中。有如下几个具体方案——

1. 直接建立缓存刷新页面，上线时手工操作。
2. 数据量不大时，可以在项目启动的时候自动进行加载。
3. 定时刷新缓存。

缓存更新：除Redis系统自带的缓存失效策略，常见采用以下两种缓存更新方式——

1. 定时清理过期缓存。
2. 当用户请求时才判断该请求所用到的缓存是否过期，若过期则去底层系统得到新数据并更新缓存。

缓存降级：降级目的是保证核心服务可用（即使是有损的）；某些服务无法降级（如电商的购物流程等）；在进行降级前要对系统讲行梳理，从而梳理出哪些必须保护，哪些可降级。

---

4 第四阶段：使用服务集群改善网站并发处理能力

随着访问量的增加，单个服务实例已无法满足高并发需求。此时，可以通过将每个服务部署为多个实例来提高系统的并发处理能力，即服务集群（ServerCluster）。服务集群可以通过负载均衡器（如Nginx、HAProxy）进行流量分发，实现高可用性和扩展性。

特点：

• 高并发：通过增加服务实例提高系统处理能力。
• 负载均衡：合理分配请求到不同服务实例。

集群带来的两个问题及其解决方案：

1. 用户的请求由谁来转发到具体的应用服务器？——负载均衡
2. 若用户每次访问到的服务器不一样，则如何维护session的一致性？

4.1 负载均衡技术

负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

负载均衡有两方面的含义：

1. 大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间
2. 单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高

可在OSI七层模型中的应用层与传输层进行部署（一般传输层比应用层更高效），常见技术如下：

• 应用层：
  1. HTTP重定向（Redirect）（基于特定软件的负载均衡）：即应用层的请求转发。用户请求到达HTTP重定向负载均衡服务器时，服务器根据算法要求用户重定向，用户收到重定向请求后再次请求真正的集群。（例：弹出询问是否跳转到外链的页面）
     • 特点：实现简单，但性能较差。
  2. 反向代理（Reverse Proxy）服务器：用户请求到达反向代理服务器时（即到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的Apache、Nginx均可充当反向代理服务器。
     • 特点：部署简单，但代理服务器可能成为性能的瓶颈。
• 传输层：
  1. DNS域名解析负载均衡：用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。
     • 特点：效率比HTTP重定向高，减少维护负载均衡服务器成本。但应用服务器故障时无法及时通知DNS；且DNS负载均衡的控制权在域名服务商手里，网站无法做更多的改善和更强大的管理。
  2. 基于NAT的负载均衡：将1个外部IP地址映射为多个IP地址（内部节点），将每次连接请求动态转换为内部节点的地址。
     • 特点：技术较为成熟，一般在网关位置，可通过硬件实现。典型应用有四层交换机。

负载均衡算法：

• 静态算法（不考虑动态负载）
  1. 轮转算法：轮流将服务请求（任务）调度给不同的节点（即服务器）。
  2. 加权轮转算法：考虑不同节点处理能力的差异。
  3. 源地址哈希散列算法：将请求的源IP地址作为散列键，从静态分配的散列表中找出对应节点。
  4. 目标地址哈希散列算法：根据请求目标IP散列查找。
  5. 随机算法：随机分配。简单，但不可控。
• 动态算法（考虑动态负载）
  1. 最小连接数算法：新请求分配给当前活动请求数量最少的节点（前提：每个节点处理能力相同）。
  2. 加权最小连接数算法：考虑节点处理能力不同，按最小连接数分配。
  3. 加权百分比算法：考虑节点的利用率、硬盘速率、进程个数等，用利用率来表现剩余处理能力。

硬件负载均衡：F5

软件负载均衡：LVS、Nginx、HAproxy

4.2 有状态与无状态服务

无状态服务（Stateless Service）对单次请求的处理不依赖于其他请求。即处理一次请求所需的全部信息要么都包含在该请求里，要么可从外部获取到（如数据库），服务器本身不存储任何信息。【理想状态】

有状态服务（Stateful Service）则会在自身保存部分数据，先后请求存在关联（有交互）。

判断以下构件属于有状态还是无状态服务：

• Identification Bean（身份认证构件）——有状态
• ResPublish Bean（资源发布构件）——无状态
• ResRetrieval Bean（资源检索构件）——无状态
• OnlineEdit Bean（在线编辑构件）——有状态
• Statistics Bean（统计分析构件）——无状态

将有状态服务变为无状态——session共享机制。方案如下：

1. 客户端设置携带session的cookie
2. 服务器可同步session
3. 将session存储Redis【最常用】

---

5 第五阶段：数据库读写分离

为了进一步提升数据库性能，可以实施读写分离策略与主从复制（Master-Slave Replication）机制。

读写分离通过将数据库的读写操作分离到不同的数据库实例来实现，并通过保持数据的一致性。能够有效减少并发操作的锁争用，但会造成数据冗余，因此需要采用主从复制策略保持数据的一致性。

主从复制的其他优点：

1. 提升性能：交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。
2. 可扩展性更优：如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。
3. 提升可用性：一主多从，一台从服务器出现故障不影响整个系统正常工作。
4. 相当于负载均衡：一主多从分担任务，相当于负载均衡。
5. 提升数据安全性：系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。

在数据库的主从模式中，有1个主数据库（Master，写库）和1个或多个从数据库（Slave，读库）。主从数据库的结构特点如下：

• 一般情况下一主多从，也可以多主多从。
• 主库做写操作，从库做读操作。

主从复制一般采用日志方式，步骤如下：

1. 主库更新数据完成前，将操作写入二进制日志（binlog文件）。
2. 从库打开I/O线程与主库连接，做binlog dump process，并将事件写入中继日志（Relay Log）。
3. 从库执行中继日志事件，保持与主库一致。

为进一步减轻读库压力，对于文件服务器建立相对应的分布式缓存服务器（将既有的缓存技术推广至数据库领域）。分布式缓存技术详见Redis。

---

6 第六阶段：使用反向代理和CDN加速网站响应

为了进一步优化用户体验和减少网络延迟，可以使用反向代理（详见负载均衡，位于Web服务器之前，作为客户端和服务器之间的中间层）和CDN（Content Delivery Network，内容分发网络）。

特点：

• 加速响应：通过缓存和就近访问提高响应速度。
• 安全性提升：反向代理可增强Web服务器的安全性。

CDN的基本思想：尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。CDN是在互联网上完成的，将静态资源缓存到多个地理位置的节点上，根据用户请求的就近原则提供内容服务，从而加速网站响应。

---

7 第七阶段：使用分布式文件系统和分布式数据库系统

随着数据量的爆炸式增长，传统的文件系统和数据库系统已无法满足需求。分布式文件系统和分布式数据库系统通过将数据分散存储在多个节点上，并提供统一的访问接口来实现可扩展性和高可用性。这些系统通常采用数据冗余和复制机制来确保数据的可靠性和一致性。

特点：

• 高可扩展性：支持水平扩展以应对大规模数据存储需求。
• 高可用性：通过数据冗余和复制机制确保服务连续性。

---

8 第八阶段：使用NoSQL和搜索引擎

为了处理非结构化数据和实现复杂查询，可以引入NoSQL数据库（如MongoDB、Cassandra）和搜索引擎（如Elasticsearch、Solr）。NoSQL数据库不遵循传统关系型数据库的ACID原则，但提供了更高的灵活性和可扩展性。搜索引擎则通过索引技术实现了快速的全文搜索和复杂查询功能。

特点：

• 灵活可扩展：NoSQL数据库支持非结构化数据存储和水平扩展。
• 快速查询：搜索引擎提供高效的全文搜索和复杂查询能力。

---

9 第九阶段：业务拆分

随着业务复杂度的增加，可在负载均衡所进行的服务器分流的基础上，按照业务线进行更细致的拆分。每个业务线都包含一系列相关的服务，这些服务共同构成了一个独立的业务单元。

特点：

• 降低耦合度：不同业务线间保持独立，降低相互影响。
• 灵活扩展：各业务线可根据自身需求独立扩展和升级。

---

10 第十阶段：分布式服务

最终局面，系统演变为由多个分布式服务组成的复杂系统。这些服务通过微服务架构进行组织和管理，每个服务都专注于完成一项特定的业务功能。

---

11 案例分析练习

【例1】阅读以下关于分布式数据库缓存设计的叙述，回答问题1至问题3。
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。经过充分讨论，该公司最终决定采用刘工的方案。
问题1（9分）：
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。下表中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善下表中的空（1）~（6）。

问题2（8分）：
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请说明基本的Redis与原有关系数据库的数据同步方案。
问题3（8分）：
请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。
【解】
问题1：分布式数据库缓存是指在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
（1）多种数据结构；（2）不支持；（3）客户端哈希分片；（4）不支持；（5）有，私有内存池；（6）不支持
问题2：
（1）Memcache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2）Memcache不支持事务，所以操作过程中可能产生数据的不一致性。
同步方案：读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中。
问题3：
Redis分布式存储的常见方案：主从模式（Master/Slave）、哨兵模式（Sentinel）、集群模式（Cluster）
Redis集群切片的常见方式：
客户端切片：在客户端通过key的hash值对应到不同的服务器。
中间件实现切片：在应用软件和Redis中间，如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
客户端服务端协作切片：客户端可采用一致性哈希，服务端提供错误节点的重定向服务slot上。不同的slot对应到不同服务器。

【例2】某电子商务企业因发展良好，客户量逐步增大，企业业务不断扩充，导致其原有的B2C商品交易平台已不能满足现有业务需求。因此，该企业委托希赛公司重新开发一套商品交易平台。该企业要求新平台应可适应客户从手机、平板设备、电脑等不同终端设备访问系统，同时满足电商定期开展 “秒杀”、“限时促销”等活动的系统高并发访问量的需求。面对系统需求，希赛公司召开项目组讨论会议，制定系统设计方案。讨论会议上，王工提出可以应用响应式Web设计满足客户从不同设备正确访问系统的需求。同时，采用增加镜像站点、CDN内容分发等方式解决高并发访问量带来的问题。李工在王工的提议上补充，仅仅依靠上述外网加速技术不能完全解决高用户并发访问问题，如果访问量持续增加，系统仍存在崩溃可能。李工提出应同时结合负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等方法设计系统架构。项目组经过讨论，最终决定综合王王和李工的思路，完成新系统的架构设计。
问题1（5分）：
请用200字以内的文字描述什么是“响应式Web设计”，并列举2个响应式Web设计的实现方式。
问题2（16分）：
综合王工和李工的提议，项目组完成了新商品交易平台的系统架构设计方案。新系统架构图如图所示。请从选项（a）~（j）中为架构图中（1）~（8）处空白选择相应的内容，补充支持高并发的Web应用系统架构设计图。

（a）Web 应用层；（b）界面层；（c）负载均衡层；（d）CDN 内容分发；（e）主数据库；（f）缓存服务器集群；（f）缓存服务器集群；（g）从数据库；（h）写操作；（i）读操作；（j） 文件服务器集群
问题3（4分）：
根据李工的提议，新的B2C商品交易平台引入了主从复制机制。请针对B2C商品交易平台的特点，简要叙述引入该机制的好处。
【例】
问题1：响应式Web设计是指页面可根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。实现方式：流式布局、弹性布局、媒体查询。（三选二）
问题2：（1）为（d）；（2）为（c）；（3）为（f）；（4）为（a）；（5）、（6）为（e）、（h）；（7）、（8）为（g）、（l）。
问题3：
1、提升性能：交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。
2、可扩展性更优：如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。
3、提升可用性：一主多从，一台从服务器出现故障不影响整个系统正常工作。
4、相当于负载均衡：一主多从分担任务，相当于负载均衡。
5、提升数据安全性：系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。