在得物技术体系中，大量使用Redis作为缓存中间件，以应对高并发下的大流量场景。在使用缓存时，不得不考虑数据一致性问题，即保证缓存中的数据和DB始终可以保持一致。常规的解决缓存一致性的方案一般为先修改DB并提交事物，再操作缓存更新或者失效，为了应对极端场景往往会再采用延迟操作的方式进行缓存的二次处理。

但实际开发中，遇到很多代码不规范的场景，在JDBC事务中进行缓存删除或者更新等操作，带来的问题是当JDBC事务未提交就完成了Redis的操作，容易造成二者数据不一致。所以我们思考：既然Redis本身也提供了事务的解决方案，那能不能将Redis事务和DB的事务进行结合，来保证数据一致性的问题呢？接下来我们就带着这个问题看看看Redis事务的实现、使用，最终探索一下将Redis操作结合DB事务使用的可能性。

之前给团队的同事做了一次超容易理解的 Redis 入门分享，这里加以整理修改成文章分享给需要的童鞋。

本文将会从：Redis 使用场景与介绍 -> 数据结构与简单使用 -> 小功能大用处 -> 持久化、主从同步与缓存设计 -> 知识拓展 来书写，初学的童鞋只要能记住 Redis 是用来干嘛，各功能的使用场景有哪些，然后对 Redis 有个大概的认识就好啦，剩下的以后有需要的时候再来查看和实践吧！

本文重点讨论AOF持久化方案，以及其存在的一些问题。

推送平台的特点是并发高、消息量大、送达及时性较高。系统设计中采用Redis集群作为消息存储和中转，以及token信息存储。集群规模大。本文围绕推送系统对Redis集群的使用，遇到的问题及解决方案，优化过程讲解。

​本文将主要分析 Redis 主从复制中的内存消耗过多和堵塞问题，以及 Redis 7.0 (尚未发布) 的共享复制缓冲区方案是如何解决这些问题的。

本次以Redis为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践。

希望通过本文让大家真正掌握跳表这种数据结构，掌握Redis的Sorted-Set底层实现的原理。

What if you could dramatically reduce the cost to operate on cloud providers? That’s what we found when we dug into Redis HASH vs SET.

Redis线程模型为什么要这么设计，有什么优点和缺点，有哪些思想是可以借鉴的...本文从网络IO的历史、Reactor模型的历史、到Redis线程模型的设计由浅入深，慢慢道来。

Jedis作为业内较通用的Redis客户端，通过深入剖析Jedis的多种模式的工作原理能够在日常工作中更好的使用。

本文介绍了一次大规模的Redis集群进行扩容操作遇到的性能问题，排查以及优化过程。

Uber’s GSS (Global Scaled Solutions) team runs scaled programs for diverse products and businesses, including but not limited to Eats, Rides, and Freight. The team transforms Uber’s ideas into agile, global solutions by designing and implementing scalable solutions. One of the areas of expertise within GSS is the Digitization vertical. The Digitization team efficiently converts physical signals into digital assets and provides services in labeling, in-field testing, data curation and validations for maps, product incubation, freight BOL (bill of lading), Eats menu uploads, etc.

All these digitization services are performed by thousands of humans (operators) working on our internal applications across many locations around the globe. While an operator is digitizing data, our backend collects a clickstream of all the user interactions in the form of raw events to the scale of 10 million events per day in AWS (Amazon Web Services) cloud infrastructure. Sometimes this data is also moved to Uber’s own data centers. Our data analytics team performs analysis on this data to improve/tweak the process, augment tooling infrastructure, address operator motivation, and improve operator skills. Analytics is usually performed by querying big data lakes and using different frontend tools for visualisation. Generally, any analytics setup has a latency (source to user) component to it and the latency of our existing (pre-COVID) infrastructure was 1 hour. With the onset of COVID-19 crisis, the digitization process had to be transitioned to work-from-home mode, leading to additional operational complexity of remotely managing a huge workforce of operators. This complexity created a gap in team’s communication, decision making, and collaboration. Where 1-hour latency of our analytics platform was previously acceptable, real-time analytics was needed to fill this gap. This blog describes how we improved latency of our data architecture by building a real-time analytics system.

While we researched approaches used for building real-time dashboards (example), we did not find an end-to-end solution, considering how rich visualization can be achieved at lower cost. We considered different visualization approaches and also looked at commercial solutions to come up with our choices. Another differentiating aspect was that our solution also addresses the need for a “single source of truth” on Amazon S3 (Amazon’s “simple storage service”), from which both streaming and batch processed dashboards would to be sourced, rather than hooking directly into the Amazon Kinesis Data Firehose stream itself. This intermediate storage lets us recover data (for the streaming window) with a replay. We production tested our visualizations with thousands of users for low load times and reliability.

大Key与热Key如果未能及时发现并进行处理，很可能会使服务性能下降、用户体验变差，甚至引发大面积故障。

最近优惠服务的redis经常会间歇性的抖动，具体表现为在短时间内redis rt上涨明显，RedisCommandTimeoutException异常陡增。

Redis 分布式锁的话题，很多文章已经写烂了，我为什么还要写这篇文章呢？

因为我发现网上 99% 的文章，并没有把这个问题真正讲清楚。导致很多读者看了很多文章，依旧云里雾里。

本文从实际使用场景出发，介绍了HyperLogLog算法的原理和Redis的实现。最后通过一系列实验，解释了文章最初的问题，以加深对HyperLogLog的理解。