关于分布式数据库缓存设计的那点事和实践

本文主要是介绍关于分布式数据库缓存设计的那点事和实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

案例

【题目】

【问题 1】(9 分)

【问题 2】(8 分)

【问题 3】(8 分)

【答案】

【问题 1】答案

【问题 2】解析

【问题 3】解析

案例

阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题 1 至问题 3。

【题目】

某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构(脚本语言+关系型数据库)研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache 来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用 Redis 来解决问题。在经过充分讨论，该公司最终决定采用刘工的方案。

【问题 1】(9 分)

在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。表 4-1 中对 MemCache 和 Redis 两种工具的优缺点进行了比较，请补充完善表 4-1 中的空(1)~(6)。

表 4-1
	MemCache	Redis
数据类型	简单 key/value 结构	(1)
持久性	(2)	支持
分布式存储	(3)	多种方式，主从、Sentinel、Cluster 等
多线程支持	支持	(4)
内存管理	(5)	无
事物支持	(6)	有限支持

【问题 2】(8 分)

刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。为避免数据可靠性和一致性的问题，刘工的方案采用 Redis 作为数据库缓存，请说明基本的 Redis 与原有关系数据库的数据同步方案。

【问题 3】(8 分)

请给出 Redis 分布式存储的 2 种常见方案和 Redis 集群切片的几种常见方式。

【答案】

本题考查数据库缓存的概念，以及数据库缓存方案的设计过程。

【问题 1】答案

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

【问题 2】解析

MemCache 不支持数据持久化操作，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题；
MemCache 不支持事务，所以操作过程中可能产生数据的不一致性。

同步方案：读取数据时，先读取 Redis 中的数据，如果 Redis 没有，则从原数据库中读取，并同步更新 Redis 中的数据。写回时，写入到原数据库中，并同步更新到 Redis 中。

【问题 3】解析

Redis 分布式存储的常见方案有:
（1）主从(Master/Slave)模式;
（2）哨兵(Sentinel)模式;
（3）集群(Cluster)模式。

Redis 集群切片的常见方式有：
（1）客户端实现分片。分区逻辑在客户端实现，采用一致性哈希来决定 Redis 节点。
（2）中间件实现分片。在应用软件和Redis 中间，例如 Twemproxy、Codis 等，由中间件实现服务到后台 Redis 节点的路由分派。
（3）客户端服务端协作分片。Redis Cluster 模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

答案：

Redis 分布式存储的 2 种常见方案：主从方案、Cluster 方案。
Redis 集群切片的几种常见方式：
（1）客户端分片：在客户端通过 key 的 hash 值对应到不同服务器。
（2）对数据根据 key 散列到不同的 slot 上，不同 slot 对应不同的服务器。

注：存储方案可以在问题1表格中直接摘抄下来。
slot（槽位）：是一种逻辑上的划分，用于将数据集合（如键值对）根据一定的规则（如哈希函数）分配到不同的存储单元（如服务器）上。每个slot通常对应一个或多个物理或逻辑上的存储节点。

相关推荐

【系统架构设计师】三、数据库系统(事务并发|封锁协议|数据库安全|商业智能|SQL语句)-CSDN博客文章浏览阅读1.2k次，点赞27次，收藏12次。事务是并发控制的前提条件，并发控制就是控制不同的事务并发执行，提高系统效率，但是并发控制中存在下面三个问题：丢失更新：事务1对数据A进行了修改并写回，事务2也对A进行了修改并写回此时事务2写回的数据会覆盖事务1写回的数据，就丢失了事务1对A的更新。即对数据A的更新会被覆盖。不可重复读：事务2读A，而后事务1对数据A进行了修改并写回，此时若事务2再读A，发现数据不对。即一个事务重复读A两次，会发现数据A有误。读脏数据：事务1对数据A进行了修改后，事务2读数据A，而后事务1回滚，数据A恢复了原来的。https://shuaici.blog.csdn.net/article/details/139778680【系统架构设计师】二十二、嵌入式系统架构设计理论与实践③-CSDN博客文章浏览阅读1.2k次，点赞30次，收藏19次。鸿蒙 (HarmonyOS) 整体采用分层的层次化设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统”→“子系统”→“功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。https://shuaici.blog.csdn.net/article/details/140818780