个人总结，仅供参考，欢迎加好友一起讨论
文章目录
系分 - 案例分析 - 数据库设计（分布式）
分布式数据库系统
透明性分类
两阶段提交协议2PC
2PC事务提交的两个阶段：
表决阶段，目的是形成一个共同的决定
执行阶段，目的是实现这个协调者的决定
两条全局提交规则：
只要有一个参与者撤销事务，协调者就必须做出全局撤销决定
只有所有参与者都同意提交事务，协调者才能做出全局提交决定
分区分表分库
| 分区 | 分表 | |
|---|---|---|
| 共性 | 1 都针对数据表 2 都使用了分布式存储 3 都提升了查询效率 4 都降低数据库的频繁I/O压力值 | |
| 差异 | 逻辑上还是一张表 | 逻辑上已经是多张表 |
分区技术
分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介质中，实际上还是一张表。
使用分区技术的优点：
- 减少维护工作量。独立管理每个分区比管理单张大表要轻松得多。
- 增强数据库的可用性。如果表的一个或几个分区由于系统故障而不能被使用，那么表其余的分区仍然可以使用；如果系统故障只影响表的一部分分区，那么，只有这部分分区需要修复，这就比修复整张大表耗费的时间少许多。
- 均衡I/O，减少竞争。通过把表的不同分区分配到不同的磁盘来平衡I/O改善性能。分区对用户保持透明。最终用户感觉不到分区的存在。
- 提高查询速度。对大表的查询、增加、修改等操作可以分解到表的不同分区中来并行执行。
数据分区技术一般分为水平分区和垂直分区，数据库中常见的是水平分区。水平分区分为范围分区、哈希分区、列表分区等。
- 范围分区（Range），按数据范围值来做分区。例：按用户编号分区，0-999999映射到分区A；1000000-1999999映射到分区B。
- 哈希分区（Hash），通过对key进行hash运算分区。例，可以把数据分配到不同分区，这类似于取余操作，余数相同的，放在一个分区上。
- 列表分区（List），根据某字段的某个具体值进行分区。例，长沙用户分成一个区，北京用户分成一个区。
| 范围分区 | 哈希分区 | 列表分区 | |
|---|---|---|---|
| 数据值 | 连续 | 连续、离散均可 | 离散 |
| 数据管理能力 | 强 | 弱 | 强 |
| 实施难度与可维护性 | 差 | 好 | 差 |
| 数据分布 | 不均匀 | 均匀 | 不均匀 |
分区的优点：
- 相对于单个文件系统或是硬盘，分区可以存储更多的数据。
- 数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可。
- 精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率。
- 可跨多个分区磁盘查询，来提高查询的吞吐量。
- 在涉及聚合函数查询时，可以很容易进行数据的合并。
数据库主从复制
主从数据库结构特点：
- 一般：一主多从，也可以多主多从。
- 主库做写操作，从库做读操作。
主从复制步骤：
- 主库（Master）更新数据完成前，将操作写binlog日志文件。
- 从库（Salve）打开I/O线程与主库连接，做binlogdump process，并将事件写入中继日志。
- 从库执行中继日志事件，保持与主库一致。
如下图：
NoSQL非关系型数据库
NoSQL，Not-only SQL，泛指非关系型数据库。
| NoSQL的使用场景 | NoSQL的缺点不足 |
|---|---|
| 1 数据模型比较简单 2 需要灵活性更强的IT系统 3 对数据库性能要求较高 4 不需要高度的数据一致性 5 对于给定key容易映射复杂值的环境 | 1 成熟度不够，大量关键特征有待实现 2 开源数据库产品的支持力度有限 3 数据挖掘与商务智能支持不足 4 现有的产品无法直接使用NoSQL 5 擅长NoSQL的专家较少 |
与关系型数据库对比
| 关系型数据库模式 | NoSQL | |
|---|---|---|
| 并发支持 | 支持并发，但效率低 | 并发性能高 |
| 存储与查询 | 关系表方式存储，SQL查询 | 海量数据存储，查询效率高 |
| 扩展方式 | 向上扩展 | 向外扩展 |
| 索引方式 | B树，哈希等 | 键值索引 |
| 应用领域 | 通用领域 | 特定应用领域 |
| 关系型数据库模式 | NoSQL | |
|---|---|---|
| 成本 | 花费巨大，成本高 | 部署简单，成本低，开源 |
| 查询速度 | 数据存储于硬盘中，SQL查询慢 | 数据存储于缓存中，查询速度快 |
| 存储数据类型 | 只支持基础数据类型，结构化 | 支持基础和对象，集合等非结构化类型 |
| 扩展性 | 多表查询，扩展复杂 | 基于键值对，容易水平扩展 |
| 持久存储 | 支持海量数据存储 | 数据在缓存中，不适用于持久存储 |
| 数据一致性 | 需要事务，强调数据的强一致性 | 不提供、弱事务处理，数据一致性较弱 |
| 数据容量 | 数据有限 | 海量数据 |
| 标准化 | 是 | 否 |
类型
键值Key - Value
键可是一个字符串对象，值可以是任意类型的数据。如整型、字符型、数组、列表、集合等。
列族数据库
分行式存储和列式存储。
文档数据库
图形数据库
缓存技术
常见缓存技术：
MemCache：Memcache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。
Redis：Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的APl。
Squid：squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。
思考：数据库与缓存数据是否有可能不一致？如何解决？
Redis
Redis与Memcache对比
| Memcache | Redis | |
|---|---|---|
| 数据类型 | 简单的Key-Value结构 | 丰富的数据结构 |
| 持久性 | 不支持 | 支持 |
| 分布式存储 | 客户端哈希分片/一致性哈希 | 多种方式，主从，Sentinel，Cluster等 |
| 多线程支持 | 支持 | Redis6.0开始支持 |
| 内存管理 | 私有内存池/内存池 | 无 |
| 事务支持 | 不支持 | 有限支持 |
| 数据容灾 | 不支持，不能做数据恢复 | 支持，可以在做数据恢复 |
Redis分布式存储方案
| 分布式存储方案 | 核心特点 |
|---|---|
| 主从（Master/Slave）模式 | 一主多从，故障时手动切换 |
| 哨兵（Sentinel）模式 | 有哨兵的一主多从，主节点故障自动选择新的主节点 |
| 集群（Cluster）模式 | 分节点对等集群,分slots，不同slots的信息存储到不同节点 |
Redis集群切片方式
| 切片方式 | 核心特点 |
|---|---|
| 客户单分片 | 在客户端通过key的hash值对应到不同的服务器 |
| 中间件实现分片 | 在应用软件和Redis中间，例如：Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派 |
| 客户端服务端协作分片 | 客户端与服务端协作完成分片处理 |
Redis数据分片方案
| 方案 | 分片方式 | 说明 |
|---|---|---|
| 范围分片 | 按数据范围值来做分片 | 例：按用户编号分片，0-999999映射到实例A；1000000-1999999映射到实例B。 |
| 哈希分片 | 通过key进行hash运算分片 | 可以把数据分配到不同实例,这类似于取余操作，余数相同的，放在一个实例上。 |
| 一致性哈希分片 | 哈希分片的改进 | 利于扩展结点，可以有效解决重新分配节点带来的无法命中问题。 |
Redis数据类型
| 类型 | 特点 | 示例 |
|---|---|---|
| String 字符串 | 存储二进制，任何类型数据，最大512MB | 缓存，计数，共享Session |
| Hash 字典 | 无序字典，数组+链表，适合存对象 Key对应一个HashMap，针对一组数据 | 存储、读取、修改用户属性 |
| List 列表 | 双向链表，有序，增删快，查询慢 | 消息队列，文章列表 记录前N个最新登录的用户ID列表 |
| Set 集合 | 键值对无序，唯一 支持交/并/差集操作 | 独立IP，共同爱好，标签 |
| Sorted Set [Zset] 有序集合 | 键值对有序，唯一，自带按权重排序效果 | 排行榜 |
Redis新的3种数据类型：
Bitmaps，位操作字符串
HyperLoglog
Geographic
持久化RDB和AOF
RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。
AOF：传统数据库中日志的思想，把每条改变数据集的命令追加到AOF文件末尾，这样出问题了，可以重新执行AOF文件中的命令来重建数据集。
| 对比 | RDB | AOF |
|---|---|---|
| 备份量 | 重量级的全量备份，保存整个数据库 | 轻量级增量备份，一次只保存一个修改命令 |
| 保存间隔时间 | 保存间隔时间长 | 保存间隔时间短，默认1秒 |
| 还原速度 | 数据还原速度快 | 数据还原速度慢 |
| 阻塞情况 | save会阻塞，但bgsave或者自动不会阻塞 | 无论是平时还是AOD重写，都不会阻塞 |
| 数据体积 | 同等数据体积：小 | 同等数据体积：大 |
| 安全性 | 数据安全性：低，容易丢数据 | 数据安全性：高，根据策略决定 |
淘汰与过期时间
| 淘汰作用范围 | 机制名 | 策略 |
|---|---|---|
| 不淘汰 | noeviction | 禁止驱逐数据，内存不足以容纳新入数据时，新写入操作就会报错。系统默认的一种淘汰策略。 |
| 设置了过期时间的键空间 | volatile-random | 随机移除某个key |
| volatile-lru | 优先移除最近未使用的key | |
| volatile-ttl | ttl值小的key优先移除 | |
| 全键空间 | allkeys-random | 随机移除某个key |
| allkeys-lru | 优先移除最近未使用的key |
Redis常见问题
缓存雪崩
大部分缓存失效，造成数据库崩溃。
解决：
- 使用锁或队列，保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
- 为key设置不同的缓存失效时间，在固定的一个缓存时间的基础上 + 随机一个时间作为缓存失效时间。
- 二级缓存，设置一个有时间限制的缓存 + 一个无时间限制的缓存。避免大规模访问数据库。
缓存穿透
查询无数据返回，直接查数据库。
解决：
- 如果查询结果为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
- 设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存预热
系统上线后，将相关需要缓存的数据直接加到缓存系统中。
解决：
- 直接写个缓存刷新页面，上线时手工操作。
- 数据量不大时，可以在项目启动的时候自动进行加载。
- 定时刷新缓存。
布隆过滤器用于快速识别一个元素不在一个集合中，通过一个长二进制向量和一系列随机映射函数来记录与识别某个数据是否在一个集合中。
缓存更新
除Redis系统自带的缓存失效策略，常见采用以下两种：
- 定时清理过期的缓存。
- 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
缓存降级
降级的目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（如电商的购物流程等)。
在进行降级之前要对系统进行梳理，从而梳理出哪些必须保护，哪些可降级。
Redis相关资料
| 知识地图： | |
|---|---|
| Redis概述与安装 https://blog.csdn.net/lili40342/article/details/127852124 | |
| Redis的5大数据类型 https://blog.csdn.net/lili40342/article/details/127897689 | |
| Redis的发布和订阅 https://blog.csdn.net/lili40342/article/details/127901009 | |
| Redis新的3种数据类型 https://blog.csdn.net/lili40342/article/details/127903901 | |
| Jedis操作Redis6 https://blog.csdn.net/lili40342/article/details/127904568 | |
| SpringBoot2整合Redis https://blog.csdn.net/lili40342/article/details/127915177 | |
| Redis事务操作 https://blog.csdn.net/lili40342/article/details/127915924 | |
| Redis持久化之RDB(Redis DataBase) https://blog.csdn.net/lili40342/article/details/127938199 | |
| Redis持久化之AOF(Append Only File) https://blog.csdn.net/lili40342/article/details/127938233 | |
| Redis主从复制 https://blog.csdn.net/lili40342/article/details/127942076 | |
| Redis哨兵(Sentinel) https://blog.csdn.net/lili40342/article/details/127942838 | |
| Redis集群(Cluster) https://blog.csdn.net/lili40342/article/details/127942123 | |
| Redis应用问题解决(缓存穿透、击穿、雪崩、分布式锁) https://blog.csdn.net/lili40342/article/details/127942407 | |
典型例题 1
题目描述
阅读以下关于数据库分析与建模的叙述，在答题纸上回答问题1至问题3。
某电子商务企业随着业务不断发展，销售订单不断增加，每月订单超过了50万笔，急需开发一套新的互联网电子订单系统。同时该电商希望建立相应的数据中心，能够对订单数据进行分析挖掘，以便更好地服务用户。
王工负责订单系统的数据库设计与开发，初步设计的核心订单关系模式为：orders（order_no，customer_no，order_date，product_no，price，……）。
考虑订单数据过多，单一表的设计会对系统性能产生较大影响，仅仅采用索引不足以解决性能问题。因此，需要将订单表拆分，按月存储。
王工采用反规范化设计方法来解决，给出了相应的解决方案。李工负责数据中心的设计与开发。李工认为王工的解决方案存在问题，建议采用数据物理分区技术。在解决性能问题的同时，也为后续的数据迁移、数据挖掘和分析等工作提供支持。
【问题1】
常见的反规范化设计包括增加冗余列、增加派生列、重新组表和表分割。为解决题干所述需求，王工采用的是哪种方法？请用300字以内的文字解释说明该方法，并指出其优缺点。
【问题2】
物理数据分区技术一般分为水平分区和垂直分区，数据库中常见的是水平分区。水平分区分为范围分区、哈希分区、列表分区等。请阅读下表，在（1）～（8）中填写不同分区方法在数据值、数据管理能力、实施难度与可维护性、数据分布等方面的特点。
【问题3】
根据需求，李工宜选择物理水平分区中的哪种分区方法？请用300字以内的文字分别解释说明该方法的优缺点。
参考答案
【问题1】
王工采用的是表分割方式中的水平分割（分割参数是：“月”，不同的月份使用不同的关系表）。
表分割包括水平分割与垂直分割两种形式：
水平分割：按记录进行分割，不同的记录可以分开保存，每个子表的列数相同。分割的条件可能是某列或多
列数据的值，如时间参数。
垂直分割：按进行分割，即把一条记录分开多个地方保存，每个子表的行数相同。把主键和一些行放到一个
表，然后把主键和另外的列放到另一个表中，通过主键进行关联。
王工采用水平分割的优点：水平分割后可以降低在查询时需要读取的数据和索引页数，同时也降低了索引的层数，
提高查询速度。同时，按月存储有利于数据迁移、备份和管理。
缺点：逻辑上破坏了关系概念的完整性，由一个关系变为多个关系，在进行历史数据挖掘和分析时，需要执行集
合并操作，处理起来比单表操作更加复杂。
【问题2】
（1）连续 （2）离散 （3）弱 （4）强 （5）不好 （6）不好 （7）不均匀 （8）均匀
【问题3】
李工宜选择范围分区方式。
范围分区优点如下：
（1） 分区表可以将表存储到多个表空间内，各个分区维护各自的本地索引，查询语句可以根据索引进行
分区范围查找，提高了查询速度。
（2） 范围分区提供良好的数据迁移、备份和管理能力，利于维护。
（3） 实现容易，而且可以方便地对表的分区进行添加、删除、拆分和合并操作。
范围分区缺点：
随着时间的增加，日期数据发生变化，DBA需要对分区进行维护，以增加新的分区。数
据在分区上不均匀。可维护性上比较差，所以可以与哈希分区组合应用。
典型例题 2
题目描述
阅读以下关于数据管理的叙述，在答题纸上回答问题1至问题3。
某全国连锁药店企业在新冠肺炎疫情期间，紧急推出在线口罩预约业务系统。该业务系统为普通用户提供口罩商品查询、购买、订单查询等业务，为后台管理人员提供订单查询、订单地点分布汇总、物流调度等功能。该系统核心的关系模式为预约订单信息表。
推出业务系统后，几天内业务迅速增长到每日10万多笔预约订单，系统数据库服务器压力剧增，导致该业务交易响应速度迅速降低，甚至出现部分用户页面无法刷新、预约订单服务无响应的情况。为此，该企业紧急成立技术团队，由张工负责，以期尽快解决该问题。
【问题1】
经过分析，张工认为当前预约订单信息表存储了所有订单信息，记录已达到了百万级别。系统主要的核心功能均涉及对订单信息表的操作，应首先优化预约订单信息表的读写性能，建议针对系统中的SQL语句，建立相应索引，并进行适当的索引优化。
针对张工的方案，其他设计人员提出了一些异议，认为索引过多有很多副作用。请用100字以内的文字简要说明索引过多的副作用。
【问题2】
作为团队成员之一，李工认为增加索引并进行优化并不能解决当前问题，建议采用物理分区策略，可以根据预约订单信息表中“所在城市”属性进行表分区，并将每个分区分布到独立的物理磁盘上，以提高读写性能。常见的物理分区特征如下表所示。李工建议选择物理分区中的列表分区模式。
请填补下表中的空（a）~（d）)处，并用100字以内的文字解释说明李工选择该方案的原因。
【问题3】
在系统运行过程中，李工发现后台管理人员执行的订单地址信息汇总等操作，经常出现与普通用户的预约订单操作形成读写冲突，影响系统的性能。因此李工建议采用读写分离模式，采用两台数据库服务器，并采用主从复制的方式进行数据同步。请用100字以内的文字简要说明主从复制的基本步骤。
参考答案
【问题1】
索引过多的副作用有：
（1）过多的索引会占用大量的存储空间。
（2）更新开销，更新语句会引起相应的索引更新。
（3）过多索引会导致查询优化器需要评估的组合增多。
（4）每个索引都有对应的统计信息,索引越多则需要的统计信息越多。
（5）聚集索引的变化会导致非聚集索引的同步变化。
【问题2】
（a）属性的离散值 （b）周期性数据/周期数据 （c）能力强 （d）均匀
李工建议根据预约订单所在城市进行表分区，而所在城市属性为离散值，根据所在城市属性建立列表分区，也方便不同城市处理自己的数据，方便数据管理。
【问题3】
主从复制的基本步骤：
（1）主服务器将所做修改通过自己的I/O线程，保存在本地二进制日志中。
（2）从服务器上的I/O线程读取主服务器上面的二进制日志，然后写入从服务器本地的中继日志。
（3）从服务器上同时开启一个SQL thread，定时检查中继日志，如果发现有更新则立即把更新的内容在本机的数据库上面执行一遍。
典型例题 3
题目描述
某软件企业开发了一套新闻社交类软件，提供常见的新闻发布、用户关注、用户推荐、新闻点评、新闻推荐、热点新闻等功能，项目采用MySQL数据库来存储业务数据。系统上线后，随着用户数量的增加,数据库服务器的压力不断加大。为此，该企业设立了专门的工作组来解决此问题。
张工提出对MySQL数据库进行扩展，采用读写分离，主从复制的策略，好处是程序改动比较小，可以较快完成，后续也可以扩展到MySQL集群，其方案如下图所示。
李工认为该系统的诸多功能，并不需要采用关系数据库，甚至关系数据库限制了功能的实现，应该采用NoSQL数据库来替代MySQL，重新构造系统的数据层。
而刘工认为张工的方案过于保守，对该系统的某些功能，如关注列表、推荐列表、热搜榜单等实现困难，且性能提升不大；而李工的方案又太激进，工作量太大，短期无法完成，应尽量综合二者的优点，采用Key-Value数据库 + MySQL数据库的混合方案。
经过组内多次讨论,该企业最终决定采用刘工提出的方案。
【问题1】
张工方案中采用了读写分离，主从复制策略。其中，读写分离设置物理上不同的主/从服务器，让主服务器负责数据的（a）操作，从服务器负责数据的（b）操作，从而有效减少数据并发操作的（c），但却带来了（d）。因此，需要采用主从复制策略保持数据的（e）。
MySQL数据库中，主从复制是通过binary log来实现主从服务器的数据同步，MySQL数据库支持的三种复制类型分别是（f）、（g）、（h）。
请将答案填入（a）~（h）处的空白，完成上述描述。
【问题2】
李工方案中给出了关系数据库与NoSQL数据的比较，如下表所示，以此来说明该新闻社交类软件更适合采用NoSQL数据库。请完成下表中的（a）~（d）处空白。
【问题3】
刘工提出的方案采用了Key-Value数据库 + MySQL数据库的混合方案，是根据数据的读写特点将数据分别部署到不同的数据库中。但是由于部分数据可能同时存在于两个数据库中，因此存在数据同步问题。请用200字以内的文字简要说明解决该数据同步问题的三种方法。
参考答案
【问题1】
（a）写 （b）读 （c）锁争用 （d）数据冗余 （e）一致性
（f）基于SQL语句的复制（statement-based replication，SBR）
（g）基于行的复制（row-based replication，RBR）
（h）混合模式复制（mixed-based replication，MBR）
【问题2】
（a）最终一致性 （b）非结构化数据 （c）低事务性 （d）海量数据
【问题3】
（1）实时同步方案，先查缓存，查不到再从DB查询，并保存到缓存；更新缓存时先更新数据库，再将缓存设置过程期更新缓存。
（2）异步队列方式同步，可采用消息中间件处理。
（3）通过数据库插件完成数据同步。
（4）利用触发器进行缓存同步。
典型例题 4
题目描述
阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3。
某公司开发的B2C商务平台因业务扩展，导致系统访问量不断增大，现有系统访问速度缓慢，有时甚至出现系统故障瘫痪等现象。面对这一情况，公司召开项目组讨论会议，寻求该商务平台的改进方案。讨论会上，王工提出可以利用镜像站点、CDN内容分发等方式解决并发访问量带来的问题。而李工认为，仅仅依靠上述外网加速技术不能完全解决系统现有问题，如果访问量持续增加，系统仍存在崩溃的可能。 李工提出应同时结合Web内网加速技术优化系统改进方案，如综合应用负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等。经过讨论，公司最终决定采用李工的思路，完成改进系统的设计方案。
【问题1】
针对李工提出的改进方案，从a～j中分别选出各技术的相关描述和对应常见支持软件填入下表中的（1）~（10）处。
a）保存静态文件，减少网络交换量，加速响应请求
b）可采用软件级和硬件级负载均衡实现分流和后台减压
c）文件存储系统，快速查找文件
d）FastDFS
e）HAProxy
f）JBoss
g）Hadoop Distributed File System(HDFS)
h）Apache Tomact
i）Squid
j）MongoDB
【问题2】
请用100字以内的文字解释分布式数据库的概念，并给出提高分布式数据库系统性能的3种常见实现技术。
【问题3】
针对B2C商务购物平台的数据浏览操作远远高于数据更新操作的特点，指出该系统应采用的分布式数据库实现方式，并分析原因。
参考答案
【问题1】
（1）b （2）e （3）a （4）i （5）c
（6）d （7）g （8）f （9）h （10）j
【问题2】
分布式数据库是由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个节点具有独立处理的能力（称为场地自治），它可以执行局部应用，同时，每个节点也能通过网络通信子系统执行全局应用。
（1）采用数据分片技术，提高访问的局部性，提升系统性能。
（2）采用查询优化技术（包括：全局查询树的变换、副本的选择与多副本的更新策略、查询树的分解、半连接与直接连接） 提高查询速度。
（3）读写分离技术。
（4）负载均衡技术。
（5）分布式缓存技术
【问题3】
可以采用一主多从的主从复制技术进行读写分离。
在本题所涉及到的环境中，浏览操作远远高于数据更新操作，可以在分布式数据库中采用主从复制技术实现读写分离。主数据库负责写操作，从数据库进行读操作，在大数据量访问数据库时，能很大程度上提升性能。
典型例题 5
题目描述
阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。经过充分讨论，该公司最终决定采用刘工的方案。
【问题1】
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。下表中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表中的空（1）～（6）。
【问题2】
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请说明基本的Redis与原有关系数据库的数据同步方案。
【问题3】
请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。
参考答案
【问题1】
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
【问题2】
（1）Memcache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2）Memcache不支持事务，所以操作过程中可能产生数据的不一致性。
同步方案：
读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中。
【问题3】
Redis分布式存储的常见方案：
主从模式（Master/Slave），哨兵模式（Sentinel），集群模式（Cluster）
Redis集群切片的常见方式：
（1）客户端分片，（2）中间件实现分片，（3）客户端服务端协作分片
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
