大规模场景中的Redis使用进阶技巧

“ 具备高吞吐量和高性能的 Redis 始终活跃在程序设计实现一线，优秀的特性让多少人为之折服。在繁多的使用姿势中，掌握些奇技淫巧将会事半功倍，让人刮目相看！”

点击卡片关注 code 杂坛 ，和我们一起

奇技淫巧，万象丛生

Redis 支持存储、缓存、中间件…等各种功能作用，凭借其出色的特性获得大家青睐。作为最常用的明星组件之一，其在不同场景下的使用姿势不尽相同，尤其在大规模高并发追求极致性能中，各种奇技淫巧玲琅满目。

在高并发场景下，为保障服务高可用和高性能指标，也对架构设计提出了更高的要求：共享资源的并发安全性、高强度下的服务稳定性、大规模流量下服务的P99…等各项高标准的指标数据背后，离不开工程师们的独具匠心和高超技艺。

Redis CRUD

良好的 CRUD 编排，可使服务性能提升 2-3倍。

在一般场景中，对 Redis 的使用像大多存储一样，离不开 CRUD。在高并发下，如何编排 CRUD 是一个技术活。如下一个场景：

QPS 7-8w，DAU 1.2亿 规模下对用户 uid 进行 redis
存储。读写规则，记录用户请求未检索时，不作统计数据；若检索时，则记录连续检索频次。

基本存储格式：为后期业务扩展，存储格式暂定为 Hash ，key 为 uid

看到这个情景，有同学可能已经胸有成竹了：用户检索直接进行 HINCRBY，当出现未检索时，执行 DELETE。

这个方案是最常规的方案了，但不是最适合此场景的方案！

这个方案，你看是不是更合理：用户检索直接进行 HINCRBY，当出现未检索时，执行 HSET 0。

此时有同学可能会有疑问，DELETE 和 HSET 有什么区别呢？执行效率不都是一样 O(1)。

没错，单单从单次执行效率看是一样。当同一 uid 频繁访问，检索与非检索切换时，DELETE 需要频繁的申请释放内存，而 HSET
只需调整值即可。

这个时候，可能有同学就质疑了，使用 HSET 岂不是内存使用一直飙升？

没错，使用 DELETE 会有效控制内存涨幅。

那么对于这两种方案，如何取舍呢？

鱼与熊掌不可兼得

在空间和效率面前如何抉择，这是个亘古不变的问题。

在各种开源组件、公共服务中都屡见不鲜。比如，goland 中原生包 syn.map、java 中 hashmap/table、锁机制中的乐观锁、数据库中的MVCC….等等等等。

面对这个问题，需要求同存异，寻求折中方案。

在 Redis 中支持一种 expire 策略，我们可以根据可使用的资源规模去设定具体的有效期，这样就能保证高执行效率的同时，资源能够得到充分的利用。

Redis Pipeline

在 Redis 读写过程中，主要存在网络耗时和服务端处理耗时两部分，其中网络耗时占 99.99….%。那么有没有办法压缩网络耗时呢？

Pipeline 为此而生，极大程度的避免了频繁交互过程中产生的网络耗时。

Connections support pipelining using the Send, Flush and Receive methods. —— Pipelining

Pipeline 由 Send 和 Flush 、Receive 三部分组成，把批量的待执行命令 Send 至应用程序输出缓冲区，手动制定阈值 Flush ，刷数据进内核进行 网络传输，最后由 Receive 接收响应。

Pipeline 将 N 条待执行的指令合并一条，进行网络传输，减少了 N-1 次的网络耗时，极大的提升了 Redis 的读写能力。
点击卡片关注 code 杂坛 ，和我们一起

猜你喜欢

Mysql数据库优化秘籍

HTTPS 如何保证数据传输安全 —— TLS 协议

Kafka高吞吐、高性能核心技术及最佳应用场景

五分钟搭建基于Prometheus + Grafana实时监控系统

点击卡片关注 code 杂坛 ，和我们一起

#架构|高可用|高性能|高并发|高容错|HTTP|网络|云原生|面试#