本文主要是介绍关于分布式数据库缓存设计的那点事和实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
案例
【题目】
【问题 1】(9 分)
【问题 2】(8 分)
【问题 3】(8 分)
【答案】
【问题 1】答案
【问题 2】解析
【问题 3】解析
相关推荐
案例
阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题 1 至问题 3。
【题目】
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构(脚本语言+关系型数据库)研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统， 采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache 来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用 Redis 来解决问题。在经过充分讨论，该公司最终决定采用刘工的方案。
【问题 1】(9 分)
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。表 4-1 中对 MemCache 和 Redis 两种工具的优缺点进行了比较，请补充完善表 4-1 中的空(1)~(6)。
| 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
这篇关于关于分布式数据库缓存设计的那点事和实践的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
