2018年系统架构师案例分析试题四

目录

案例

【题目】

【问题 1】(9 分)

【问题 2】(8 分)

【问题 3】(8 分)

【答案】

【问题 1】答案

【问题 2】解析

【问题 3】解析

相关推荐

案例

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

【题目】

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

【问题 1】(9 分)

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