Redis应用案例解析

2019-03-09  本文已影响0人  抚剑听琴
以下案例摘自2018年下半年软件职业考试,并由此展开redis相关知识,持续更新中

【背景说明】

某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业,创业初期为快速开展业务,该企业采用轻量型的开发架构(脚本语言+关系型数据库)研制了一套业务系统。业务开展后受到用户普遍欢迎,用户数和业务数量迅速增长,原有的数据库服务器已不能满足高度并发的业务要求。为此,该企业成立了专门的研发团队来解决该问题。

张工建议重新开发整个系统, 采用新的服务器和数据架构,解决当前问题的同时为日后的扩展提供支持。但是,李工认为张工的方案开发周期过长,投入过大,当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据,建议采用缓存工具MemCache来减轻数据库服务器的压力,这样开发量小,开发周期短,比较适合初创公司,同时将来也可以通过集群进行扩展。然而,刘工又认为李工的方案中存在数据可靠性和一致性问题,在宕机时容易丢失交易数据,建议采用Redis来解决问题。在经过充分讨论,该公司最终决定采用刘工的方案。

1.分布式数据库缓存的基本概念

在李工和刘工的方案中,均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。

答:所谓的分布式数据库缓存就是将不同的数据放在不同的缓存服务器上,获取数据时需要根据路由从不同的服务器上获取。

2.表 MemCache与Redis能力比较

Memcache Redis
网络IO模型 多线程,非阻塞IO复用的网络模型 redis使用单线程的IO复用模型
数据类型 简单key/value Redis 有 5 种基础数据结构
持久性 不支持 支持
分布式存储 支持 多种方式,主从,Sentinel、Cluster等
多线程支持 支持 不支持
内存管理 Memcached默认使用Slab Allocation机制管理内存 Redis通过定义一个数组来记录所有的内存分配情况
事务支持 有限支持

3.说明数据可靠性和不一致问题产生等原因

刘工认为李工的方案存在数据可靠性和一致性的问题,请说明原因。

4.简述数据同步方案

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

5.简述Redis分布式存储的2种常见方案

6.简述Redis集群切片的几种常见方式。

Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。

Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。

Codis 将所有的 key 默认划分为 1024 个槽位(slot),它首先对客户端传过来的 key 进行 crc32 运算计算哈希值,再将 hash 后的整数值对 1024 这个整数进行取模得到一个余数,这个余数就是对应 key 的槽位。
每个槽位都会唯一映射到后面的多个 Redis 实例之一,Codis 会在内存维护槽位和 Redis 实例的映射关系。这样有了上面 key 对应的槽位,那么它应该转发到哪个 Redis 实例就很明确了。

hash = crc32(command.key)
slot_index = hash % 1024
redis = slots[slot_index].redis
redis.do(command)

槽位数量默认是1024,它是可以配置的,如果集群节点比较多,建议将这个数值配置大一些,比如2048、4096。

附加 1.redis 有哪些数据淘汰机制?

Redis提供了下面几种淘汰策略供用户选择,其中默认的策略为noeviction策略:

noeviction:禁止驱逐数据。当内存使用达到阈值的时候,所有引起申请内存的命令会报错。(注意是写请求返回错误,读请求可以正常执行)
allkeys-lru:在主键空间中,优先移除最近未使用的key。
volatile-lru:在设置了过期时间的键空间中,优先移除最近未使用的key。
allkeys-random:在主键空间中,随机移除某个key。
volatile-random:在设置了过期时间的键空间中,随机移除某个key。
volatile-ttl:在设置了过期时间的键空间中,具有更早过期时间的key优先移除。

扩展阅读

【redis常见面试问题】

上一篇下一篇

猜你喜欢

热点阅读