中间件与数据库:Redis

腾讯会议核心存储治理:Redis分库和异地多活

异地容灾多活、高可用我都要,腾讯会议核心存储治理实践。

Redis的BigKey(大key)、HotKey(热key)又引发了线上事故

日常生产中经常会碰到由于redis集群的不当访问,造成的线上问题。其中比较常见的是BigKey(大key)和HotKey(热key)的问题。

一次访问Redis延时高问题排查与总结(续)

本文是一次访问Redis延时高问题排查与总结的续篇,主要讲述了当时没有发现的一些问题和解决方案。

Redis Bigkey排查

Redis bigkey 是指在 Redis 数据库中占用空间较大的键值对。这些键通常包含了大量的数据,可能会影响 Redis 的性能和内存使用。例如,在一个集合、哈希表、列表或有序集合中存储了大量元素的键。

携程Redis跨IDC多向同步实践

跨数据中心的数据同步是企业提升容灾实力的必备手段。

Jedis 参数异常引发服务雪崩案例分析

本文主要分析Redis3.x版本集群模式发生主从切换场景下Jedis的参数设置不合理引发服务雪崩的过程。

深入解析Redis的LRU与LFU算法实现

重点介绍了Redis的LRU与LFU算法实现,并分析总结了两种算法的实现效果以及存在的问题。

一次访问Redis延时高问题排查与总结

本文抽丝剥茧得记录了一次访问Redis延时高问题的排查和总结。

Redis持久化:RDB和AOF

Redis 数据存储在内存中,如果不想办法将数据保存到硬盘上,一旦Redis重启(退出/故障),内存的数据将会全部丢失。我们肯定不想 Redis 里的数据由于某些故障全部丢失(导致所有请求都走 MySQL),即便发生了故障也希望可以将Redis原有的数据恢复过来,这就是持久化的作用。

Redis分布式锁正确打开方式

随着业务的发展,架构从单体系统发展到SOA、然后是微服务。由于多进程、多线程分布在不同机器上,单机上的并发控制策略失效,于是分布式锁应运而生,跨JVM的共享资源的访问(互斥机制)得到有效解决。

一文了解Redis集群及客户端设计原理

Redis集群是一个由多个Redis实例组成的分布式系统,它可以极大提高系统的可用性和扩展性。与传统的主从复制相比,Redis集群具有更好的吞吐量、更稳定的性能和更好的数据一致性。Redis集群也是信也科技在生产环境中使用最多的redis架构。在这篇文章中,我们将深入探讨Redis集群的组成架构、工作原理和最佳实践,希望能为大家了解Redis集群提供有益的参考和指导。

Redis延迟问题全面排障指南

了解Redis排障深水区。

VLDB 顶会论文 Async-fork 解读与 Redis 实践

通过不同数据量下对比测试,我们可以看到,Async-fork 相比原生 fork,阻塞时间大大减少,性能提升非常明显。而且阻塞时间非常稳定,不会因为数据量的增长出现倍数级增长。

Redis为什么这么快?

Redis是一个开源的内存中的数据结构存储系统,在实际的开发过程中,Redis已经成为不可或缺的组件之一,基于内存实现、合理的数据结构、合理的数据编码、合理的线程模型等特征不仅仅让Redis变得如此之快,同时也造就了Redis对更多或者复杂的场景的支持。

Redis两层数据结构简介

Redis 的性能高的原因之一是它每种数据结构都是经过专门设计的,并都有一种或多种数据结构来支持,依赖这些灵活的数据结构,来提升读取和写入的性能。

Optimizing Myntra’s Pricing System for Serving Millions of Traffic under 30ms Latency

Myntra’s pricing system is responsible for uploading various discounts for different products and serving them to multiple services. Currently, the pricing system has been serving discount information with a latency of 150ms for millions of traffic. With increasing scale and the need to disseminate discount information to several other systems, it became essential to scale the system to handle the increased load while maintaining its resilience, robustness, and fault tolerance. Several new features are being developed which require pricing information to be available in synchronous flows. To enable all these features, our pricing system needs to scale to handle 10s of millions of requests with latency as low as 30ms.

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.124.0. UTC+08:00, 2024-04-27 05:49
浙ICP备14020137号-1 $访客地图$