SQL 数据库满载,Redis 力挽狂澜

为什么你的 ERP/MES/CRM/HR/OA 系统访问首页都很慢,明明你确定打开页面时没有大量的写入操作!

或许是时候了解下缓存了。

一次实战:在 SQL Server 前加层 Redis

步骤:

1 - Python 中启动 5000 根线程同时访问 SQL Server, 执行存储过程,并记录每次请求响应时间和 Windows Server 的服务器状态;

2 - 安装 Redis, 并将步骤 1 中需要的数据加载到 Redis ;

3 - Python 中启动 5000 根线程同时访问 Redis 取数, 记录每次请求响应时间与 Windows Server 服务器以及 Redis 主机 CentOS 的服务器状态

直联 SQL Server 时,5000 并发下的服务器状态:

在这里插入图片描述

注意:一个方格子为 10%. 这里大约维持在 30% 的 CPU 使用率

直联 SQL Server 时,5000 并发下的响应时间:
在这里插入图片描述

直联 Redis 时,5000 并发下的服务器状态:

在这里插入图片描述

注意:Windows Server 的 CPU 使用率一直维持在了 10% 不到的基准线上。而 CentOS 除了网络使用率高之外,CPU, 内存其实都稳定。

直联 Redis 时,5000 并发下的响应时间:

在这里插入图片描述

相较之前直联 SQL Server ,在响应时间上并没有优势也没有落后。

缓存本质

分清楚 cache 和 buffer 很重要!
电商系统中所有的商品,加在一起将达到非常长的一份列表。购物页面被打开的瞬间,顾客肯定希望商品列表分门别类的展示在眼前,而不是延迟 2,3 秒才逐个展现出来。因此在缓存服务器中,预先将数据库中百万甚至千万商品读取出来,然后分发给离顾客城市最近的二级缓存服务器上,便可给顾客一种快速从本地数据拉取商品列表的错觉。这一过程,可以称之为 cache.

顾客接着会挑选自己的商品下单。在挑选的过程中,先后会将挑好的商品存入缓存,这层缓存应当叫做 Buffer,而这份 Buffer 通常叫做购物车缓存。传统设计上将存入数据库的顾客购物列表,现在放到了 Redis 缓存中,大大减少了与数据库的交互,提高了速度。为什么不要直接与数据库交互的原因,顾客的购物车不一定最后会成单,有可能顾客只是收藏,也有可能最后一刻反悔不买了。

用好缓存

缓存适用场景 - 写少读多
在大多数小规模应用中,采用一对一模式的缓存加数据库模式便足以满足系统反应速度。过多过早的采用复杂的缓存架构只能带来负担。很多数据写入缓存就失效,还没被请求访问。从适用角度来考虑,类似新浪微博大 V 的言论,做好缓存设计就显得十分有价值。写一次就有数千万次访问,这类缓存对系统来讲就有意义的多。

缓存适用场景 - 热点数据
在购物场景中,热点数据可以有:最受欢迎的商品,团购以及礼券等。而非热点数据可以是:订单历史,用户评论等。缓存通常是用内存资源做数据存储,而内存价格相比硬盘价格要贵很多,不分轻重把所有数据都放入内存,肯定加大硬件的成本。所以分清楚系统的热点数据是哪一块,再抽取这块数据到缓存服务器内存中这一策略,肯定是在最佳。稍稍要记一笔的是,如何判断热点数据,以及非热点数据如何做请退处理。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dbLenis

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值