公司基于业务发展以及战略部署，需要实现在多个数据中心单元化部署，一方面可以实现多数据中心容灾，另外可以提升用户请求访问速度。需要保证多数据中心容灾或者实现用户就近访问的话，需要各个数据中心拥有一致的全量数据，如果真正实现用户就近读写，也就是实现真正的业务异地多活，数据同步是异地多活的基础，这就需要多数据中心间数据能够双向同步。

本文提出了一种可实现的基于Redis的消息队列，与传统消息队列形成互补，弥补传统消息队列这方面特性的缺失。

Redis 大家用的不少，但是我们大多数人可能都只是关注业务本身，对于底层的细节则经常忽略，久而久之，对个人的成长帮助甚少。本文为大家总结了关于 Redis 常见用法的进阶指南，希望帮助大家加深对这门技术的理解。

让code更快速、高效、完备地执行。

最近使用 Redis 遇到了一个类似分布式锁的场景，跟 Redis 实现分布式锁类比一下，就是释放锁失败，也就是缓存删不掉。又踩了一个 Redis 的坑……

资源的抽象和交付由 K8s 来完成，无需再关注具体机型。在物理机时代我们需要根据不同机型上的 CPU 和内存配置来决定每个机型的机器上可以部署的 Redis 实例的数量。通过 Redis 云原生，我们只需要跟 K8s 声明需要的 CPU 和内存的大小，剩下的调度、资源供给、机器筛选由 K8s 来完成。

节点的调度由 K8s 来完成。在实际部署一个 Redis 集群时，为了保证高可用，需要让 Redis 集群的一些组件满足一定的放置策略。要满足放置策略，在物理机时代需要运维系统负责完成机器的筛选以及计算的逻辑，这个逻辑相对比较复杂。K8s 本身提供了丰富的调度能力，可以轻松实现这些放置策略，从而降低运维系统的负担。

节点的管理和状态保持由 K8s 完成。在物理机时代，如果某台物理机挂了，需要运维系统介入了解其上部署的服务和组件，然后在另外一些可用的机器节点上重新拉起新的节点，填补因为机器宕机而缺少的节点。如果由 K8s 来完成节点的管理和状态的保持，就可以降低运维系统的复杂度。

标准化 Redis 的部署和运维的模式。尽量减少人工介入，提升运维自动化能力，这是最重要的一点。

Redis里面使用skiplist是为了实现sorted set这种对外的数据结构。sorted set提供的操作非常丰富，可以满足非常多的应用场景。这也意味着，sorted set相对来说实现比较复杂。同时，skiplist这种数据结构对于很多人来说都比较陌生，因为大部分学校里的算法课都没有对这种数据结构进行过详细的介绍。因此，为了介绍得足够清楚，本文会比这个系列的其它几篇花费更多的篇幅。

缓存 Redis 已成为高并发场景下提升数据访问速度的标配。

本文字数：3940字预计阅读时间：20分钟一、背景二、监控指标分类三、监控指标说明四、总结一、背景Redi

信也项目实战之Redis存储压缩方案，了解信也内部项目如何节省80%的Redis内存

如何有效控制Redis实例大小？

本文主要介绍主要介绍缓存使用的典型场景、实操案例分析、Redis使用规范及常规Redis监控。

edis6已经release半年有余(当前版本是6.0.7)，其中包含很多优秀的特性和优化：多线程、RESP3协议、客户端缓存、安全相关（ACL、SSL)、优化死键问题、异步删除、PSYC2、RDB加速等问题.

“众里寻他千百度，蓦然回首，那人却在，灯火阑珊处”。多年的IT生涯，一直希望自己写的程序能够有很强的健壮性，

Redis does not guarantee the consistency between master and its replica nodes when Lua scripts are used. Read more to find out why and how to guarantee data consistency.

mattsta老哥可太有意思了。八卦之心让我看完了整件事