jwhdhr
作者jwhdhr·2018-06-15 09:39
软件开发工程师·农商银行

基于支付标记化项目使用Redis构建缓存数据库的6个难点问题

字数 3647阅读 5117评论 0赞 3

近年来,互联网金融公司飞速发展,无论是业务还是技术都较传统银行业有所区别,比如一年一度的双十一给银行业无疑带来了很大的压力,作为传统的银行业如何来从技术上着手,从而构建处理速度快、系统稳定性高的业务系统,是银行业面临的一大问题。

众所周知,数据库在业务系统中占据了非常重要的地位,互联网业务的数据正以更快的速度在增长,数据类型越来越丰富,这对数据处理的速度和能力提出了更高要求,但关系型数据库在如今浪涌似的交易下极易出现瓶颈,因此互联网公司率先引入了缓存数据库来解决性能问题,在这其中,Redis 是一种开源的内存非关系型数据库,给开发人员带来的体验是颠覆性的。在自始至终的设计过程中,都充分考虑高性能,这使得 Redis 成为当今速度最快的 NoSQL 数据库,也是互联网企业在缓存数据库选型时的第一选择。

我写了一篇文章《redis最佳实践--以支付标记化为例》,以给同行业提供一点借鉴,作为传统的银行业来说,如何使用Redis来构建我们的缓存数据库从而提高我们的系统处理性能。

之后的交流活动,我和同行交流了一些经验,互动结束后,我整理了活动中出现的几个重要的难点问题,希望继续给大家一些借鉴和帮助。

1.redis 如何快速查找big key?

redis由于是内存数据库,经常需要查看是什么占用了内存资源。是否有什么方法可以快速找出什么大约是什么键占用了多大的内存

解答:
工作中,经常有些Redis实例使用不恰当,或者对业务预估不准确,或者key没有及时进行处理等等原因,导致某些KEY相当大。
那么大Key会带来哪些问题呢?

如果是集群模式下,无法做到负载均衡,导致请求倾斜到某个实例上,而这个实例的QPS会比较大,内存占用也较多;对于Redis单线程模型又容易出现CPU瓶颈,当内存出现瓶颈时,只能进行纵向库容,使用更牛逼的服务器。
涉及到大key的操作,尤其是使用hgetall、lrange 0 -1、get、hmget 等操作时,网卡可能会成为瓶颈,也会到导致堵塞其它操作,qps 就有可能出现突降或者突升的情况,趋势上看起来十分不平滑,严重时会导致应用程序连不上,实例或者集群在某些时间段内不可用的状态。
假如这个key需要进行删除操作,如果直接进行DEL 操作,被操作的实例会被Block住,导致无法响应应用的请求,而这个Block的时间会随着key的变大而变长。
有以下几种办法可以知道某个Redis实例是否存在大key:

在redis实例上执行bgsave,然后我们对dump出来的rdb文件进行分析,找到其中的大KEY
有个不太推荐的命令,debug object xxx 可以看到这个key在内存中序列化后的大小,当然我们可以通过SCAN+debug object xxx 得到当前实例所有key的大小。
redis-cli 原生自带 –bigkeys 功能,可以找到某个实例 5种数据类型(String、hash、list、set、zset)的最大key。

2.在使用redis的时候如何避免和解决缓存穿透和缓存雪崩问题?

解答:
缓存穿透:一般的缓存系统,都是按照key去缓存查询,如果不存在对应的value,就应该去后端系统查找(比如DB)。如果key对应的value是一定不存在的,并且对该key并发请求量很大,就会对后端系统造成很大的压力。这就叫做缓存穿透。
缓存雪崩:当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力。

针对缓存穿透问题,一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。通过这个直接设置的默认值存放到缓存,这样第二次到缓存中获取就有值了,而不会继续访问数据库,这种办法最简单粗暴!
针对缓存雪崩问题,给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存。
缓存标记:记录缓存数据是否过期,如果过期会触发通知另外的线程在后台去更新实际key的缓存。
缓存数据:它的过期时间比缓存标记的时间延长1倍,例:标记缓存时间30分钟,数据缓存设置为60分钟。 这样,当缓存标记key过期后,实际缓存还能把旧数据返回给调用端,直到另外的线程在后台更新完成后,才会返回新缓存。

3.redis大key删除时会造成整库堵塞,该问题如何优化?

解答1:
在Redis集群中,应用程序尽量避免使用大键;直接影响容易导致集群的容量和请求出现”倾斜问题“,在实际生产过程中,总会有业务使用不合理,出现这类大键;当DBA发现后推进业务优化改造,然后删除这个大键;如果直接删除它,DEL命令可能阻塞Redis进程数十秒,对应用程序和Redis集群可用性造成严重的影响。

解答2:
直接删除大key是有风险的,key过大,直接删除时会导致Redis阻塞,不同类型的大key有不同的删除方式,
Large Hash Key 可使用hscan命令,每次获取500个字段,再用hdel命令,每次删除1个字段。
Large Set Key 可使用sscan命令,每次扫描集合中500个元素,再用srem命令每次删除一个键。
Large List Key可通过ltrim命令每次删除少量元素
Large Sorted Set Key使用sortedset自带的zremrangebyrank命令,每次删除top 100个元素

解答3:
可以从以下方面:
1、业务角度,尽量不要使用大key或对其进行处理
2、在4.x版本之前可通过数据类型对应的参数命令进行操作,例如:针对Large Hash Key ,可使用hscan命令进行操作
3、在4.x版本后可通过UNLINK 命令用于执行大KEY异步删除

4.如何快速的增加redis的节点数?

解答:
因为现阶段比较流行的都是redis 3.0之后的集群架构模式,它提供了灵活的节点扩容和收缩方案。在不影响集群对外服务的情况下,可以为集群添加节点进行扩容也可以对下线节点进行缩容。
扩容集群是分布式存储最常见的需求,Redis集群扩容可以分为如下步骤:
准备新节点:配置和之前集群节点配置基本相同,启动后的新节点会作为孤儿节点运行,没有和其他节点与之通信。
加入集群:我们可以通过CLUSTER MEET命令将新节点加入到集群中或者也可以使用redis专门进行集群管理的工具redis-trib.rb,新加入的节点都是主节点,因为没有负责槽位,所以不能接受任何读写操作,对于新加入的节点,我们可以有两个操作:为新节点迁移槽和数据实现扩容,作为其他主节点的从节点负责故障转移。
迁移槽和数据:当我们将新节点加入集群后,我们就可以将槽和数据迁移到新的节点,迁移的方法也有两种,可以使用redis-trib.rb工具,也可以通过手动命令的方式,但是一般要确保每个主节点负责的槽数是均匀的,因此要使用redis-trib.rb工具来批量完成。

5.reids和memcached如果只有string数据时的话二者的区别是什么,该如何选择?

如果目前两者共存,如何进行收敛(干掉一个)

解答1:
针对分布式缓存库的选择,不仅要考虑产品自身的特性,同时也要考虑业务场景、系统架构层面

解答2:
u9dnrj2qt5if

u9dnrj2qt5if

6.redis有哪些安全特性和加固方法?

解答1:
需要从以下几个方面对redis进行加固,网络层加固,账号与认证,服务运行权限最小化,服务精细化授权,安全补丁

解答2:
redis有两种安全策略方式,一是限制访问ip,二是设置用户名、密码;
注:由于Redis的性能极高,并且输入错误密码后Redis并不会进行主动延迟(考虑到Redis的单线程模型),所以攻击者可以通过穷举法破解Redis的密码(1秒内能够尝试十几万个密码),因此在设置时一定要选择复杂的密码。
配置Redis复制的时候如果主数据库设置了密码,需要在从数据库的配置文件中通过masterauth参数设置主数据库的密码,以使从数据库连接主数据库时自动使用AUTH命令认证。

解答3:
上面的朋友回答的挺全面的,主要从以下方面入手:
1、权限管理层面:
(1)建议禁止root账户执行应用,使用linux nobody启动redis服务
(2)禁用危险命令:
rename-command FLUSHALL ""

rename-command FLUSHDB ""

rename-command CONFIG ""

rename-command KEYS ""

2、账户管理层面:
设置密码访问,比方:requirepass "password"或 >CONFIG set requirepass "password"
3、网络配置层面:
(1)禁止外网访问,bind 指定ip
(2)更改port值,建议采用不常用的端口地址
4、应用本身层面:
关注与redis应用相关的组件漏洞,并及时打补丁
5、其他相关层面

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

相关资料

X社区推广